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
Seems to match what other browsers do. Other browsers seem to fire
events at random some of the time tho, fun stuff as usual.
Differential Revision: https://phabricator.services.mozilla.com/D218603
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
Stop supporting following the system preference, but keep macOS users
able to switch to just text controls (accessibility.tabfocus=1) in the
settings.
Change the meaning of the "Use the tab key to move focus between form
controls and links" checkbox in the Firefox settings, which was
introduced in bug 1628476 to override the system setting.
The intention, I think was that this checkbox being off resulted in
"follow the system" behavior, but that didn't quite happen due to a bug
in the preferences code (this[1] won't unset the pref, because of
this[2], which means we'll just return 0).
This patch changes it so that the checkbox instead always ignores the
system setting. There will no longer be a Firefox setting (neither in
the UI nor on about:config) that means "follow system setting".
This allows us to somewhat simplify the approach compared to the
previous patch in D196110, and keep the accessibility.tabfocus working
as the source of truth without a migration.
In the future, we can think of migrating accessibility.tabfocus to a
boolean pref, which would allow us to do the cleanups to the preferences
code that D196110 did.
[1]: https://searchfox.org/mozilla-central/rev/f1532761de0b60337e42c6c3f525288a523dabef/browser/components/preferences/main.js#2252
[2]: https://searchfox.org/mozilla-central/rev/f1532761de0b60337e42c6c3f525288a523dabef/toolkit/content/preferencesBindings.js#450,483
Differential Revision: https://phabricator.services.mozilla.com/D208602
Stop supporting following the system preference, but keep macOS users
able to switch to just text controls (accessibility.tabfocus=1) in the
settings.
Change the meaning of the "Use the tab key to move focus between form
controls and links" checkbox in the Firefox settings, which was
introduced in bug 1628476 to override the system setting.
The intention, I think was that this checkbox being off resulted in
"follow the system" behavior, but that didn't quite happen due to a bug
in the preferences code (this[1] won't unset the pref, because of
this[2], which means we'll just return 0).
This patch changes it so that the checkbox instead always ignores the
system setting. There will no longer be a Firefox setting (neither in
the UI nor on about:config) that means "follow system setting".
This allows us to somewhat simplify the approach compared to the
previous patch in D196110, and keep the accessibility.tabfocus working
as the source of truth without a migration.
In the future, we can think of migrating accessibility.tabfocus to a
boolean pref, which would allow us to do the cleanups to the preferences
code that D196110 did.
[1]: https://searchfox.org/mozilla-central/rev/f1532761de0b60337e42c6c3f525288a523dabef/browser/components/preferences/main.js#2252
[2]: https://searchfox.org/mozilla-central/rev/f1532761de0b60337e42c6c3f525288a523dabef/toolkit/content/preferencesBindings.js#450,483
Differential Revision: https://phabricator.services.mozilla.com/D208602
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
Make it be output-only, not having that confusing in-out tab-index
parameter that is special for XUL to become focusable with
-moz-user-focus: normal. Instead, do that explicitly in
nsIFrame::IsFocusable().
Also, call it IsFocusableWithoutStyle(), since that's what it is.
Differential Revision: https://phabricator.services.mozilla.com/D195644
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
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
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
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
PictureSourceDimensionChanged may be called by an image element with a null
selector (because we call this function on all the image elements after
the source element).
Differential Revision: https://phabricator.services.mozilla.com/D155626
It doesn't make sense to load the selected image after we destroy the
image element because this is unnecessary and may cause unexpected behaviors.
We can reproduce this by running layout/style/test/test_bug418986-2.html
with xorigin, if we don't apply this patch.
Differential Revision: https://phabricator.services.mozilla.com/D155419
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
Per https://drafts.csswg.org/cssom-view/#extensions-to-the-htmlimageelement-interface:
> The x attribute, on getting, must return the x-coordinate of the left
> border edge of the first CSS layout box associated with the element,
> relative to the initial containing block origin, ignoring any
> transforms that apply to the element and its ancestors, or zero if
> there is no CSS layout box.
But we were using GetClosestLayer which stops at the first abspos
containing block or scroll frame.
Differential Revision: https://phabricator.services.mozilla.com/D151263
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
Emilio Cobos Álvarez