Clean-up some legacy nsImageLoadingContent state tracking while at it:
* mLoading was not used to set ElementState anymore, and was only
checked on the "loading" attribute handling, in what seems to be a
poor man's way of preventing lazy loading to start once an image load
is ongoing? However that should already be covered by the image load
not being sync and checking mLazyLoad itself.
* The depth tracking was unneeded, image notifications have been all
async for ages.
Move some bools into nsImageLoadingContent to pack it better.
Differential Revision: https://phabricator.services.mozilla.com/D218971
This fixes src loads to be consistent with srcset/picture loads, modulo
the special synchronous case in the spec
(https://html.spec.whatwg.org/#update-the-image-data step 7), which
requires src loads to be sync if the image is available.
We now avoid triggering the load from the parser consistently for src /
srcset / picture, and unify the codepath with BindToTree. That should
avoid some useless task allocations.
Only the sync load code-path needs a script runner (mostly to deal with
anonymous content like the video poster <img> and such, but it also
helps not trigger sync loads at unexpected times like on adoption).
About the HTMLImageElement::Complete() getter change, we need to also
return false if there's an existing load task. That is the proposal in
https://github.com/whatwg/html/issues/4884, and prevents some failures
in the-img-element/{update-src-complete,img.complete}.html WPTs. It
technically changes our behavior on .srcset changes, but it makes it
consistent with .src changes and other browsers, so seems fine.
There are a couple regressions in CSP tests and the networkEvent stubs,
but these are really a pre-existing issue. What happens is that, since
the loads are now async, CSP can't figure out the script that triggered
the load anymore. I need to look if there's an easy way to propagate
that information in the image load tasks, but this is trivially
reproducible by changing these tests to use srcset rather than src.
The rest of the test changes are as expected: either new passes, or
expected test changes from this.
Differential Revision: https://phabricator.services.mozilla.com/D215519
This doesn't change behavior on its own, but it's likely we want to make
the tab focusability more complicated in bug 1895184, and this will make
changes to this area less painful.
Differential Revision: https://phabricator.services.mozilla.com/D209525
This patch adds fetchpriority support for the `<img>` element, also
exposing the corresponding attribute in the WebIDL. As in D197493, we
try and minimize the change and rely on a mapping configurable under a
preference to ease future experiments. We use initial mapping
PRIORITY_LOW/PRIORITY_HIGH/PRIORITY_LOW for fetchpriority=low/high/auto
and allow further adjustments in the image code.
Internal fetchpriority mapping is covered by the following tests:
- `image-initial-load.h2.html` (typos fixed here)
- `image-dynamic-load.h2.html`
DOM tests are covered by the following tests (pref enabled to make them
pass):
- `idlharness.https.html`
- `attr-img-fetchpriority.html`
Differential Revision: https://phabricator.services.mozilla.com/D202222
Much like BindToTree.
This will be useful because I need to pass more information through
UnbindFromTree() to speed up dir=auto for bug 1874040.
Differential Revision: https://phabricator.services.mozilla.com/D202215
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
Instead, lazily schedule evaluation of them before styling, much like we
were doing for SVG.
A subtle tweak is that we only remain scheduled while in the document.
This allows us to use the "in document" bit plus the "mapped attributes
dirty" bit to know our scheduled status. It also prevents doing silly
work for disconnected elements, and having to do hashmap lookups on
adoption and node destruction.
Differential Revision: https://phabricator.services.mozilla.com/D181549
Instead, lazily schedule evaluation of them before styling, much like we
were doing for SVG.
A subtle tweak is that we only remain scheduled while in the document.
This allows us to use the "in document" bit plus the "mapped attributes
dirty" bit to know our scheduled status. It also prevents doing silly
work for disconnected elements, and having to do hashmap lookups on
adoption and node destruction.
Differential Revision: https://phabricator.services.mozilla.com/D181549
ParseAttribute ideally would be const (see bug 1829138), but the SVG and
SMIL code is rather messy. Still, now that BeforeSetAttr can't really
fail, swapping the order of ParseAttribute and BeforeSetAttr shouldn't
really change behavior.
Sorry for the extra `virtual` keyword removal and such. I had to do this
one by hand unlike the dependent bugs, and I went a bit drive-by, lmk if
you want me to split those changes.
Differential Revision: https://phabricator.services.mozilla.com/D176086
Same rg + sed shenanigans as the first patch.
There were two that could fail, both due to OOM:
* HTMLInputElement::AfterSetAttr: If we fail (only in the type=range
case) we end up with an old value without it being clamped by
min/max/step.
* HTMLBodyElement::AfterSetAttr: If we fail we won't peek up the
DocShell's frame margins and styling could be incorrect.
That seems better than having to deal with broken states after we've
already set the attribute.
Depends on D176069
Differential Revision: https://phabricator.services.mozilla.com/D176070
rg BeforeSetAttr -l | xargs sed -i 's/nsresult BeforeSetAttr/void BeforeSetAttr/g'
rg ::BeforeSetAttr -l | xargs sed -i 's/nsresult \(.*\)::BeforeSetAttr/void \1::BeforeSetAttr/g'
Plus trivial fixes, plus clang-format.
The only meaningful changes are in nsXULElement::BeforeSetAttr. Two
things could fail:
chromemargin: I removed it because we don't use the parsed attribute any
other place than here:
https://searchfox.org/mozilla-central/rev/31f5847a4494b3646edabbdd7ea39cb88509afe2/dom/xul/ChromeObserver.cpp#136
And that deals just fine with it not being parsed.
usercontextid: We have a debug assertion that we don't dynamically change it.
I kept it but I don't think it's worth failing to set the attribute on release for that
Differential Revision: https://phabricator.services.mozilla.com/D176069
Document.adoptNode() transfers a node from another document into this
method's document. Per spec, we have to react to the DOM mutations when
the elements adopting steps are run. So we have to update the image
responsive source to reflect the change of the environment.
For adopt, we update the source synchronously in NodeInfoChanged(), and
queue the image load task if the new document should load it (which is
done by StartLoadingIfNeeded()).
In the test case, without the patch, we don't add the script runner
because ShouldLoadImage() of the new document returns false, during
adopting steps. There is a pending image load task queued by setting
srcset, and this microtask runs after we finish adopting steps, so
we hit this assertion because this image element doesn't update its
image resource during adopting steps (with the new owner doucment).
Differential Revision: https://phabricator.services.mozilla.com/D156916
This patch will use the width/height attributes from <source> to override
width/height/aspect-ratio CSS property values of <img> elements.
So basically, we need to introduce an extra nsMappedAttribtue member in
HTMLSourceElement (and it only stores width and height attributes).
And then we use it as an extra declarations (which are generated by
Gecko_GetExtraContentStyleDeclarations()) so we can override the
declarations created from presentation attributes of <img>.
Besides, we need to make sure <img> elements get restyled in the
following cases:
1. width/height attributes is changed in <source> elements
2. <source> is inserted as a <picture>'s child
3. <source> is removed from the child list of <picture>
4. <img> is inserted as a <picture>'s child
5. <img> is removed from the child list of <picture>
We make the responsive source synchronously get updated in the previous patch,
so now we can just restyle the image when updating its responsive source.
Note: We fix the reflection of percentages for width/height attributes in
the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D152586
In order to make sure we are using the correct source element when
flushing the style, it's necessary to update the responsive image selector
synchronously (i.e. full selection for source element and re-resolve the
URI).
Differential Revision: https://phabricator.services.mozilla.com/D154813
So we can set the density during UpdateResponsiveSource(), and these functions
make us easier to restyle the image when we need to update the responsive
source synchronously in the patch series.
Differential Revision: https://phabricator.services.mozilla.com/D154329
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
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
referrerpolicy and crossorigin changes were handled in
AfterMaybeChangeAttr, but were only handling the case where the
attribute changed (that is, the AfterSetAttr caller). However
AfterSetAttr only calls AfterMaybeChangeAttr if there's a new value,
which means that we don't handle attribute removal.
So their handling can just move to AfterSetAttr, and we can simplify
AfterMaybeChangeAttr to just deal with src changes which is what it was
intended to deal with anyhow.
Differential Revision: https://phabricator.services.mozilla.com/D73619
Though with this initial implementation, we do create an IntersectionObserver
only for the root document in each processes, once we found issues on this
model, we can create an IntersectionObserver in each _document_.
Depends on D61437
Differential Revision: https://phabricator.services.mozilla.com/D61438
Behind a pref of course. Toggle that pref on on the loading/lazyload test
subdirectory, though there are no tests for the IDL (I guess once the spec PR
lands the existing IDL tests will be updated from the spec).
Differential Revision: https://phabricator.services.mozilla.com/D59764
ReferrerPolicy gets tossed back and forth as a uint32_t and
ReferrerPolicy enum in header file. Expose ReferrerPolicyValues from
webidl file and use consistently in native code.
Differential Revision: https://phabricator.services.mozilla.com/D41954
Per spec, "hspace" and "vspace" are parsed as dimension attributes and are
supported on the following elements: embed, iframe, img, object,
<input type="image">, marquee. Except no one implements this for iframe.
https://github.com/whatwg/html/issues/4742 tracks the spec changing accordingly.
As far as hspace/vpace on <table> go, Safari supports them in both quirks and
standards mode, while Chrome doesn't support them in either mode. The HTML spec
doesn't have them supported at all, and neither does the quirks mode spec, so
I'm removing the quirks-only support we had to align with the specs and Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D36375
BindContext was going to have way more information at first, but then I realized
that most of the things I wanted to know were basically a flag away using the
parent node.
Still I think it's worth it, now experimenting with BindToTree will only mean
adding a field to a struct that's included from a couple cpp files, instead of a
massive pain.
I also think this is clearer, and doing this highlights quite a few
inconsistencies in our code which I've left untouched, but commented with
FIXMEs.
Steps are:
$ for file in $(rg 'nsresult BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#nsresult BindToTree(Document\* aDocument, nsIContent\* aParent,#nsresult BindToTree(BindContext\&, nsINode\& aParent)#g' $file; done
$ for file in $(rg 'nsresult BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's# nsIContent\* aBindingParent) override#override#g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#::BindToTree(Document\* aDocument, nsIContent\* aParent,#::BindToTree(BindContext\& aContext, nsINode\& aParent)#g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#nsIContent\* aBindingParent)##g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#::BindToTree(aDocument, aParent, aBindingParent)#::BindToTree(aContext, aParent)#g' $file; done
$ ./mach clang-format
Then manual fixups.
Depends on D32948
Differential Revision: https://phabricator.services.mozilla.com/D32949
Emilio Cobos Álvarez