Currently DevTools doesn't do it, but it feels like the right API and is
already there. This allows fixing this on the devtools side however you
want :)
Differential Revision: https://phabricator.services.mozilla.com/D223627
Extend the pageload event to store features used on the root document for better signal-to-noise detection in performance experiments.
This patch uses a bit to record documents in which fetchpriority is used on images.
Data-classification-low: Category 1 “Technical data”
Differential Revision: https://phabricator.services.mozilla.com/D222991
Printing has a weird code-path which doesn't use the refresh driver.
Update frame sizes explicitly, and remove the hack in
nsDisplayRemote::Paint (which is what probably papered over this).
Differential Revision: https://phabricator.services.mozilla.com/D222372
Calling setViewport on a background tab would wait forever without this
tweak after D221995, because we won't resize it until it becomes active.
Some tests like the ones mentioned in comment 12 call newPage() multiple
times at once, and newPage() calls setViewport() if there is a default
viewport set, which triggered this bug.
Make this work by reusing the AppWindow logic for sizing popup windows,
with a tweak so that we also resize background tabs.
Differential Revision: https://phabricator.services.mozilla.com/D222227
This makes resizing the browser generally faster by not resizing
all background tabs at the same time.
This allows to remove special code in the browser to try to avoid
it, too.
Differential Revision: https://phabricator.services.mozilla.com/D221995
Do it at the same time as UpdateRemoteFrameEffects() (so, intersection
observer timing). Otherwise we can see flickering sometimes from the
resize with the previous patch (and this should be less work, when we
resize).
Non-remote frames need to synchronously communicate their resizes
(because JS could access the frame), but that's not an issue for
remote frames.
This should also more reliably prevent issues like bug 1910887 or like
bug 1764655, and paves the way for fixing bug 1750189 (which stalled) in
a similar fashion.
I tested this in a build with a couple hundred tabs open and it doesn't
measurably show up. I think we should consider not communicating resizes
to background tabs / hidden remote iframes, at least for top levels.
Differential Revision: https://phabricator.services.mozilla.com/D221405
This makes resizing the browser generally faster by not resizing
all background tabs at the same time.
This allows to remove special code in the browser to try to avoid
it, too.
Differential Revision: https://phabricator.services.mozilla.com/D221995
Do it at the same time as UpdateRemoteFrameEffects() (so, intersection
observer timing). Otherwise we can see flickering sometimes from the
resize with the previous patch (and this should be less work, when we
resize).
Non-remote frames need to synchronously communicate their resizes
(because JS could access the frame), but that's not an issue for
remote frames.
This should also more reliably prevent issues like bug 1910887 or like
bug 1764655, and paves the way for fixing bug 1750189 (which stalled) in
a similar fashion.
I tested this in a build with a couple hundred tabs open and it doesn't
measurably show up. I think we should consider not communicating resizes
to background tabs / hidden remote iframes, at least for top levels.
Differential Revision: https://phabricator.services.mozilla.com/D221405
Apparently we might not create a subdoc frame for <frame> unless it's
inside <frameset>.
Let's treat it as fully hidden.
Differential Revision: https://phabricator.services.mozilla.com/D221943
What goes on here is that there's a couple of unfortunate style change
sequences which end up making us not do the EffectsInfo dance correctly.
Twitter uses (maybe didn't use to, which would explain the regression) a
visibility: hidden, out-of-flow iframe for a bit (which we correctly
throttle). But then they switch to an in-flow, visible, zero-height
iframe. That we should _not_ throttle. However, we end up not getting to
the display list code at all, because nsBlockFrame decides that we don't
need to descend into an empty line[1].
It seems less error prone to re-use the IntersectionObserver timing and
computation to determine whether the iframe is visible. That completely
matches in-process iframes, too.
Removing the empty frame border and putting them on an empty line in
dom/base/test/test_bug1639328.html is enough to reproduce the issue
without this patch.
[1]: https://searchfox.org/mozilla-central/rev/fe2743c6c5c708061c7f6504b26958fcc815bb4a/layout/generic/nsBlockFrame.cpp#7569-7579
Differential Revision: https://phabricator.services.mozilla.com/D207479
What goes on here is that there's a couple of unfortunate style change
sequences which end up making us not do the EffectsInfo dance correctly.
Twitter uses (maybe didn't use to, which would explain the regression) a
visibility: hidden, out-of-flow iframe for a bit (which we correctly
throttle). But then they switch to an in-flow, visible, zero-height
iframe. That we should _not_ throttle. However, we end up not getting to
the display list code at all, because nsBlockFrame decides that we don't
need to descend into an empty line[1].
It seems less error prone to re-use the IntersectionObserver timing and
computation to determine whether the iframe is visible. That completely
matches in-process iframes, too.
Removing the empty frame border and putting them on an empty line in
dom/base/test/test_bug1639328.html is enough to reproduce the issue
without this patch.
[1]: https://searchfox.org/mozilla-central/rev/fe2743c6c5c708061c7f6504b26958fcc815bb4a/layout/generic/nsBlockFrame.cpp#7569-7579
Differential Revision: https://phabricator.services.mozilla.com/D207479
This is still fairly incomplete (i.e. no capturing, etc), but it allows
a transition to "start", and then finish (on the next frame always, for
now) or timeout, appropriately.
I think it's in a reviewable shape, given that. There's one known
divergence from the spec, which is described in
https://github.com/w3c/csswg-drafts/issues/10822
Differential Revision: https://phabricator.services.mozilla.com/D220843
This is still fairly incomplete (i.e. no capturing, etc), but it allows
a transition to "start", and then finish (on the next frame always, for
now) or timeout, appropriately.
I think it's in a reviewable shape, given that. There's one known
divergence from the spec, which is described in
https://github.com/w3c/csswg-drafts/issues/10822
Differential Revision: https://phabricator.services.mozilla.com/D220843
When there's trailing garbage after an @import rule we throw, but we
still trigger the load (that's not great but not trivial to change).
Deal with that case before calling ImportRuleLoaded().
Differential Revision: https://phabricator.services.mozilla.com/D219783
