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
This patch fixes only the cases if the result of `ComputeIndexOf_Deprecated()`
is used as unsigned integer with implicit or explicit cast.
Differential Revision: https://phabricator.services.mozilla.com/D131336
It's hard to fix some callers. Therefore, in this bug, we should fix only
simple cases. Therefore, we should rename existing API first.
Differential Revision: https://phabricator.services.mozilla.com/D131334
It seems plausible for the doc to be unlinked, or for the element to be moved
to another document, in between the time observer notification is scheduled and
the time it runs. In that case, we'd be unregistered already anyways, so
there's nothing else to do.
Differential Revision: https://phabricator.services.mozilla.com/D114740
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
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
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
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
