The grammar changes parallel those in https://github.com/heycam/webidl/pull/700
We don't prevent having both a constructor operation and [Constructor] or
[ChromeConstructor], because those extended attributes are about to get
removed, once they are no longer used in our IDL.
Differential Revision: https://phabricator.services.mozilla.com/D45387
--HG--
extra : moz-landing-system : lando
Took care to only call .task once. Maybe it would be nice to move this functionality inside `WorkerDispatcher`?
Differential Revision: https://phabricator.services.mozilla.com/D45534
--HG--
extra : moz-landing-system : lando
Existing tests will fail when there are more than 1 pending frames when Drain()
is called. Repeatly calling it to ensure all frames will be collected.
Differential Revision: https://phabricator.services.mozilla.com/D43689
--HG--
extra : moz-landing-system : lando
Some existing functions that manipulates H.264 bitstream already cover
most of the efforts for converting Android encoder output. With some minor
changes, they can be called by the encoder to avoid code duplications.
Differential Revision: https://phabricator.services.mozilla.com/D43686
--HG--
extra : moz-landing-system : lando
This reverts the available memory tracker back to its old implementation that
relied on GlobalMemoryStatusEx() instead of the potentially expensive
K32GetPerformanceInfo(). In spite of its name GlobalMemoryStatusEx() may return
per-process values instead of global ones which might lead to underestimating
the actual memory pressure. Because of this limitation this change is a
stop-gap while we replace this code with a non-polling implementation based on
QueryMemoryResourceNotification().
Differential Revision: https://phabricator.services.mozilla.com/D45338
--HG--
extra : moz-landing-system : lando
Accessing `offsetXXX` attributes of element, it would trigger reflow, and sometime it would result in a re-entry of `processCue()` because we would call `processCue()` when `resizecaption` occurs.
One specifical case is that, assigning CSS properties `min-width` and `max-width` at the same video element, in thise case, when we re-enter the `processCues()` and access `offsetXXX`. It seems that the layout system would reprocess those properites again and again and dispatch `resizecaption` when we access `offsetXXX`, which causes an infinite loop, starting from receving `resizecaption`, then calling `processCue()`, accessing `offSetXXX`, triggering reflow, sending `resizecaption` event again.
Therefore, we should stop revisiting `processCues()` if we're already running a processing, we should run a processing once at a time.
Differential Revision: https://phabricator.services.mozilla.com/D45421
--HG--
extra : moz-landing-system : lando
Took care to only call .task once. Maybe it would be nice to move this functionality inside `WorkerDispatcher`?
Differential Revision: https://phabricator.services.mozilla.com/D45534
--HG--
extra : moz-landing-system : lando
The parent process usually starts a native drag session during the processing
of a Gecko mouse move event while the mouse is down. Usually, these Gecko mouse
move events are processed synchronously during -[ChildView mouseDragged:]. But
in some cases, the Gecko mouse move event can be a synthetic mouse move event
that was generated in response to a reflow. Those get processed during refresh
driver ticks, which run at a time that's completely unrelated to when
mouseDragged is invoked.
So the widget should just assume that drags can be started at any time between
mouseDown and mouseUp.
Differential Revision: https://phabricator.services.mozilla.com/D36151
--HG--
extra : moz-landing-system : lando
This might be necessary since we fail to load the second blank page in 500 ms all the times
Differential Revision: https://phabricator.services.mozilla.com/D45474
--HG--
extra : moz-landing-system : lando
We fail to release component manager in content process, which should has nothing to do with COOP implemetation
Differential Revision: https://phabricator.services.mozilla.com/D45260
--HG--
extra : moz-landing-system : lando
For popup windows with parent we need to get scale factor of the parent
window. Because when the windows are hidden they're not receiving updates
about changing scaling factor. So when moving from normal dpi to
the hidpi monitor the newly opened popup windows will have the same scale.
Differential Revision: https://phabricator.services.mozilla.com/D45649
--HG--
extra : moz-landing-system : lando