Differential Revision: https://phabricator.services.mozilla.com/D57954

--HG--
extra : moz-landing-system : lando

Bug 981248 - Fix test_input_number_mouse_events.html to not dispatch mouse events from input events. r=masayuki

The test fails with my <input type=number> rewrite because editor fails to
dispatch one input event caused by these mouse events.

The reason for this is that we schedule them from an input event, which fires
from here:

  https://searchfox.org/mozilla-central/rev/6305f6935f496b3a302c7afcc579399a4217729c/editor/libeditor/EditorBase.cpp#965

Not how at that point we still haven't decremented mPlaceholderBatch. That means
that other stuff that triggers input events from there will not dispatch events.

I think that's a bit unexpected, but it is a preexisting problem, and can't
happen for users because mouse events go through the event loop.

Differential Revision: https://phabricator.services.mozilla.com/D57810

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D57631

--HG--
extra : moz-landing-system : lando

Bug 1604511 - [1.2] Ensure Autofill.Support is fully initialized before handling events and enforce UI thread only access. r=geckoview-reviewers,agi,snorp

Differential Revision: https://phabricator.services.mozilla.com/D57507

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D54900

--HG--
extra : moz-landing-system : lando

Bug 1600267: part 8) Call `ComparePoints` instead of `ComparePoints_Deprecated` in Selection. r=smaug

Some calls to `ComparePoints_Deprecated` remain, because adapting them
would require to add boilerplate code, which potentially will be deleted
again once `ComparePoints` supports crossing the Shadow DOM boundary.

Differential Revision: https://phabricator.services.mozilla.com/D57615

--HG--
extra : moz-landing-system : lando

The closed-over-binding data is generated for each scope with a nullptr
delimiter per scope. This is wasteful when there are no closed-over bindings.
This patch removes trailing nullptr entries and for leaf-functions may result
in the script-data allocation being avoided altogether.

The FullParseHandler::nextLazyClosedOverBinding() will return nullptr after
the end of the gcthings data so that the delazification process is otherwise
unchanged.

Differential Revision: https://phabricator.services.mozilla.com/D57885

--HG--
extra : moz-landing-system : lando

Move the transcoding from XDRLazyScript and XDRRelazificationInfo into
LazyScript::XDRScriptData to avoid duplication. Add similar code for non-lazy
scripts for consistency.

Depends on D57919

Differential Revision: https://phabricator.services.mozilla.com/D57920

--HG--
extra : moz-landing-system : lando

Depends on D57918

Differential Revision: https://phabricator.services.mozilla.com/D57919

--HG--
extra : moz-landing-system : lando

Depends on D57917

Differential Revision: https://phabricator.services.mozilla.com/D57918

--HG--
extra : moz-landing-system : lando

We had a few extra RootedFunction when we only cared if about if the pointer
was null or not, so lets remove them. Also rename to isFunctionScript since
this is called for stand-alone functions as well. Semantics should be
unchanged.

Depends on D57862

Differential Revision: https://phabricator.services.mozilla.com/D57917

--HG--
extra : moz-landing-system : lando

Pass appropriate arguments to NewFunctionWithProto instead of filling them
after the fact. The script should be transcoded after the function is set up.
Also stop preserving the NEW_SCRIPT_CLEARED flag in XDR.

Differential Revision: https://phabricator.services.mozilla.com/D57862

--HG--
extra : moz-landing-system : lando

Also add this helper to FunctionBox for consistency.

Depends on D57852

Differential Revision: https://phabricator.services.mozilla.com/D57853

--HG--
extra : moz-landing-system : lando

Cleanup the aliases we use for constructing different types of functions.
Always specify the function kind explicitly for readability.

Depends on D57851

Differential Revision: https://phabricator.services.mozilla.com/D57852

--HG--
extra : moz-landing-system : lando

Fix the formatting, commenting, ordering of the flags. Also move the function
kind bits to the beginning of the flag word.

Differential Revision: https://phabricator.services.mozilla.com/D57851

--HG--
extra : moz-landing-system : lando

The ReflowTracker was based on the assumption that there was only ever going to
be one target to be observed.
With Fission, this is no longer true.
Turning the ReflowTracker into something that is multi-target aware seemed more
complex than really worth it. After all, all it was doing is getting a ReflowFront
and listening for events on it.
The only 3 things that needed it are the grid inspector, flex inspector and box
model widget. They all needed it for the same reason: updating the data displayed
in the UI when the size/geometry/box-model regions of the selected node changed.
So, it seems simpler to let the inspector instantiate the right ReflowFront when
it needs it (upon a new node selection).
There's only one node selected at any given time in the inspector, so it's simple
to just listen for reflow in that node's target, and dispatch events to the grid,
flex and box-model tools so they can update themselves.

Note that once a new node is selected, we do the `getFront("Reflow")` again
since that node can be in a different target than the previous one. If it is,
however, in the same target, then `getFront` will return the same instance which
is nice.

Differential Revision: https://phabricator.services.mozilla.com/D55987

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D56300

--HG--
extra : rebase_source : 86d8b0fa5774d0313c81df74b563aac459b78424
extra : intermediate-source : f619147af86350ab10427506b5f9a2b1b7c1acbc
extra : source : ba6f7b326c95cd868ae261a6c2fd66bd1eb1a6a6

--HG--
extra : histedit_source : 5d8a598ca6fe4b35721e10b3f46baf2aab57d238

--HG--
extra : histedit_source : 00ee1014f86a55b3fe9c4e2df272bad8edcd988c

Talkback users expect that when you navigate past the end of the text in a node, Talkback will move into the next node and navigate there.
However, even though text navigation is async (client performs an action on the focused accessible and then waits for a text traversal event), firing a traversal event with a different accessible from the focused accessible is not supported by Talkback.
Firing a11y focus on the new node (as we did previously) doesn't fix this, but instead causes the entire node to be reported, among other weird behaviour.

1. Don't fire a11y focus for text traversal.
    Aside from Talkback reporting the entire node, this was also confusing Talkback, causing it to try to navigate several times into the new node.
2. When navigating text, cache whether we're at either edge.
    We do this because we need to be able to synchronously query whether we're at the edge, but we do navigation async.
    Special handling is needed for words at the end because words don't include trailing space.
3. When performing a text navigation action, check if we're already at the edge using the cache described above.
    If we are, synchronously return false, as Talkback expects.
    Talkback will then move to the next/previous node itself and navigate the text there.

Differential Revision: https://phabricator.services.mozilla.com/D57926

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D57441

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D57792

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D57785

--HG--
extra : moz-landing-system : lando

This is the last part needed to be able to restrict results without an explicit
typed token (either restriction or alias). Note this is all preparatory work,
there isn't a design for a feature using this yet, but we know at a certain
point we want a more usable representation of aliases and restriction tokens
and eventually a mode picker UI (search button).

Differential Revision: https://phabricator.services.mozilla.com/D57781

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D57914

--HG--
extra : moz-landing-system : lando

These currently are Mozilla-only but can be trivially moved into upstream
tests once there is agreement to take the feature.



Depends on D57472

Differential Revision: https://phabricator.services.mozilla.com/D57473

--HG--
extra : moz-landing-system : lando

Add a WebDriver:Print command to marionette, following the proposed
WebDriver spec at https://github.com/w3c/webdriver/pull/1468
The implementation is largely the same as that added to the
remote agent in Bug 1599994.



Depends on D57471

Differential Revision: https://phabricator.services.mozilla.com/D57472

--HG--
extra : moz-landing-system : lando

Depends on D56444

Differential Revision: https://phabricator.services.mozilla.com/D57471

--HG--
extra : moz-landing-system : lando

Implement /session/<session id>/moz/print endpoing in GeckoDriver, corresponding
to the proposed spec at https://github.com/w3c/webdriver/pull/1468.

Differential Revision: https://phabricator.services.mozilla.com/D56444

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D56694

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D57933

--HG--
extra : moz-landing-system : lando

This is exactly the kind of test that makes no sense once we have finished
the rework of RDM (to be embedded into the browser UI). Indeed, once done,
there won't be a nested iframe in RDM through which we need to make sure
all messages that lead to the tab status/title/icon (and many other things)
are forwarded.

So, because this test currently fails with fission, let's just disable it
for now when in fission mode, and then once the RDM project is done, let's
delete it entirely. No use spending time making it work now if we're going
to remove it later.

Differential Revision: https://phabricator.services.mozilla.com/D57758

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D57814

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D57799

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D56442

--HG--
extra : moz-landing-system : lando

Bug 1570499 - Part 2: Suppress -Wimplicit-fallthrough warnings from third-party udis86 code. r=froydnj

ProcessRedirect.cpp includes third-party udis86 C code that triggers -Wimplicit-fallthrough warnings. We suppress these warnings in ProcessRedirect.cpp because we want to minimize Mozilla changes to third-party code and we can't use C++17's [[fallthrough]] attribute in C code anyway. We don't suppress the warnings for the entire ProcessRedirect.cpp file (e.g. in moz.build) because we'd like clang -Wimplicit-fallthrough to check ProcessRedirect.cpp's own use of [[fallthrough]].

This changeset reverts some earlier Mozilla changes [1] made to upstream udis86's decode.c [2] that are no longer necessary.

[1] https://hg.mozilla.org/mozilla-central/rev/9042673fb235c00fbb021ea6356f4b0921505d1d
[2] https://github.com/vmt/udis86/blob/master/libudis86/decode.c#L747

Differential Revision: https://phabricator.services.mozilla.com/D56441

--HG--
extra : moz-landing-system : lando

Bug 1570499 - Part 1: Replace MOZ_FALLTHROUGH macro with C++17's [[fallthrough]] attribute. r=froydnj

This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.

Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:

* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.

Differential Revision: https://phabricator.services.mozilla.com/D56440

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D56722

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D57875

--HG--
extra : moz-landing-system : lando