To do this we change the timing at which ResizeObserver fires with
respect to the refresh driver last layout update, which is what the spec
says to do, in order for the focus fixup rule to fire after
ResizeObserver.
Bug 1790150 would make this more explicit.
Differential Revision: https://phabricator.services.mozilla.com/D156219
To do this we change the timing at which ResizeObserver fires with
respect to the refresh driver last layout update, which is what the spec
says to do, in order for the focus fixup rule to fire after
ResizeObserver.
Bug 1790150 would make this more explicit.
Differential Revision: https://phabricator.services.mozilla.com/D156219
I couldn't reproduce this, but this matches the specification.
https://drafts.csswg.org/resize-observer/#html-event-loop:
1. Recalc styles
2. Update layout
3. Set depth to 0
4. Gather active observations at depth depth for Document
5. Repeat while document has active observations
2. Set depth to broadcast active observations.
3. Recalc styles
4. Update layout
5. Gather active observations at depth depth for Document
This matches the spec, tweaked a bit to avoid duplication.
I haven't been able to reproduce the original issue, but flushing
upfront should make sure that delayed resizes are processed given we
flush the browsing context tree in pre-order.
Differential Revision: https://phabricator.services.mozilla.com/D155064
It's possible to observe an element in the iframe while the
ResizeObserver object lives in the outer document, so we have to make
sure we also schedule the observer for all documents in the same
BrowsingContext tree.
Differential Revision: https://phabricator.services.mozilla.com/D119843
The observers take care of unregistering when they need to. Instead,
make the ResizeObservation keep the element alive just like
nsMutationReceiver keeps the mutation observer alive.
Differential Revision: https://phabricator.services.mozilla.com/D118477
The observers take care of unregistering when they need to. Instead,
make the ResizeObservation keep the element alive just like
nsMutationReceiver keeps the mutation observer alive.
Differential Revision: https://phabricator.services.mozilla.com/D118477
This patch factors the DOM related sizes in nsWindowSizes to its own
struct, such that callers can easily acess DOM memory sizes.
Differential Revision: https://phabricator.services.mozilla.com/D111317
This changes the way we deal with page use counters so that we can
handle out of process iframes.
Currently, when a parent document is being destroyed, we poke into all
of the sub-documents to merge their use counters into the parent's page
use counters, which we then report via Telemetry. With Fission enabled,
the sub-documents may be out of process. We can't simply turn these
into async IPC calls, since the parent document will be destroyed
shortly, as might the content processes holding the sub-documents.
So instead, each document during its initialization identifies which
ancestor document it will contribute its page use counters to, and
stores its WindowContext id to identify that ancestor. A message is
sent to the parent process to notify it that page use counter data will
be sent at some later point. That later point is when the document
loses its window. It doesn't matter if the ancestor document has
already been destroyed at this point, since all we need is its
WindowContext id to uniquely identify it. Once the parent process has
received all of the use counters it expects to accumulate to a given
WindowContext Id, it reports them via Telemetry.
Reporting of document use counters remains unchanged and is done by each
document in their content process.
While we're here, we also:
* Limit use counters to be reported for a pre-defined set of document
URL schemes, rather than be based on the document principal.
* Add proper MOZ_LOG logging for use counters instead of printfs.
Differential Revision: https://phabricator.services.mozilla.com/D87188
The key here is to test the type of the variable declaration for being a
smartptr type, instead of testing the type of the variable _use_.
Differential Revision: https://phabricator.services.mozilla.com/D65581
--HG--
extra : moz-landing-system : lando
In Notify(), we should guarantee that the inner window we get is for the
document, and avoid using null outer window pointer.
Differential Revision: https://phabricator.services.mozilla.com/D35727
--HG--
extra : moz-landing-system : lando
Need to write a test for this. Also, as a matter of preventive measure, null out
mOwner when it dies.
That may matter in the case where the controller dies while the observer is
getting notified. In that case, somebody still keeps a reference to the
controller. Right now is fine because nothing will touch it again (the
destructor doesn't), but that's not great, and it's better to just clear the
pointer.
Differential Revision: https://phabricator.services.mozilla.com/D29395
--HG--
extra : moz-landing-system : lando
Use ResizeObserverController to schedule the observers and manage them.
Document will hold this controller in the later patch.
Depends on D27616
Differential Revision: https://phabricator.services.mozilla.com/D27617
--HG--
extra : moz-landing-system : lando
Use ResizeObserverController to schedule the observers and manage them.
Document will hold this controller in the later patch.
Depends on D27616
Differential Revision: https://phabricator.services.mozilla.com/D27617
--HG--
extra : moz-landing-system : lando