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
This is technically web-exposed, but if we needed to introduce it for
compat we could always re-introduce it matching false.
Differential Revision: https://phabricator.services.mozilla.com/D186938
This is technically web-exposed, but if we needed to introduce it for
compat we could always re-introduce it matching false.
Differential Revision: https://phabricator.services.mozilla.com/D186938
This is technically web-exposed, but if we needed to introduce it for
compat we could always re-introduce it matching false.
Differential Revision: https://phabricator.services.mozilla.com/D186938
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
This shouldn't change behavior but reduces the amount of code paths
where we update the internal image state.
Depends on D170594
Differential Revision: https://phabricator.services.mozilla.com/D170595
I don't think there's ever a way these should differ.
Got some include hell from removing ReferrerInfo.h from Document.h but
hopefully should be straight-forward to review.
Depends on D173154
Differential Revision: https://phabricator.services.mozilla.com/D173155
Otherwise the image frame doesn't get the image until the OnImageLoaded
notification arrives. See the test-case on why does this matter.
Differential Revision: https://phabricator.services.mozilla.com/D160659
The fix is the one line in
nsImageLoadingContent::MaybeForceSyncDecoding, but I added new asserts
that should prevent this from regressing in the future.
Differential Revision: https://phabricator.services.mozilla.com/D154815
This code will most likely be removed, but for now I am putting it
behind a pref so that it won't be activated when the modal is being
created.
See Bug 1782582 for the removal of the code.
Differential Revision: https://phabricator.services.mozilla.com/D153393
This code will most likely be removed, but for now I am putting it
behind a pref so that it won't be activated when the modal is being
created.
See Bug 1782582 for the removal of the code.
Differential Revision: https://phabricator.services.mozilla.com/D153393
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
Note this is an experiment in getting functionality going for text
recognition. It may be possible to do this more efficiently from
the C++ side of things, but this will allow for rapid experimentation
while working with UX.
Differential Revision: https://phabricator.services.mozilla.com/D143422
Note this is an experiment in getting functionality going for text
recognition. It may be possible to do this more efficiently from
the C++ side of things, but this will allow for rapid experimentation
while working with UX.
Differential Revision: https://phabricator.services.mozilla.com/D143422
We could expose the text recognition values to JS if need be, but
there's no reason to do that for now. We expose them via the UA
widget DOM for now.
We can trivially do that if we want to build the Shadow DOM in JS
or what not. I decided to still return a promise so that we can
expose errors though.
Differential Revision: https://phabricator.services.mozilla.com/D141113
We're checking animation consumers, not locked status. We don't care
about animation consumer count of non-animated images.
Depends on D137765
Differential Revision: https://phabricator.services.mozilla.com/D137766
Unsuppressing is done only if the page can use stylesheet cache. That should mean the
load isn't a cold load and also some other resources may be cached and thus
painting could happen sooner.
There is currently a regression around dom.ipc.processCount.webIsolated handling, but the
testing has been done with dom.ipc.processCount.webIsolated==1, and the patch for bug 1731792
should give back similar behavior as what process count 1 has.
Differential Revision: https://phabricator.services.mozilla.com/D125878
My previous patch still causes one WPT regression (invalid-src.html),
because we stopped firing error event for src="". However that test
times out because it doesn't correctly handle the invalid URI case. This
patch fixes it and cleans up the code a bit.
This fixes bug 1466138 too, and matches Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D114495
