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
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
So we do it while we're still handling re-entrant changes for SVG, since SVG can
post change hints from UpdateOverflow().
Differential Revision: https://phabricator.services.mozilla.com/D12102
--HG--
extra : moz-landing-system : lando
The code was trying to implement the getOwnPropertyDescriptor trap in terms of
getPropertyDescriptor, by comparing the "holder" object we found to the object
we did the lookup on. This becomes buggy when wrappers like WindowProxy are involved.
The patch removes this check and calls JS_GetOwnPropertyDescriptor instead of
JS_GetPropertyDescriptor.
Differential Revision: https://phabricator.services.mozilla.com/D15091
--HG--
extra : moz-landing-system : lando
The `privateSession` key would normally allow persisting the Private Browsing
session across OOMs in Activity's Bundle.
We need to do that to avoid storing private, sensible data on disk like we do
with the normal browsing session.
In some cases `privateSession` would contain a lot of data which, along with
other possible concurrent transactions could overflow Binder's buffer which has
a limited fixed size, currently 1Mb.
To avoid this, we will drop `privateSession` from the Bundle if the resulting
size is greater than a _speculative_ size of 300KBs which would mean that in
the case of an OOM all Private Browsing state would be lost.
Bug 1515592 is filed to investigate for a better solution.
Differential Revision: https://phabricator.services.mozilla.com/D15067
--HG--
extra : moz-landing-system : lando
In order to support IA2 live regions with e10s (bug 1322532), text change events sent from the child process to the parent process use sync IPC.
That comes at a slight performance cost: the content process is blocked until the parent returns from sending and handling the event.
However, there is no reason to do this if the event is not for an accessible inside a live region; current clients don't need the sync behaviour outside of live regions.
Differential Revision: https://phabricator.services.mozilla.com/D15183
--HG--
extra : moz-landing-system : lando
This patch slightly speedups origin initialization by having a special column in
the database table for current data usage.
This patch also fixes a problem with length computation of some unicode strings.