This patch prevents raptor-youtube-playback-geckoview-live from running on Pixel 2 arm7 builds on mozilla-central.
Differential Revision: https://phabricator.services.mozilla.com/D36935
--HG--
extra : moz-landing-system : lando
In bug 1551961, a WM_NCMOUSELEAVE message handler was added to the Windows widget
backend so that we can detect when the mouse leaves a draggable region (since
draggable regions are hittest'ed as HTCAPTION, and are therefore "non-client").
Inside that message handler, we used the WindowAtMouse handler to determine whether
or not the WM_NCMOUSELEAVE was firing because the mouse was moving off of the
non-client area to client area, or moving out of the window entirely.
For reasons that are not particularly clear, on Windows Aero Glass, when clicking on
one of the min/max/close caption buttons, a WM_NCMOUSELEAVE message fires, and the
::WindowFromPoint call that WindowAtMouse uses causes another WM_NCMOUSELEAVE message
to be queued immediately after, so we end up in this situation where the message
loop is getting spammed by WM_NCMOUSELEAVE messages. Moving the mouse away from
the caption buttons seems to stop the spamming.
We have a function similar to WindowAtMouse called EventIsInsideWindow which
does not use ::WindowFromPoint, and this seems to sidestep the issue, while
being functionally equivalent.
Depends on D37421
Differential Revision: https://phabricator.services.mozilla.com/D37422
--HG--
extra : moz-landing-system : lando
We need to do this in order to not override the mouse cursor that we set in the
widget layer when hit-testing in the non-client region.
We were accidentally overriding before because the PresShell normally queues up a
synthetic mousemove event when the mouse is moving within the client region. That
mousemove cause the EventStateManager to update the cursor to match Gecko's
reckoning of the cursor CSS style of the underlying frame (which overrides the
cursor we may have set in the Windows non-client region hittest - for example,
one of the window resize cursors).
By clearing the mMouseInDraggableArea boolean when transitioning from a draggable
to non-draggable region in the non-client region, we make sure that we process the
WM_MOUSELEAVE message, which sends the eMouseExitFromWidget event into Gecko, which
effectively cancels handling of the synthetic mousemove.
Differential Revision: https://phabricator.services.mozilla.com/D37421
--HG--
extra : moz-landing-system : lando
geckoview-junit now runs on x86_64 opt so we don't need to run the tests on arm
too.
Differential Revision: https://phabricator.services.mozilla.com/D37464
--HG--
extra : moz-landing-system : lando
Allow limited access to the proc_pidinfo() syscall from the Mac utility process sandbox.
Differential Revision: https://phabricator.services.mozilla.com/D37533
--HG--
extra : moz-landing-system : lando
On startup some program binaries are loaded from disk into an
in-memory cache. When we call create_program() we check if the
required program is present in this cache, and if so we call
glProgramBinary(). This is done early on so that the driver can
perform any necessary work in the background.
There may however be binaries in the disk cache that have not yet been
loaded in to memory, in order not to slow down startup. This change
makes it so that we attempt to load missing binaries from disk during
link_program(). The reason we do not do this in create_program() is
because that would result in loading all shaders from disk during
startup, which we want to avoid. Loading these shaders may therefore
take slightly longer than if they'd been loaded at startup, but will
still be much faster than recompiling them from scratch, and startup
will remain quick.
If loading the shaders on startup had previously timed out, then we do
not attempt to load shaders on demand as the disk is probably too slow
for that to be useful.
Depends on D33954
Differential Revision: https://phabricator.services.mozilla.com/D33955
--HG--
extra : moz-landing-system : lando
Webrender caches the program binaries of shaders used within the first
ten frames, so that on next startup it can load them from disk rather
than having to recompile them.
Previously it would load all binaries found in the disk cache on
startup, and when saving to the cache it would delete any existing
binaries that weren't used.
This changes it so that unused binaries are not deleted. The disk
space this requires is insignificant, but as the cache grows loading
all the shaders on startup can get expensive. To solve that we write a
whitelist of the shaders used during startup, and only load those
during the next startup.
Differential Revision: https://phabricator.services.mozilla.com/D33954
--HG--
extra : moz-landing-system : lando
Updating these process-wide prefs at runtime is racy, it was easy to get
into a weird state and we bake in some of these values in JIT code.
Differential Revision: https://phabricator.services.mozilla.com/D37387
--HG--
extra : moz-landing-system : lando
Using process-wide prefs is consistent with the other JIT options and is simpler
to work with (one place to initialize for all runtimes).
Differential Revision: https://phabricator.services.mozilla.com/D37385
--HG--
extra : moz-landing-system : lando
We weren't handling comments at all, which means that having
any in the console would probably make the autocomplete not
working.
This patch handles both inline and multiline javascript comments,
and adds test cases to ensure we don't regress.
Depends on D36573
Differential Revision: https://phabricator.services.mozilla.com/D37196
--HG--
extra : moz-landing-system : lando
Barret Rennie
Kartikaya Gupta
Chris H-C
Gregory Mierzwinski
Andreea Pavel
Aaron Klotz
Mike Conley
dleblanccyr
Agi Sferro
Ciure Andrei
Marco Bonardo
Paul Adenot
Dão Gottwald
Haik Aftandilian
Jamie Nicol
Andreas Pehrson
Jan de Mooij
Razvan Maries
Sylvestre Ledru
Mu Tao
Jean-Yves Avenard
harry
Nicolas Chevobbe
Dorel Luca
Connor Brewster
Jed Davis
gfmcknight
Erica Wright