- Introduce `dom.webcomponents.elementInternals.enabled` for custom element's elementInternals.
- Implement disabledFeatures static field and disableInternals.
- Refactor get observedAttributes sequence.
Differential Revision: https://phabricator.services.mozilla.com/D52156
--HG--
extra : moz-landing-system : lando
- Introduce `dom.webcomponents.elementInternals.enabled` for custom element's elementInternals.
- Implement disabledFeatures static field and disableInternals.
- Refactor get observedAttributes sequence.
Differential Revision: https://phabricator.services.mozilla.com/D52156
--HG--
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
This also moves the 'mach' docs from /python/mach to /mach. The reason being
that 'mach' doesn't really have anything to do with Python other than its
implemented in it.
Differential Revision: https://phabricator.services.mozilla.com/D52253
--HG--
extra : moz-landing-system : lando
Determining link status from states and addresses of the individual interfaces isn't always reliable. With this patch we assume the link is up when we could find a route for kRouteCheckIPv4 host or kRouteCheckIPv6 host.
Differential Revision: https://phabricator.services.mozilla.com/D52027
--HG--
extra : moz-landing-system : lando
Determining link status from states and addresses of the individual interfaces isn't always reliable. With this patch we assume the link is up when we could find a route for kRouteCheckIPv4 host or kRouteCheckIPv6 host.
Differential Revision: https://phabricator.services.mozilla.com/D52027
--HG--
extra : moz-landing-system : lando
This change addresses two issues with vrhost sending WM_MOUSEWHEEL events:
- The point from the message had an incorrect coordinate origin. Documentation specifices that it should be screen, rather than window/client, origin. Since vrhost only knows about a position in the window, it translates the point before sending the message.
- Gecko ignores the point passed in to the window message and instead uses the point from GetMessagePos. As warnings indicate, this can be incorrect, as is exposed with vrhost. This change now uses this point from the message when available.
Differential Revision: https://phabricator.services.mozilla.com/D51322
--HG--
extra : moz-landing-system : lando
There were 3 checks for this preference. Prior to bug 1079355 which ignored the
pref for system principals, the checks were all straightforward pref checks.
The conditionals are somewhat confusing as written. The main idea is the code
inside the blocks only executes if:
- The preference is disabled.
- The RV was success (we don't want to steal error handling, just prevent
success.)
- We're not dealing with the system principal.
As such, I'm removing the full conditional blocks.
Differential Revision: https://phabricator.services.mozilla.com/D51672
--HG--
extra : moz-landing-system : lando
promise rejection event was enabled by default on 69 (bug 1525554).
We could get rid of this preference.
Differential Revision: https://phabricator.services.mozilla.com/D51491
--HG--
extra : moz-landing-system : lando
Behind a pref to ensure that we can turn this off pretty easily if it has perf
impact.
I want to leave the repainting stuff to another bug to land separately, to track
potential (though I hope not!) perf regressions more easily.
Differential Revision: https://phabricator.services.mozilla.com/D50704
--HG--
extra : moz-landing-system : lando
This moves plugin finding logic into a separate class (PluginFinder).
PluginFinder is a runnable. After this commit, there are two ways in which it
can be used:
1. to actually find and load plugins.
2. to check if there have been any changes to plugins.
Although it is a runnable, at this point we still invoke its Run method on the
main thread, so all that's happening is we're separating the "look for plugins
on disk" bits out from everything else.
The goal is to be able to run the IO-intensive FindPlugins (including reading
and writing pluginreg) away from the main thread.
Depends on D48330
Differential Revision: https://phabricator.services.mozilla.com/D48331
--HG--
rename : dom/plugins/base/nsPluginHost.cpp => dom/plugins/base/PluginFinder.cpp
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
This moves plugin finding logic into a separate class (PluginFinder).
PluginFinder is a runnable. After this commit, there are two ways in which it
can be used:
1. to actually find and load plugins.
2. to check if there have been any changes to plugins.
Although it is a runnable, at this point we still invoke its Run method on the
main thread, so all that's happening is we're separating the "look for plugins
on disk" bits out from everything else.
The goal is to be able to run the IO-intensive FindPlugins (including reading
and writing pluginreg) away from the main thread.
Depends on D48330
Differential Revision: https://phabricator.services.mozilla.com/D48331
--HG--
rename : dom/plugins/base/nsPluginHost.cpp => dom/plugins/base/PluginFinder.cpp
extra : moz-landing-system : lando
Lots of these callbacks have a non-`void*` final parameter, which UBSAN
complains about. This commit changes them to have a `void*` parameter.
This requires undoing the machinery added in the first two commits of bug
1473631: `TypePrefChangeFunc` and `PREF_CHANGE_METHOD`. The resulting code is
simpler (which is good) and more boilerplate-y (which is bad) but avoids the
undefined behaviour (which is good).
Differential Revision: https://phabricator.services.mozilla.com/D50901
--HG--
extra : moz-landing-system : lando
Manifest V3 functionality. This applies CSP on the webextension content scripts using either a default csp or an
extension provided csp. It will remain pref'd off but is available for developers to test against, as well as for future
validation of chrome compatibility.
Differential Revision: https://phabricator.services.mozilla.com/D48107
--HG--
extra : moz-landing-system : lando
The idea of these are not to penalize legit uses of scroll anchoring, and
catching pathological cases fast.
The current algorithm I thought of is just whether the average of all the
consecutive scroll anchoring adjustments is less than a given threshold.
If the average adjustment is close to zero and the user is not scrolling, it
means that we're not making much progress.
It is important that zero adjustments don't get counted, since those are common
during window resizes and don't have side-effects anyway.
Exact number may need tuning, let me know if you want it
nightly-and-early-beta-only for now or something.
Depends on D51038
Differential Revision: https://phabricator.services.mozilla.com/D51024
--HG--
extra : moz-landing-system : lando