The Mac focus model is a bit different (mouse doesn't focus form
controls for example).
This matches GTK3 to my knowledge, where outlines are not shown until
you've navigated with the keyboard.
We should maybe consider changing Android as well (and maybe all
platforms, actually), but that's a bit of a bigger endeavour.
Differential Revision: https://phabricator.services.mozilla.com/D75505
In RFP mode, we do not support `PerformanceNavigationTiming`, so don't expose
it. In particular, `window.PerformanceNavigationTiming` should return
`undefined`.
Added a new method `PerformanceNavigationTiming::Enabled` which when used with
the WebIDL `Func` attribute allows us to toggle whether
`window.PerformanceNavigationTiming` is exposed.
Created
`dom/tests/mochitest/general/test_toggling_performance_navigation_timing.html`
to test whether the toggling works. Updated
`browser/components/resistfingerprinting/test/browser/browser_performanceAPI.js`
to create a new window each time `privacy.resistFingerprinting` is flipped so
this behavior does not leak into other tests.
Differential Revision: https://phabricator.services.mozilla.com/D73528
This seems to come from bug 618907, which seems to be a hack-around code
that went away in bug 1595435.
If we open a window on mousedown such as it gains focus before this code
runs, we just steal the focus from it, which is undesired.
Also remove the test for bug 799299. It doesn't work anyways if the
browser is remote (this test only runs on non-e10s mode), and this
unifies the behavior with e10s and with content (see attached test-case,
which doesn't change behavior with and without my patch).
Differential Revision: https://phabricator.services.mozilla.com/D73901
This seems to come from bug 618907, which seems to be a hack-around code
that went away in bug 1595435.
If we open a window on mousedown such as it gains focus before this code
runs, we just steal the focus from it, which is undesired.
Also remove the test for bug 799299. It doesn't work anyways if the
browser is remote (this test only runs on non-e10s mode), and this
unifies the behavior with e10s and with content (see attached test-case,
which doesn't change behavior with and without my patch).
Differential Revision: https://phabricator.services.mozilla.com/D73901
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
Instead of manually defining toStringTag we now add the toStringTag symbol to the list of properties.
This is also how we usually define toStringTag in the JS engine.
Even though this changes more code I like this approach better. Everything is centralized in the generated bindings file.
Differential Revision: https://phabricator.services.mozilla.com/D72179
This code is supposed to test what happens when you wrap the outer for an
inner after the inner has been nuked, and the outer has navigated to a
remote window. However, the current code just runs when any window anywhere
gets nuked. Also, it never unregisters itself. This patch fixes both of
those issues.
My hope is that this will fix an intermittent orange we are seeing, but
there's also an underlying issue that should be addressed at some point.
Also, we don't need the inner-window-nuked notifications from the parent.
Differential Revision: https://phabricator.services.mozilla.com/D72081
We need it to live in BrowsingContext instead of WindowContext, because
we need to preserve the zoom level across same-origin navigation.
It'd be nice if it only lived in the top BC, but that's not possible at
the moment because a lot of tests rely on zooming only iframes. Some of
them can be adjusted for scaling the top instead, but not sure it's
worth it's worth fixing them and moving the zoom to be top-only, as it'd
be a bunch of effort, and the complexity and overhead of propagating the
zoom is not so big.
The print-preview-specific code in nsContentViewer is from before we did
the document cloning setup, and it seems useless. I've tested print
preview scaling before and after my patch and both behave the same.
The rest is just various test changes to use the SpecialPowers APIs or
BrowsingContext as needed instead of directly poking at the content
viewer.
I named the pres context hook RecomputeBrowsingContextDependentData, as
more stuff should move there like overrideDPPX and other media emulation
shenanigans.
I also have some ideas to simplify or even remove ZoomChild and such,
but that's followup work.
Differential Revision: https://phabricator.services.mozilla.com/D71969
Xray waivers for remote window proxies don't make much sense, so we nuke any
waiver when a window proxy navigates from local to remote. However, this xray
waiver can be the target of a CCW, and dead wrappers are not supposed to the
target of a CCW, so we need to find and nuke any CCWs targetting the waiver.
This requires fixing js::RemapWrapper so that it can be used to fix CCWs to
dead wrappers.
Hopefully this will fix a bunch of intermittent failures in
browser_windowProxy_transplant.js.
Differential Revision: https://phabricator.services.mozilla.com/D66459
--HG--
extra : moz-landing-system : lando
