Per sharonbautista in #274, this can now be removed. However, also per sharonbautista, it is possible we will want to recruit study participants from the extension in the future, so I have just turned the feature flag off in config rather than completely reverting PR#278.
Also update METRICS.md to add the `'amazon_smile_link'` value for the `element` extra key for the `open_nonproduct_page` event, since that was part of the string change request as well.
This overflow declaration was added in #215, nominally to help deal with
overflow issues when pinned to the overflow menu, but it's not clear how this
particular line helps vs the other changes to the width of the onboarding
view.
My theory on why this is biting us now:
- #256 updated the popup to a fixed width when not in the overflow menu, and a
flexible width when it is.
- When we have more items than the 600px max height in the popup, we overflow
and add a vertical toolbar inside.
- The vertical toolbar increases the desired width of the popup, causing the
body element to add a horizontal scrollbar.
- The horizontal scrollbar increases the height beyond the 600px limit (since
the initial overflow is contained within the product listing), causing the
body element to add a vertical scrollbar.
If we force the body element to hide overflow, it refuses to add scrollbars, and
the overflow scrollbar on the product listing is overlaid correctly. This should
be safe to do now that we flex the width of the popup based on where it is
located.
Tracking protection is blocking the eBay favicon from being loaded in private
browsing mode, but serving it locally instead of fetching it from the internet
avoids being blocked.
Update `shouldUpdatePrices` with a check for whether or not the active window is a private window.
I did not add a check for `isActiveWindowPrivate` in `shouldExtract` in `./src/privacy.js`, despite the fact that `browser.extension.inIncognitoContext` returns the "wrong" value for background extraction, because background extraction is gated by the `shouldUpdatePrices` check.
Detect toolbar button in fixed overflow menu:
- Add a call to `getPlacementOfWidget`
- This check covers the case when the toolbar button is explicitly pinned/unpinned to the Overflow menu by the user.
Context:
- The original patch only detected the toolbar button in the non-fixed overflow menu, which only covered the case when the toolbar button was moved into and out of the overflow menu by a window resize.
- Per jaws, the fixed versus non-fixed Overflow menus live in two different areas of the browser chrome, where "the non-fixed overflow panel is the area that is basically an extension of the navigation-toolbar."
- With both checks together, we cover both of the cases in which the toolbar button can be moved into and out of the Overflow menu.
With CustomizableUI.jsm (via the experimental `browser.customizableUI` API added in #157), it is possible to detect when the browserAction toolbar button is and is not in the Overflow menu.
Because the overflow menu width varies by OS (for example, it is 377px wide on my Mac 10.13 and 425px wide on a Linux 14.04), this patch will detect whether or not the toolbar button is in the Overflow menu and adjust the width accordingly.
This fix has the added benefit of allowing us to constrain the non-Overflow menu popup width (which is hopefully the vast majority use case) to the UX spec of 320px where previously we had set it to a max-width of 400px to try to accomodate Overflow menu issues.
Michael Kelly
Michael Kelly
Sakshi
Bianca Danforth