This patch does several things:
1. If there is a change to a host or a slot, check the slottable
elements to see if they are rendered in the tree. Remove them if not.
2. Check slot elements' fallback content if it is rendered and remove if
not.
3. Allow accessibles to be reinserted into a different parent or index.
Differential Revision: https://phabricator.services.mozilla.com/D43489
--HG--
extra : moz-landing-system : lando
Hooks up slow script reporting to the ContentDelegate. Allowing slow script prompts to be implemented.
Differential Revision: https://phabricator.services.mozilla.com/D41970
--HG--
extra : moz-landing-system : lando
If there are no stored logins, the Cancel button is hidden.
If there are visible stored logins, clicking the Cancel button will exit and move to the first login in the list.
If there are no visible stored logins, clicking the Cancel button will reset the search filter, exit, and move to the first login in the list.
This patch also fixes a race condition where we could end up with multiple observer notifications if about:logins was loaded multiple times very quickly.
Differential Revision: https://phabricator.services.mozilla.com/D43544
--HG--
extra : moz-landing-system : lando
We should only prompt for master password when copying a password, or when changing from a hidden to revealed password.
This patch maintains the revealed state when going from readonly to edit mode of the login. When leaving edit mode, whether through cancel or save, the revealed state is reset.
Differential Revision: https://phabricator.services.mozilla.com/D43883
--HG--
extra : moz-landing-system : lando
We store the created DebuggerClient when opening the Browser Console
so we can close it when closing the Browser Console window.
The Browser Console window `unload` event listener is moved out of
the BrowserConsole class to the BrowserConsoleManager, so we can close
the DebuggerClient when the window is closed (plus it makes more sense
to have it here since that's where we create the window).
Finally, functions that were inlined in toggleBrowserConsole are moved
as method of the BrowserConsoleManager for clarity.
Differential Revision: https://phabricator.services.mozilla.com/D43930
--HG--
extra : moz-landing-system : lando
Only SeekToNextFrame cares about promises, but prior to this patch the common
method HTMLMediaElement::Seek() would always return a promise.
When the caller was not SeekToNextFrame (e.g., SetCurrentTime, FastSeek), the
promise would end up *not* being exposed. When later rejected, we would catch
this and write an error to the js console.
This patch lifts the handling of the promise out of Seek() and into
SeekToNextFrame() so that we avoid creating promises that would not get exposed
to js.
Differential Revision: https://phabricator.services.mozilla.com/D42511
--HG--
extra : moz-landing-system : lando
I'm not sure of the exact cause since that would require doing a local Windows beta build and the getService error doesn't indicate what failed inside the component. I mostly guessed that this was the problem by looking at other tests which do the same thing.
Differential Revision: https://phabricator.services.mozilla.com/D43899
--HG--
extra : moz-landing-system : lando
In order to do this properly, we create new variable in
variables.css that hold the same values as the console-warning-*
variables we have in webconsole.css.
We take this as an opportunity to replace the box shadow on
the deprecation label by an outline. I think this was done
so the border doesn't take additional height, and outline
seems perfect for this job.
Differential Revision: https://phabricator.services.mozilla.com/D43933
--HG--
extra : moz-landing-system : lando
As far as I can tell the try...catch was originally added around various sendAsyncMessage calls but then when some logic got moved to a helper, the try...catch didn't move along with it. This try...catch made it very annoying to debug an issue with bug 1570372 because it swallowed errors that were getting thrown. It doesn't seem like a good idea to swallow all errors for large pieces of code.
Differential Revision: https://phabricator.services.mozilla.com/D43863
--HG--
extra : moz-landing-system : lando
In Bug 1387894 we created a mode for Firefox where it unconditionally clamps all timestamps to 20 microseconds. This happens if you disable privacy.reduceTimerPrecision (which is on by default) and is so we don't inadvertently leak super-high-resolution (nanosec) timestamps.
As part of that patch, we started clamping animation timestamps - which are exempted from privacy.reduceTimerPrecision because it was too difficult to get them working at the time. (We should still fix that though.)
This caused new test failures, and one of those was a comparison between document timelines and the timestamp in requestAnimationFrame. we were not clamping the timestamp in requestAnimationFrame under the logic that it fires in predictable intervals.
However discussions about the WPT change we made to 'fix' the now-broken comparison https://github.com/web-platform-tests/wpt/pull/18172 and https://github.com/web-platform-tests/wpt/pull/18357 showed me that document.timeline is supposed to be slaved to the requestAnimationFrame timestamp (or vice versa.)
The correct fix is therefore to unconditionally clamp the requestAnimationFrame timestamp AND the document.timeline timestamp. In doing so we also start clamping/jittering the requestAnimationFrame timestamp in Resist Fingerprinting mode, so that might cause some new/unexpected behaviors for that mode we should watch out for.
Differential Revision: https://phabricator.services.mozilla.com/D43788
--HG--
extra : moz-landing-system : lando
We're getting crashes because either there's no CycleCollectedJSContext or it
has a null JSContext. Hard to tell which, and whether this is happening
because our runnable comes really early in thread setup or really late in
thread teardown. In either case, this is restoring the null-check that used to
be there in this code.
Differential Revision: https://phabricator.services.mozilla.com/D43804
--HG--
extra : moz-landing-system : lando
Adds unit tests for the Home page code and Messaging System code in browser/component/newtab into treeherder/try automation. Currently at Tier 2, should move to Tier 1 before long.
Differential Revision: https://phabricator.services.mozilla.com/D43562
--HG--
extra : moz-landing-system : lando
The Rust get_if_addrs library previously used does not build on Android with
our build system. Since we're already using nICEr to determine the local
interface addresses, rather than fix the Rust library, we can use those
addresses to set the interface on which mdns_service listens.
Differential Revision: https://phabricator.services.mozilla.com/D42760
--HG--
extra : moz-landing-system : lando
Checking this assertion outside of the if statement can result in
a use-after-free in debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D42152
--HG--
extra : moz-landing-system : lando
The current code causes one mDNS service to be created for each PeerConnection.
Due to Bug 1569311, the services persist until shutdown, which can lead to a
lot of mDNS threads running on sites which use WebRTC for fingerprinting. This
change makes it so we start at most one mDNS service.
I've filed Bug 1569955 to look at shutting down the mDNS service after the
last hostname is unregistered. As an alternative, if we fix Bug 1569311, we
could also use refcounting and stop the mDNS service after the last
StunAddrsRequestParent is freed.
Differential Revision: https://phabricator.services.mozilla.com/D42151
--HG--
extra : moz-landing-system : lando
With the move to the socket process, the UUID service is no longer available
in nricectx. This adds a pair of helper functions to mdns_service to generate
UUIDs and uses them to generate hostnames inside nricectx.
Differential Revision: https://phabricator.services.mozilla.com/D42150
--HG--
extra : moz-landing-system : lando