Instead of starting transitions and animations as a result of a paint,
use the refresh driver tick to do this.
This sets the transition-ready time to the current time during the next
refresh driver tick that it was started on (see mSawTickWhilePending).
This is similar to what's described in the bugs comments, and seems to
work nicely in practice.
We could easily change that (current time) by a paint-based time if
needed (when available), which would be more similar to what we were
doing. But I'd rather do the simple thing for now, and land this shortly
after the soft freeze is over so that we have time to watch out for
regressions.
There's one regression on a test that birtles wrote (using an XHR doc
and switching the timeline to a rendered doc's timeline).
We use the timeline's document rather than the target document to
determine whether to trigger animations now. That's one of the cases
where we'd keep vsync perma-running without this patch, and Chrome also
fails that test. Maybe the test should be removed / the spec should be
tweaked to allow this behavior?
This causes some progression in some CSS transitions tests too, and I
added an extra test for the vsync behavior.
Over-all this is much simpler to reason about and I think we should try
to do this.
Differential Revision: https://phabricator.services.mozilla.com/D193583
There might be multiple LCP entries in a web page, and we only care about the
last one which is also the biggest value. That's why we need to record these
values in two different places:
- During the Document unload, so we can add markers for the closed pages.
- During the profile capture, so we can add markers for the open pages.
This allows us to capture all the LCP values. Note that this is not the case
for other metrics like FCP, TTFB, DOMContentLoaded etc. that fires only once.
Differential Revision: https://phabricator.services.mozilla.com/D192828
There might be multiple LCP entries in a web page, and we only care about the
last one which is also the biggest value. That's why we need to record these
values in two different places:
- During the Document unload, so we can add markers for the closed pages.
- During the profile capture, so we can add markers for the open pages.
This allows us to capture all the LCP values. Note that this is not the case
for other metrics like FCP, TTFB, DOMContentLoaded etc. that fires only once.
Differential Revision: https://phabricator.services.mozilla.com/D192828
There might be multiple LCP entries in a web page, and we only care about the
last one which is also the biggest value. That's why we need to record these
values in two different places:
- During the Document unload, so we can add markers for the closed pages.
- During the profile capture, so we can add markers for the open pages.
This allows us to capture all the LCP values. Note that this is not the case
for other metrics like FCP, TTFB, DOMContentLoaded etc. that fires only once.
Differential Revision: https://phabricator.services.mozilla.com/D192828
This requires moving some code around to PreferenceSheet, but that makes
stuff actually a bit simpler.
Depends on D192574
Differential Revision: https://phabricator.services.mozilla.com/D192575
This matches the behavior of other browsers, and avoids having to keep
alive the link element and thus associated document etc for too long.
Differential Revision: https://phabricator.services.mozilla.com/D192834
Instead, use forced-color-adjust: none to disable HCM forced colors in
DevTools, for now. It's a more straight-forward way of doing it.
Differential Revision: https://phabricator.services.mozilla.com/D192669
The event isn't dispatched correctly for DOM manipulations anymore. It is
dispatched when swapping docshells but we don't actually use this event anywhere
except tests so we might as well just remove it entirely.
Differential Revision: https://phabricator.services.mozilla.com/D192333
I realized that our `HTMLEditUtils::IsFormatNode` is not maintained different
from the other browsers. Therefore, only we do not check new elements defined
after HTML 4.01. This patch aligns the list of the format elements to the
others [1].
Then, this also changes some expectations of `editing/run/formatblock.html`
to align common behavior of the browsers.
Note that we mapped `formatBlock` of `execCommand` to `cmd_paragraphState`,
and the XUL command handles `<blockquote>` in a different path [2] and the
behavior is pretty different from the other formatBlock command implementations.
Therefore, this patch creates new command for `formatBlock` and makes
`HTMLEditor` switch behavior in any places.
1. ba50f40fc4:third_party/WebKit/WebCore/editing/FormatBlockCommand.cpp;l=114-134
2. https://searchfox.org/mozilla-central/rev/6602bdf9fff5020fbc8e248c963ddddf09a77b1b/editor/libeditor/HTMLEditor.cpp#2461-2474
Differential Revision: https://phabricator.services.mozilla.com/D190900
This patch removes the old docshell timeline and timeline markers codebase and replaces them with equivalent Gecko profiler marker. This patch also fixes Bug 1834143, which is a subset of 1421651.
Differential Revision: https://phabricator.services.mozilla.com/D184217
This patch removes the old docshell timeline and timeline markers codebase and replaces them with equivalent Gecko profiler marker. This patch also fixes Bug 1834143, which is a subset of 1421651.
Differential Revision: https://phabricator.services.mozilla.com/D184217
Initial implementation for <iframe loading=lazy>
Also cleaned up some image lazy loading to be generalised
(sharing an intersection observer and some enums/funcs in Element).
Unimplemented details:
- Window load should not wait for in view lazy loading iframes.
Unplanned for this patch and ship for now.
(Chromium fail, WebKit pass)
We also pass some other WPTs other engines do not too already too.
Also added a WPT to ensure using parse-time base URI for lazy -> eager iframes.
Differential Revision: https://phabricator.services.mozilla.com/D190662
To allow workers to know the OverriddenFingerprintingSettings,
we populate the value to the worker loadInfo and worker private from
the document.
For service workers, we use the partitionKey in its principal to get
the OverriddenFingerprintingSettings of the given service worker.
Differential Revision: https://phabricator.services.mozilla.com/D185014
This makes number localization cheaper / halves the time in the
microbenchmark.
Change the content-language handling to use atoms. This exposes some
interesting inconsistencies but I tried not to change behavior there.
Differential Revision: https://phabricator.services.mozilla.com/D191174
It's a weak pointer but presumably can only die based on main thread actions. The GetBrowsingContext getter is just a plain getter, returning a pointer.
Although small this does show up in the profile in bug 1857094. It's called from some common layout/painting functions.
Differential Revision: https://phabricator.services.mozilla.com/D190559
Now that we have a DocumentState type we can be a bit less explicit
(before this used EventStates, so the extra Document in the names was
useful).
Differential Revision: https://phabricator.services.mozilla.com/D190602
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
These days it's just a very thin wrapper over an nsTArray of
ResizeObservers. We also schedule notifications for resize observations
for the whole BrowsingContext tree at once, so there's no point on
individually keep track of them.
Differential Revision: https://phabricator.services.mozilla.com/D190113
