This also makes it so that the initial browser tab setup code can handle a JS array
as the URI(s) to load during start-up. If it's an array, the first element of that
array is inspected to determine what process type the initial browser tab should
be in.
Differential Revision: https://phabricator.services.mozilla.com/D14755
For a better user experience of auto-blocking canvas extraction, this
patch changes the behavior when detecting a canvas extraction without
user interaction. It will show a canvas identity block icon with a
hidden doorhanger when auto-blocking the canvas extraction. Users can
make their choice to either block or allow the canvas extraction by
clicking the identity block icon and then refresh the page to make
the canvas permission taking effect.
Differential Revision: https://phabricator.services.mozilla.com/D14259
We must delay setting the selected index, otherwise we may end dealing with
richlistitems without an applied binding, and the richlistbox may break them
permanently by setting a "selected" expando.
Differential Revision: https://phabricator.services.mozilla.com/D14385
We have a few places where C++ calls ChromeUtils::Import directly.
I fixed these to pass the target object directly instead of an empty Optional<>.
Differential Revision: https://phabricator.services.mozilla.com/D14180
- Unified openContainerNodeInTabs and openURINodesInTabs in PlacesUIUtils into openMultipleLinksInTabs
- Users are now warned when the amount of links to be opened is equal to or exceeds browser.tabs.maxOpenBeforeWarn
Differential Revision: https://phabricator.services.mozilla.com/D12983
This can happen when we annotate trackers with the strict list but block based on the
basic list, and it is confusing users.
Differential Revision: https://phabricator.services.mozilla.com/D13968
I missed the failure in browser_selectpopup_colors.js since it doesn't run on
Linux. Fix the getComputedStyle usage in that code by using
getDefaultComputedStyle, which is what it really wants.
Also, do a bit of cleanup while at it: uaBackgroundColor was unused, and uaColor
was wrong (we don't override the ua color of the <option> element, it just
inherits, so it's the same as the <select> color, and that's what we were
comparing it against anyway).
Differential Revision: https://phabricator.services.mozilla.com/D13956
I missed the failure in browser_selectpopup_colors.js since it doesn't run on
Linux. Fix the getComputedStyle usage in that code by using
getDefaultComputedStyle, which is what it really wants.
Also, do a bit of cleanup while at it: uaBackgroundColor was unused, and uaColor
was wrong (we don't override the ua color of the <option> element, it just
inherits, so it's the same as the <select> color, and that's what we were
comparing it against anyway).
Differential Revision: https://phabricator.services.mozilla.com/D13956
Seems that when run as the first test in a test run there is a race for whether
the favicon for the initial tab has already been seen or not. Rarely we fail the
race and end up seeing a successful favicon load. This makes us ignore any
favicons other than the one we're interested in.
Differential Revision: https://phabricator.services.mozilla.com/D13838
