This is what other browsers do, and it does make sense to me, it's useless to
try to scroll a frame with no scroll range in a given direction.
I think all callers of this function should be treated like this, so this is
more like a RFC / feedback request than a patch per se.
The wheel handling code already checks scroll range, so there's no difference of
behavior in that case, if I'm reading the code right.
There are a few other functions that check the result of
GetPerceivedScrollingDirections(), but I think if we change this we should
change this consistently.
I also think that if we do this we should rename the method to something like
GetAvailableScrollingDirections() or such.
Anyhow, wdyt? I should also add a test for this if we go with this.
Differential Revision: https://phabricator.services.mozilla.com/D38991
--HG--
extra : moz-landing-system : lando
At a high level, this change does the following:
- move the pluginchild actor to be a JSWindowActorChild
- move the parent handling from browser-plugins into a JSWindowActorParent
- move the crash handling from ContentCrashHandlers.jsm to the parent actor,
using a `PluginManager` object. It needs to talk to the actors (and vice
versa), so this seemed a better fit than spreading actor implementation
details to other JSMs.
- switch to using plugin IDs to identify plugins cross-process, instead of
combinations of names or other properties of the plugin tag. As part of that,
ensured plugin IDs are unique between "fake" plugins and the other ones.
- drop support for having a notification for more than 1 plugin. We only support
Flash, in practice, so there didn't seem to be much point in the added
complexity of trying to support more than 1 thing.
Some notes:
- the previous implementation mixes runIDs (for NPAPI plugin process "runs")
and GMP pluginIDs when doing crashreporting. AFAICT there is no guarantee
these don't conflict, so I've split them out to avoid issues. There's a
pluginCrashID object I pass around instead that has either a runID or
pluginID. Happy to rename some more for clarity.
- the previous implementation used `pluginInfo` and `plugin` for a bunch of
different types of variables. I've tried to be consistent, where:
* `pluginElement` is a DOM element for a plugin
* `activationInfo` is a JS object used to track click to play state for a plugin
* `plugin` is a plugintag as returned by the pluginhost service
* `pluginCrashID` is an identifier for a crashed plugin (see previous point).
- I'm still using broadcastAsyncMessage to tell the content processes about
gmp plugin crashes and plugin crash submission updates, because there's no
guarantee the actors are instantiated (for gmp plugins) nor can the parent
easily find out which actors to talk to (for either gmp or npapi plugins).
Open to suggestions there, too. I think our best bet might be moving that to
IPDL-based IPC within the GMP code, but that feels like a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D37665
--HG--
rename : browser/base/content/browser-plugins.js => browser/actors/PluginParent.jsm
extra : moz-landing-system : lando
This mechanical transform lays the foundation for generalizing the
underlying test runner.
Differential Revision: https://phabricator.services.mozilla.com/D37132
--HG--
extra : moz-landing-system : lando
This is the equivalent of .pth in virtualenv declarations. It sets up
a .egg file with a `sys.path` addition, as far as I can tell.
Differential Revision: https://phabricator.services.mozilla.com/D37131
--HG--
extra : moz-landing-system : lando
mozharness and mozharness test transforms for generic-worker currently
don't wrap the commands with run-task. This changes things such that the
commands are wrapped with run-task, by piggy-backing on the run_task
transform.
Some things then become redundant with what the run_task transform does,
and some others need to happen later than they currently do in order to
work.
Depends on D28026
Differential Revision: https://phabricator.services.mozilla.com/D28027
--HG--
extra : moz-landing-system : lando
This mechanical transform lays the foundation for generalizing the
underlying test runner.
Differential Revision: https://phabricator.services.mozilla.com/D37132
--HG--
extra : moz-landing-system : lando
This is the equivalent of .pth in virtualenv declarations. It sets up
a .egg file with a `sys.path` addition, as far as I can tell.
Differential Revision: https://phabricator.services.mozilla.com/D37131
--HG--
extra : moz-landing-system : lando
This patch fixes the CSS rule for displaying the disabled tracking
protection icon when TP is off.
Differential Revision: https://phabricator.services.mozilla.com/D38668
--HG--
extra : moz-landing-system : lando
Now that we have built up the required primatives in previous patches, this
patch simply replaces the previous code with a new version that uses the new
APIs from ShellHeaderOnlyUtils.h.
Differential Revision: https://phabricator.services.mozilla.com/D38945
--HG--
extra : moz-landing-system : lando
For the URI handling case, we still want to parse the URI to look for any
malformation. OTOH, IShellDispatch2::ShellExecute does not accept PIDLs as
arguments, we we need an overload that converts the absolute PIDL back to a
path for the purposes of passing on to that interface.
Differential Revision: https://phabricator.services.mozilla.com/D38944
--HG--
extra : moz-landing-system : lando
This is just so that both the launcher process and other Gecko code can share
this method.
Differential Revision: https://phabricator.services.mozilla.com/D38943
--HG--
extra : moz-landing-system : lando
When I added TIOracle.cpp, this missing header broke the unified ARM build. (We don't test non-unified ARM builds by default.)
Differential Revision: https://phabricator.services.mozilla.com/D38729
--HG--
extra : moz-landing-system : lando
Got rid of the per-thread JSContext created at the start of each thread. Tasks that require JSContext (ParseTasks, IonBuilder, Wasm tier 2 generators, GCParallel) now request an unused context to set to their thread. Tasks which do not use JSContext will not request one.
Differential Revision: https://phabricator.services.mozilla.com/D37495
--HG--
extra : moz-landing-system : lando
Created a vector of JSContext*, initialized at creation of GlobalHelperThreadState, destroyed when GlobalHelperThreadState.finish() is called. Note that this implementation makes the assumption that the creation and destruction of these objects always happens in the same order (helper thread state created -> main thread context created -> main thread context destroyed -> helper thread state destroyed). In this scenario context checks can clear by each context claiming the main thread during its ctor/dtor but this is only possible if the main thread context is not set at the time.
Also, removed GlobalHelperThreadState::lock() and unlock(), as they are not being used - AutoLockHelperThreadState is used instead.
Differential Revision: https://phabricator.services.mozilla.com/D36842
--HG--
extra : moz-landing-system : lando
Created SetThread/ClearThread functions to handle JSContext/tid setting/clearing & updated existing implementation of JSContext to reflect. CurrentThread is ContextData because JSContext should already have a "claim" on the thread if it's clearing these.
Differential Revision: https://phabricator.services.mozilla.com/D36836
--HG--
extra : moz-landing-system : lando
Remove the uneeded XULDocument check so that when textbox elements are
loaded in XHTML documents the inline spell checker UI works.
Differential Revision: https://phabricator.services.mozilla.com/D38690
--HG--
extra : moz-landing-system : lando
Bug 1561547 introduces an SVG resource document in the UI in a way that the pref
changed callback ends up being called for that document _before_ being called for
the main document.
Given mDeviceContext is shared, it's a bug to depend on the return value of the
CheckDPIChange call, since then we only properly update the first document that
gets notified.
Differential Revision: https://phabricator.services.mozilla.com/D38974
--HG--
extra : moz-landing-system : lando
Bug 1547135 added functionality to configure specific Android devices
for performance tests. That code landed as part of device setup in
`testing/raptor/raptor.py` but there is nothing Raptor-specific
(indeed, nothing harness-specific) about this configuration.
Rather than lift it to `mozdevice`, this commit moves it into a
`performance_tuning` module. That's enough to slim down `raptor.py`.
Differential Revision: https://phabricator.services.mozilla.com/D37128
--HG--
extra : moz-landing-system : lando
The reftest-paged tests don't trigger the document clone code-path (I realized
that after writing them), but I guess they don't hurt, the printpreview test
does fail without the previous patch.
Depends on D39053
Differential Revision: https://phabricator.services.mozilla.com/D39054
--HG--
extra : moz-landing-system : lando
So that the styleset and CSS loader react appropriately.
Bug 1535788 causes the styleset to be created earlier, so it stopped grabbing the
already-updated compat mode.
I think the CSS loader stuff could already cause some issues before bug 1535788,
for what is worth.
Differential Revision: https://phabricator.services.mozilla.com/D39053
--HG--
extra : moz-landing-system : lando
In the first version of this code, we assumed that a non-empty typeset implied that we had already executed this opcode, so the intrinsic must already exist and its type must have already been added to the typeset. We added an assertion to justify the assumption.
In bug 1000780, we improved jsop_intrinsic to check for the intrinsic's existence, because it might have been created elsewhere. The assertion remained, even though we were no longer depending on it for correctness.
The new monitorType testing function gives us another way to add to type sets, making it possible for the typeset in jsop_intrinsic to contain something other than the type of the intrinsic. That doesn't cause any correctness issues, so the right fix is just to remove the assertion and adjust the surrounding logic accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D38697
--HG--
extra : moz-landing-system : lando
Support for coping link location from within the Console panel (through the context menu) can be extended and cover learn more links too.
Differential Revision: https://phabricator.services.mozilla.com/D38546
--HG--
extra : moz-landing-system : lando
* Add a new case for when suggest.bookmark = false to the logic that returns the appropriate SQL query. Don't autofill bookmarks in that case.
* Add a bunch of new tests that cover all cases
Differential Revision: https://phabricator.services.mozilla.com/D38394
--HG--
extra : moz-landing-system : lando
Browsers who already have text-decoration-skip-ink implemented will currently
fail [or spuriously pass] these tests because the feature is on by default and
the Ahem font is "ink-heavy", causing underlines and overlines to not show up
at all. The added text-decoration-skip-ink: none; line will ensure that an
underline or overline will be rendered whether or not skip-ink has been
implemented.
Differential Revision: https://phabricator.services.mozilla.com/D38949
--HG--
extra : moz-landing-system : lando
* Move AddressBar.rst into a new browser/components/urlbar/docs directory
* Break it up into several files, which makes the patch look way bigger than it really is because I used `hg cp` to preserve blame
* Add an Experiments & Extensions file/subsection, to be written later
* Rewrite the intro a little for wording and also to reflect the fact that quantumbar has shipped, and also tweak the wording of some subsection titles
Differential Revision: https://phabricator.services.mozilla.com/D38938
--HG--
rename : browser/docs/AddressBar.rst => browser/components/urlbar/docs/contact.rst
rename : browser/docs/AddressBar.rst => browser/components/urlbar/docs/debugging.rst
rename : browser/docs/AddressBar.rst => browser/components/urlbar/docs/overview.rst
rename : browser/docs/AddressBar.rst => browser/components/urlbar/docs/telemetry.rst
rename : browser/docs/AddressBar.rst => browser/components/urlbar/docs/utilities.rst
extra : moz-landing-system : lando
The args count needs to be set before the LazyScript takes hold of the
functionbox, or else some code that references lazy functions can get the wrong
number of arguments (ie, CloneFunctionObjectIfNotSingleton on a lazy function)
Differential Revision: https://phabricator.services.mozilla.com/D36984
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Gijs Kruitbosch
mcrawford@mozilla.com
Nick Alexander
Narcis Beleuzu
championshuttler
Mike Hommey
Tim Huang
Matthew Gregan
Aaron Klotz
Iain Ireland
Kristen Wright
Brendan Dahl
Boris Zbarsky
Armando Ferreira
Edwin Gao
Micah Tigley
Jan-Ivar Bruaroey
Drew Willcoxon
Belén Albeza
Charlie Marlow
Daniel Holbert
Tim Nguyen
Johann Hofmann
Matthew Gaudet
Ryan VanderMeulen