Top layer / fullscreen should work in shadow dom. This check is off
compared to literally every other fullscreen check.
The test is pretty gross, but not my fault, see the comment in there :)
Differential Revision: https://phabricator.services.mozilla.com/D83198
Also: adjust include paths to be consistent for usages of various SVG headers,
and remove unused SVG includes (mostly for "utils" classes),
and drop stray "ns" from already-renamed SVG classes in various code comments.
Differential Revision: https://phabricator.services.mozilla.com/D83140
We need to notify unconditionally because even if we didn't have
stylesheets, we could have responsive content which needs to change
source.
We need to notify the document even if the pres shell is not
initialized, as it might be our last chance to notify the responsive
content. This happens for printing, and makes my srcset test fail.
MANUAL PUSH: Somehow phabricator still thinks it needs review, even
though it was accepted.
Differential Revision: https://phabricator.services.mozilla.com/D81778
The only common failure case that's not being warned about now is when the user
rejected the prompt, which I think is expected behavior.
Differential Revision: https://phabricator.services.mozilla.com/D79597
The only common failure case that's not being warned about now is when the user
rejected the prompt, which I think is expected behavior.
Differential Revision: https://phabricator.services.mozilla.com/D79597
The only common failure case that's not being warned about now is when the user
rejected the prompt, which I think is expected behavior.
Differential Revision: https://phabricator.services.mozilla.com/D79597
We also need to propagate the IsOnContentBlockingAllowList to the script
generated document. For this kind of document, it won't have the
CookieJarSettings at the first place. It will generate its
CookieJarSettings when someone requests it. And we need to propagate the
flag when generating the CookieJarSettings in this case. Or the script
generated document will have a wrong IsOnContentBlockingAllowList flag.
Differential Revision: https://phabricator.services.mozilla.com/D81727
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
This patch would
- notify media controller when media enters/leaves fullscreen
The advantage of doing this is
- prework of being able to control media when media enters fullscreen
Differential Revision: https://phabricator.services.mozilla.com/D79765
Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354
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
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
We've had nsNativeBasicTheme enabled since 75, and all reported issues
were fixed real soon (and I haven't heard of any of them recently).
Given the non-native theme is likely changing in the future, I'd rather
not maintain three themes for Android :)
Differential Revision: https://phabricator.services.mozilla.com/D80105
This patch implements a per-process cache of parsed stylesheets for
non-inline sheets. The entries are evicted when the document gets
destroyed and there's no other document with the same principal around.
This works fine in practice even when navigating because CC happens
pretty late, but we could add an extra timer if we deem it worth it.
I had to adapt some tests so that they keep passing. They were already
clearing various image / network caches so it seems fine to also clear
this one.
Note that there's a very subtle change in the load data key: We only
miss the cache if the referrer _policy_ is different, not if the
referrer is different. While that is slightly dubious, that is the only
think that makes this effort somewhat worth it. Otherwise stylesheets
would have to be re-fetched if the referrer is different, which
effectively would mean to re-parse it if the document URI is different,
which is bad.
It seems like the network cache only keys on the referrer policy, so it
seems fine to do the same.
Differential Revision: https://phabricator.services.mozilla.com/D77457
This patch implements a per-process cache of parsed stylesheets for
non-inline sheets. The entries are evicted when the document gets
destroyed and there's no other document with the same principal around.
This works fine in practice even when navigating because CC happens
pretty late, but we could add an extra timer if we deem it worth it.
I had to adapt some tests so that they keep passing. They were already
clearing various image / network caches so it seems fine to also clear
this one.
Note that there's a very subtle change in the load data key: We only
miss the cache if the referrer _policy_ is different, not if the
referrer is different. While that is slightly dubious, that is the only
think that makes this effort somewhat worth it. Otherwise stylesheets
would have to be re-fetched if the referrer is different, which
effectively would mean to re-parse it if the document URI is different,
which is bad.
It seems like the network cache only keys on the referrer policy, so it
seems fine to do the same.
Differential Revision: https://phabricator.services.mozilla.com/D77457
Emilio Cobos Álvarez
longsonr
Micah Tigley
Csoregi Natalia
Johann Hofmann
Razvan Maries
Andreea Pavel
Daisuke Akatsuka
James Willcox
Bogdan Tara
Kagami Sascha Rosylight
sefeng
Simon Giesecke
Tim Huang
Andrea Marchesini
Cosmin Sabou
Liang-Heng Chen
Christoph Kerschbaumer
Delan Azabani
Eden Chuang
alwu
Jean-Yves Avenard
Narcis Beleuzu
Kris Maglione
Nicholas Nethercote
Olli Pettay