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
- Use former ReparentNativeWidgetInternal() code in nsWindow::SetParent().
Also update mToplevelParentWindow for Wayland to hold default toplevel window.
- Make nsWindow::ReparentNativeWidget() to work on toplevel windows only and use only gtk_window_set_transient_for() to reparent
a toplevel window. Also update mToplevelParentWindow for Wayland.
Differential Revision: https://phabricator.services.mozilla.com/D43600
--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
This avoids doing wasted work and sending spurious resize
events if this case would be hit.
In practice, it cannot be hit yet, I think, because
callers do check for this and bail out earlier. But
there's no assertion to that respect so this shouldn't
hurt.
Differential Revision: https://phabricator.services.mozilla.com/D43798
--HG--
extra : moz-landing-system : lando
The old code was making an autoRestoreTransform around dest and then quickly
overwriting dest with something new. I prefer creating the autoRestoreTransform
for buffer, which doesn't change over the course of this function.
Differential Revision: https://phabricator.services.mozilla.com/D43384
--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
