Using integer as a bit field may cause simple mistake and may not be easy
to read, and we have `EnumSet` class which can treat an `enum class` as
a bit flags so that we should make it an `enum class` and use it with the
`EnumSet` class.
Differential Revision: https://phabricator.services.mozilla.com/D99172
This is intended to be a hotfix for the URL bar regression. Ideally there should be a spec or this behavior should be removed completely.
Previously select() scrolled back to the start position before the regression, but this fix does not restore that behavior.
Differential Revision: https://phabricator.services.mozilla.com/D98972
The spec text has been improved a while ago, so I think we should do
this. This keeps the current moz-focusring behavior when the pref is
disabled, but when enabled it becomes effectively an alias of
focus-visible.
Differential Revision: https://phabricator.services.mozilla.com/D96697
Software keyboard is shown by user interaction. But `change` event by
`element.click()` becomes user interaction event by bug 1543439 even if
it is called by script.
Since `change` event can be fired by click() method, we shouldn't be
that it is always user interaction.
Also, we have setUserInput that is chrome API to emulate user input. It
should be defined as user interaction.
Differential Revision: https://phabricator.services.mozilla.com/D95818
By moving it to nsImageLoadingContent we don't need to pass a reference
to the current request and can just use the member.
The weird reference-passing was introduced in bug 987140 and broke in
bug 1534608.
Also make it return a CSSIntSize rather than an nsSize, since it's what
it returns, nsSize is supposed to be in app units, not in CSS pixels :-)
Differential Revision: https://phabricator.services.mozilla.com/D90036
We still reframe for additions / removals of the attribute because that
makes us create the placeholder <div>. We could avoid it if we created
it independently of the presence of the attribute but that seems like it
could regress perf for the case where there's no placeholder attribute,
which is probably common enough.
Differential Revision: https://phabricator.services.mozilla.com/D88724
We still reframe for additions / removals of the attribute because that
makes us create the placeholder <div>. We could avoid it if we created
it independently of the presence of the attribute but that seems like it
could regress perf for the case where there's no placeholder attribute,
which is probably common enough.
Differential Revision: https://phabricator.services.mozilla.com/D88724
They're enabled in all configurations and there's no plan to change
this. With it, dom.experimental_forms is also useless, so we can remove
it too.
Differential Revision: https://phabricator.services.mozilla.com/D87623
This changes the UA widget setup (again). What is going on in this
test-case is that we have a marquee inside a video, two things that have
their own UA widget. Given how the code is currently written, the
runnable to attach and set up the marquee's widget is posted before than
the video one (which is potentially reasonable).
However that means that the marquee one runs before and flushes layout,
and catches the video in an inconsistent state (in the composed doc, but
without a shadow root). That in turn messes up reflow because
nsVideoFrame assumes stuff.
Rather than putting the attach / detach logic in script runners, just
run that bit synchronously, and post only the event async. I audited the
consumers of those events and it seems fine to me, they either already
deal with the possibility of the shadow root being already detached or
they don't care.
For teardown, none of the destructors of the UA widgets rely on the
shadow root being still attached to the element.
Differential Revision: https://phabricator.services.mozilla.com/D84487
Make them perform the image load (if needed), instead of copying the
image requests from the original document.
This is needed for CSS for stuff like:
@media print {
#foo::before {
content: url(bar.png);
}
}
And so on. For images, we should do this as well. Nothing prevents you
from doing:
<picture>
<source srcset="print.png" media="print">
<source srcset="screen.png" media="not print">
<img>
</picture>
And that should in theory work. It works after this patch, and I added a
test for that.
This patch is a bit bigger than I'd like, but I didn't find a more
reasonable way to split it up.
Making static docs able to do image loads is most of the patch and is
mostly straight-forward. This allows to remove the hacky "change the
loading document" thing that CSS images do, which is just working around
the CSP of the print document.
I need to enable background colors in printpreview_helper so as to be
able to have a reference page for all the different image types.
Differential Revision: https://phabricator.services.mozilla.com/D81779
This changes the UA widget setup (again). What is going on in this
test-case is that we have a marquee inside a video, two things that have
their own UA widget. Given how the code is currently written, the
runnable to attach and set up the marquee's widget is posted before than
the video one (which is potentially reasonable).
However that means that the marquee one runs before and flushes layout,
and catches the video in an inconsistent state (in the composed doc, but
without a shadow root). That in turn messes up reflow because
nsVideoFrame assumes stuff.
Rather than putting the attach / detach logic in script runners, just
run that bit synchronously, and post only the event async. I audited the
consumers of those events and it seems fine to me, they either already
deal with the possibility of the shadow root being already detached or
they don't care.
For teardown, none of the destructors of the UA widgets rely on the
shadow root being still attached to the element.
Differential Revision: https://phabricator.services.mozilla.com/D84487
Make them perform the image load (if needed), instead of copying the
image requests from the original document.
This is needed for CSS for stuff like:
@media print {
#foo::before {
content: url(bar.png);
}
}
And so on. For images, we should do this as well. Nothing prevents you
from doing:
<picture>
<source srcset="print.png" media="print">
<source srcset="screen.png" media="not print">
<img>
</picture>
And that should in theory work. It works after this patch, and I added a
test for that.
This patch is a bit bigger than I'd like, but I didn't find a more
reasonable way to split it up.
Making static docs able to do image loads is most of the patch and is
mostly straight-forward. This allows to remove the hacky "change the
loading document" thing that CSS images do, which is just working around
the CSP of the print document.
I need to enable background colors in printpreview_helper so as to be
able to have a reference page for all the different image types.
Differential Revision: https://phabricator.services.mozilla.com/D81779
