Notes:
- I had to put the copy in brackets in StudyInvitation.jsx to be able to use the apostrophe it contains. This avoids the eslint rule error react/no-unescaped-entities.
- The panels are wider than bryanbell's mocks, but the PR for #256 will fix that.
This brings our testing accuracy to 92%. I think I trained on one vector (to get the 92% one) but then mistranscribed it into the master vector before I did the testing run. So it should be a legitimate, not-cheating 92%.
Order the coeffs alphabetically in the ruleset factory so getCoeffsInOrder() works once more.
Upgrade to Fathom 2.8 so FathomFox's good/back-clicking features work when you symlink from a fathom-trainees fork to here. (Yarn looks in pricewise, not in fathom-trainees, for a copy of fathom.)
Also don't require the price to come at the end, in service of the "US $5.00 plus free shipping" use case which I misread "'US $5.00' on eBay" as. Let's see how that goes.
Express it in terms of fuzzy truth. Also greatly simplify. I'd like to test whether this does as well or better than the overlap-testing method.
In doing so, change getHighestScoringImage() to return its fnode, not its element.
Add a trapezoid function, mostly to clamp it to 0..1 before we raise it to the coeff's power.
Re-spell largerImage() for consistency. ("Is" is what we've been using for fuzzy-truth values elsewhere, so we adopt it here.)
Also break up both "price" rules into separate ones for parent and the actual element so the trainer can come up with optimal coeffs, rather than what I assume is a human guess of .75x difference.
Start those new parent coeffs out at as close to .75x as I could.
I'm not sure what scaling by the viewport size was getting us before. I could just be dense.
Put the coefficients vector back; I had used a shrunken one for faster training when working on image rules.
I'm hoping this sort of thing will help penalties like the cart one have a more consistent effect, since we'll no longer be blowing up bonuses without bound.
Previously, price polling (a.k.a. background price updates) was disabled when Do Not Track, Tracking Protection or certain cookie settings ('reject_third_party' and 'reject_all') were enabled.
Now, price polling occurs in these situations. This leaves the `shouldUpdatePrices` function in `privacy.js` kind of useless, but I left it there instead of removing it entirely in order to add the Private Browsing check that is part of #177.
In order to avoid the eslint `no-cycle` error, I moved all events to be registered to their own `events.js` script, so that both `privacy.js` and `extension.js` could import from `events.js`. (thanks Osmose for the idea)
More about the `no-cycle` error that was avoided: This error came up when I tried to import CATEGORY_3_EVENTS from `./src/telemetry/extension.js` into `./src/privacy.js`, since we were already importing `shouldCollectTelemetry` from the latter into the former.
Tacking this on, though it's an unrelated error.
Previously, we were attempting to send messages via `tabs.sendMessage` to all content scripts both the ones running in content processes and in the background. However, the tabId for a content script in the background is -1, which is not a valid value for sending messages to content scripts in specific tabs.
Since the code that introduced this error was intended to fix an issue related to badging the browserAction toolbar button to add a new product, and since that badging is only triggered by extraction in content processes, we don't need to worry about sending the message to the background.
Now, we now no longer see the error:
`Type error for parameter tabId (Integer -1 is too small (must be at least 0)) for tabs.sendMessage.`
Adds a new Redux action UPDATE_PRODUCT which replaces the existing Product object in the store with a new one created from a re-extraction of the product page. The only keys that are not overwritten are the ids: `product.id` and `product.anonId`.