This way it has a more WebIDL-like signature, which will be helpful in a second.
Differential Revision: https://phabricator.services.mozilla.com/D14357
--HG--
extra : moz-landing-system : lando
Also add an IsElement check in GetElementFromPoint in the APZ code since I think
the element cast is unsound in presence of Shadow DOM.
Differential Revision: https://phabricator.services.mozilla.com/D14355
--HG--
extra : moz-landing-system : lando
In bug 1259382, some workarounds were added to make the build system
alter PATH and not use absolute paths for toolchain programs, because
autoconf and the build system doesn't deal with spaces in those very
well. But later in bug 1290040, we made find_program return Windows
short paths (without spaces), which alleviates the need for those
workarounds.
We still, however, and unfortunately, need to alter PATH to account for
the fact that MSVC DLLs are not necessarily alongside the compiler
executables...
Depends on D15181
Differential Revision: https://phabricator.services.mozilla.com/D15182
--HG--
extra : moz-landing-system : lando
Like for other windows platforms. This currently doesn't make a
difference, but will with next change.
Differential Revision: https://phabricator.services.mozilla.com/D15181
--HG--
extra : moz-landing-system : lando
We remove --disable-libjpeg-turbo because that's only useful when Yasm
is too old, and the required version is now almost 8 years old, so we
can reasonably require people to upgrade rather than workaround with a
--disable option.
The valid_yasm_version function can seem overkill, but that's because
future moves of other things to python configure will pile up.
Differential Revision: https://phabricator.services.mozilla.com/D15184
--HG--
extra : moz-landing-system : lando
If we can't get any sample anymore, the resource might have been closed, so we should change state to 'completedState'.
Differential Revision: https://phabricator.services.mozilla.com/D15029
--HG--
extra : moz-landing-system : lando
Now that we're not even building host static libraries, we don't need
variables for the tools used to build them.
Ironically, we weren't even running HOST_RANLIB.
Depends on D15172
Differential Revision: https://phabricator.services.mozilla.com/D15173
--HG--
extra : moz-landing-system : lando
The build system has skipped creating target static libraries for very
long, except in very specific cases.
We can actually do the same for host static libraries, for which we
don't even need the escape hatch to still allow to create static
libraries.
Depends on D15171
Differential Revision: https://phabricator.services.mozilla.com/D15172
--HG--
extra : moz-landing-system : lando
OBJ_SUFFIX is modified during the profile-generation phase to be i_o
instead of o/obj. _OBJ_SUFFIX is the unmodified value.
We don't actually do PGO for host objects, so we don't need to build the
objects with a different suffix.
Differential Revision: https://phabricator.services.mozilla.com/D15171
--HG--
extra : moz-landing-system : lando
This was necessary back when it still contained a lot of xpcom code, but
shouldn't be necessary now that it only contains two objects.
Differential Revision: https://phabricator.services.mozilla.com/D15168
--HG--
extra : moz-landing-system : lando
So far, the main subject of cross-compiles was to cross compile from one
OS to another (e.g. {linux,osx} -> android), but there are a few useful
cases where the OS doesn't change, and, with --host being guessed, we
can just have developers pass --target=$cpu instead of a complete
target triplet. This can be useful to do x86 Linux builds on x86-64
Linux hosts, or aarch64 Windows builds on x86-64 Windows hosts.
Differential Revision: https://phabricator.services.mozilla.com/D15063
--HG--
extra : moz-landing-system : lando
It turns out all the changes related to --help linting in lint.py make
them unnecessary, and we still can detect missing --help arguments
without them, per test_lint.py. On the flip side, keeping those
need_help_dependency arguments makes some functions executed twice
because some memoized functions end up being called for both cases
need_help_dependency=True and need_help_dependency=False.
Differential Revision: https://phabricator.services.mozilla.com/D15054
--HG--
extra : moz-landing-system : lando
When running `mach help`, mozconfig is loaded multiple times, and even
with an almost empty mozconfig, this makes mach help take close to 10
seconds on my Windows machine.
With some memoization, the time to run mach help gets down to 2s.
Differential Revision: https://phabricator.services.mozilla.com/D15186
--HG--
extra : moz-landing-system : lando
As of bug 1513157, minidump_stackwalk is not installed in the test
docker images, so it needs to be downloaded.
Differential Revision: https://phabricator.services.mozilla.com/D14644
--HG--
extra : moz-landing-system : lando
If video has not been within the potential visible range (which is larger than viewport) yet, its visibility state won't
be updated and would stay in 'UNTRACK'. As those kinds of video are still invisible to users, we don't need to decode
any video frames, we can suspend their video decoding until they're going to be visible.
Differential Revision: https://phabricator.services.mozilla.com/D13804
--HG--
extra : moz-landing-system : lando
The VisualViewport events are all nice and shiny, but unfortunately not quite
what is needed for the session store.
Firstly, the spec wants the "scroll" event to be fired only when the *relative*
offset between visual and layout viewport changes. The session store however
records the absolute offset and as such is interested in when *that* changes.
Secondly, again as per the spec the events don't bubble, and with the default
DOMEventTargetHelper implementation they don't escape the VisualViewport during
capturing, either. This means that any event listener must be added directly on
the VisualViewport itself in order to capture any events.
This might have been intended because the events use the same names as the
normal "scroll"/"resize" events, and as such you cannot specify separate event
listeners for VisualViewport and non-VisualViewport "scroll" events if both
events end up being dispatched to the same element (you can only try to filter
after the fact by looking at the originalTarget of the event).
At the same time, the VisualViewport is attached to the inner Window, and so
each time you navigate, you also get a different VisualViewport object.
All of this might be totally fine from the perspective of a page script, because
in that case you won't care anyway about what happens when the current page goes
away.
From the session store perspective on the other hand (especially Fennec's non-
e10s session store design), this is rather unfortunate because we don't want to
have to keep registering event listeners
a) manually for each subframe
b) each time the page navigates
The event target chain problem could be solved by letting the scroll events
escape the VisualViewport during the capturing phase (which the spec doesn't say
anything about), but this would mean that any scroll listener attached to a
window/browser/... that uses capturing will now catch both layout and visual
viewport scroll events.
In some cases this might even be beneficial, but in others (e.g. bug 1498812
comment 21) I'd like to specifically decide which kind of scroll event to
capture. Having to look at event.originalTarget to distinguish the two kinds
might be defensible in test code, but in case this distinction would be needed
in production code as well, given the existence of a C++-based filtering helper
in nsSessionStoreUtils for another use case where (scroll) events need to be
filtered, JS-based scroll event filtering might be a bad idea.
Additionally, in any case this wouldn't solve the fundamental conflict between
the spec and the session store about *when* the "scroll" event should be fired
in the first place.
Hence I'd like to introduce a separate set of events with distinct event names,
which will be dispatched according to the requirements of our internal users
(i.e. currently the session store). To avoid potential web compatibility issues
down the road, for now these events will be dispatched only to event listeners
registered in the system group (allowing *all* Chrome event listeners cannot be
done because checking the Chrome status of each event target might be too
expensive for frequently dispatched events).
Differential Revision: https://phabricator.services.mozilla.com/D14046
--HG--
extra : moz-landing-system : lando
This changes the semantics of the relative visual viewport offset calculation in
the PresShell slightly, in that a missing root scroll frame will no longer
force the relative offset to zero, even if the visual viewport itself has a non-
zero scroll position [1].
On the other hand, the visual viewport's own relative offset calculations
already work that way today, in that layout and visual viewport scroll positions
are retrieved separately and then subtracted from one another regardless of
whether those values are actually valid or merely a fallback because the
PresShell/scroll frame weren't available.
[1] Though I'm not sure under what circumstances this could really be relevant.
Differential Revision: https://phabricator.services.mozilla.com/D14686
--HG--
extra : moz-landing-system : lando
The semantics of the VisualViewport resize/scroll events aren't quite what is
needed for internal browser usage, so we need a separate set of events that can
be used e.g. by the session store. To avoid future web compatibility issues,
that event should be kept internal, however none of the existing
options to achieve that are suitable:
- mNoContentDispatch can actually end up being dispatched to content after all
and as per its comment preferably shouldn't be used any more for new features
- mOnlySystemGroupDispatchInContent would work perfectly, except that it
shouldn't be used for frequent events, which the resize/scroll events
arguably are
- mOnlyChromeDispatch doesn't work for the Desktop session store's content
script, plus it might have the same performance problems as
mOnlySystemGroupDispatchInContent
Therefore, I propose to introduce a new mOnlySystemGroupDispatch event flag,
which skips the comparatively expensive IsCurrentTargetChrome() check and relies
only on the event listener having been registered in the system group.
Differential Revision: https://phabricator.services.mozilla.com/D14045
--HG--
extra : moz-landing-system : lando
Internally, Gecko stores and updates the *absolute* offset between the visual
viewport and the page, however the spec demands that the scroll event be fired
whenever the *relative* offset between visual and layout viewport changes.
Differential Revision: https://phabricator.services.mozilla.com/D14044
--HG--
extra : moz-landing-system : lando
The event rate throttling mechanism is modelled on the logic for "scroll" events
in nsGfxScrollFrame.cpp.
That is
1. When a request to fire an event is posted to the VisualViewport, we create a
new runnable for this and register it with the RefreshDriver. If we already
have a pending runnable, calling VisualViewport->Post...Event() becomes a
no-op.
2. When the RefreshDriver is ready, it executes the runnable, which in turn
fires the actual event and then cleans itself up.
To keep this patch manageable, we simply fire a scroll event every time the
stored visual viewport offset is changed. Because we are storing the absolute
offset of the viewport relative to the page, this behaviour doesn't match the
spec, which demands that scroll events are fired only when the relative offset
between visual and layout viewport changes. We'll fix this up in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D14043
--HG--
extra : moz-landing-system : lando
This will use the existing APZ basic pan/pinch-zoom tests to check that
scrolling/zooming will also generate the expected visual viewport events.
Because the various scroll-related events are throttled by the refresh driver
and only fire once per tick, merely flushing APZ repaints is no longer enough.
We now have to actually wait for the paints themselves, so we're sure that we've
had an opportunity to receive the corresponding events, too.
Differential Revision: https://phabricator.services.mozilla.com/D14041
--HG--
extra : moz-landing-system : lando
I want to check that panning also triggers the appropriate scroll events, and
that will be easier without callbacks to worry about.
The test has been reorganised after the model given by helper_basic_zoom.html.
Differential Revision: https://phabricator.services.mozilla.com/D14038
--HG--
extra : moz-landing-system : lando
Cristina Coroiu
Sean Stangl
longsonr
Emilio Cobos Álvarez
Jan Varga
Jan de Mooij
Dorel Luca
Mike Hommey
alwu
Michael Froman
Jan Henning
Mark Banner
Eitan Isaacson
Shane Caraveo
Matthew Noorenberghe
Gurzau Raul
Margareta Eliza Balazs
Dão Gottwald
Daniel Holbert