CLOSED TREE
Backed out changeset 17df14f0b129 (bug 1200896)
Backed out changeset 5d9e9bd12cd2 (bug 1200896)
Backed out changeset 7f016de8d52f (bug 1200896)
Right now they start with a FullyHidden() effect info, but with a
"visible" widget, and thus active docshell and so on.
That's no good :)
Differential Revision: https://phabricator.services.mozilla.com/D86364
Right now they start with a FullyHidden() effect info, but with a
"visible" widget, and thus active docshell and so on.
That's no good :)
Differential Revision: https://phabricator.services.mozilla.com/D86364
Also, for changes in CSS declarations, like changing
cssRules[i].style.color or something, we end up avoiding a lot of the
work we were doing.
This page still trips us in the sense that they add a stylesheet, then
call getBoundingClientRect(), then insert more rules in the stylesheet,
which causes us to rebuild a lot of the cascade data.
We could try to detect appends to the last stylesheet on the list or
something I guess, and avoid rebuilding the cascade data in some cases.
Depends on D85615
Differential Revision: https://phabricator.services.mozilla.com/D85616
Right now they start with a FullyHidden() effect info, but with a
"visible" widget, and thus active docshell and so on.
That's no good :)
Differential Revision: https://phabricator.services.mozilla.com/D86364
Unlike other engine vendors, we process meta elements
at parser, instead of when they are inserted. This
leads some web compact issues.
This patch aligns us with other vendors.
Differential Revision: https://phabricator.services.mozilla.com/D84545
The NoValidContent type was added to detect cases where we needed to apply
default width the viewport. That approach is no longer needed, and this
enum can be removed, as well as the code that sets and checks that enum.
Differential Revision: https://phabricator.services.mozilla.com/D84447
Having two classes in the inheritance chain inherit from SupportsWeakPtr
now won't compile, but you can use WeakPtr<Derived> when any base class
inherits from SupportsWeakPtr.
Differential Revision: https://phabricator.services.mozilla.com/D83674
We need to set the original document ASAP so images triggered from the
clone use the right service worker.
It is a bit unfortunate to have the static document checks twice, but we
may get to Document::GetClientInfo before the cloned doc has a window,
so it's not 100% clear to me how we could avoid it.
Differential Revision: https://phabricator.services.mozilla.com/D82081
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
We need to set the original document ASAP so images triggered from the
clone use the right service worker.
It is a bit unfortunate to have the static document checks twice, but we
may get to Document::GetClientInfo before the cloned doc has a window,
so it's not 100% clear to me how we could avoid it.
Differential Revision: https://phabricator.services.mozilla.com/D82081
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
The telemetry probe, which is related with `mDocTreeHadPlayRevoked`, has already been removed, so we don't need these code anymore.
Differential Revision: https://phabricator.services.mozilla.com/D83163
After we enable Fissions, we can't always access the top level document because it might be in another process.
Therefore, we should move `mDocTreeHadAudibleMedia` from document to the top window context, which can ensure that we set the value correctly even if setting `mDocTreeHadAudibleMedia` happens in a different process which is different from the process where the top level document exists.
Differential Revision: https://phabricator.services.mozilla.com/D83162
See bug 1606660 comment 8 as to why checking it only in
Element.requestFullscreen is wrong.
Do you know how to test this? I'm not very familiar with feature-policy.
Differential Revision: https://phabricator.services.mozilla.com/D78567
This patch adds the boolean pref mathml.stixgeneral_operator_stretching.disabled, which defaults to true iff nightly.
When the pref is true, stretched operators won’t be rendered with STIXGeneral, because we only use OpenType MATH tables (in fonts that have them) or the generic Unicode table.
When the pref is false, we continue to support STIXGeneral for stretched operators, but warn the author in devtools and bump the use counter (up to once per page). This only happens when a stretched operator actually uses STIXGeneral: not when we successfully render the operator with some other font earlier in the font-family stack, and not when STIXGeneral isn’t installed.
Differential Revision: https://phabricator.services.mozilla.com/D73833
When we hit the stylesheet cache for an existing stylesheet in a
different document:
* There's no existing preload in the PreloadService (because the sheet
was loaded in another document).
* We don't create a PreloaderBase (because we don't trigger a load at
all).
* And thus we believe the load has just errored, which is wrong...
Fix it by properly passing through the "already complete" status from
PreloadStyle.
Note that there's still another issue, which is that we'd still hit this
broken path if two stylesheets with the same URI are loading in
different documents and the CSS loader coalesces them.
For that, I think we'd have to make SheetLoadData the thing that
actually implements PreloaderBase. This is kind of an obscure case, and
SheetLoadData has a pretty complex lifetime already (keeps alive a whole
lot of stuff), so I'd prefer to do this in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D80289
Hiroyuki Ikezoe
Sean Feng
Mihai Alexandru Michis
Emilio Cobos Álvarez
Razvan Maries
Stephen A Pohl
Noemi Erli
Brad Werth
Narcis Beleuzu
alwu
Simon Giesecke
Daisuke Akatsuka
James Willcox
Bogdan Tara
Delan Azabani
Eden Chuang
Andrea Marchesini
Nika Layzell
Johann Hofmann
Anny Gakhokidze