Open Bug 1565509 Opened 5 years ago Updated 2 years ago

Firefox 68: not working css mask from local storage (file:///...)

Categories

(Core :: CSS Parsing and Computation, defect, P3)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect

Tracking

()

People

(Reporter: vladimir.m.shevchenko, Unassigned)

References

(Regression)

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

I'm using css properties in my local css-files for development and after update to version 68 all was is OK, but after update css property "mask" stopped working in local files like file:///C:/Users/1/index.html (in version 67 all OK).

Code example:
background-color: #0096D6;
-webkit-mask: url("../images/icons/icon-trash-1.svg") no-repeat 0 0 / 100% 100%;
mask: url("../images/icons/icon-trash-1.svg") no-repeat 0 0 / 100% 100%;

Actual results:

Blank wrap, but if i'm using gradient instead url - all is well.

Expected results:

Mask should working in local files.

Component: ru / Russian → Untriaged
Product: Mozilla Localizations → Firefox

hello, do you see a CORS error in the web console when this is happening?

(In reply to [:philipp] from comment #1)

hello, do you see a CORS error in the web console when this is happening?

No.

this is likely fallout due to the following privacy/security fix in firefox 68: https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730

you could try to change privacy.file_unique_origin to false in about:config, restart firefox and see if this can make a difference (please note that this makes you vulnerable to the described security problem though).

(In reply to Robert Longson [:longsonr] from comment #3)

this is likely fallout due to the following privacy/security fix in firefox 68: https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730

you could try to change privacy.file_unique_origin to false in about:config, restart firefox and see if this can make a difference (please note that this makes you vulnerable to the described security problem though).

Thanks, it works for me.

Emilio, do you know offhand where masks do a same-origin check and what behavior in other browsers is?

Blocks: file-fallout
Status: UNCONFIRMED → NEW
Component: Untriaged → CSS Parsing and Computation
Ever confirmed: true
Flags: needinfo?(emilio)
Product: Firefox → Core
Regressed by: CVE-2019-11730

It was implemented in bug 1418470. As far as I can tell, Safari fixed that before us, but Chrome still hasn't fixed it, which is unfortunate.

Flags: needinfo?(emilio)

As far as I can tell, Safari fixed that before us

Does Safari enforce CORS here for file:// URLs too?

Which properties does this affect? Looking at the code, seems like this might apply to float area shapes and anything that uses ImageLayer?

Is there a Blink issue tracking them fixing this?

Flags: needinfo?(emilio)

Blink issue is https://bugs.chromium.org/p/chromium/issues/detail?id=786507.

Don't know about Safari, but Epiphany which is also WebKit based renders white just like us in this test-case:

<!doctype html>
<style>
  img {
    -webkit-mask-image: url(image.png);
    mask-image: url(image.png);
    width: 100px;
    height: 100px;
    background: red;
  }
</style>
<img>

Where image is just a local version of https://d33wubrfki0l68.cloudfront.net/d319533ac3d22c3186498254e0caee871796a29e/d7ce9/images/css/masking/image-mask.png.

Flags: needinfo?(emilio)

Yeah, Epiphany's network panel shows "Origin null is not allowed by Access-Control-Allow-Origin".

Thanks for the testcase. Safari has the same behavior as Epiphany, looks like.

Sounds like we should just push Chrome to fix their bug; I've sent some mail. I assume that the reasons for CORS here should in fact apply to file:// loads?

Note that that Chrome folks are pushing back on whether these loads should be CORS at all.

Is there any public document on that, or something I could read for their rationale?

The priority flag is not set for this bug.
:emilio, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(emilio)

I think this is P3 for now. Boris, question for you in comment 12. I'm happy to remove the cors stuff if we think it's not a bug, but I'd like to understand the argument first.

Flags: needinfo?(emilio) → needinfo?(bzbarsky)
Priority: -- → P3

Is there any public document on that, or something I could read for their rationale?

Sorry, I wasn't cced, looks like. The discussion I am aware of is in https://crbug.com/786507 and this is what foolip had to say in email to me directly:

Following https://crbug.com/786507, ultimately nobody gave a reason
why it's important to use a CORS for this fetch. Boris, do you think
this itself is important, or is any way of aligning behavior OK?

So it sounds like mostly a difference of "new things should be CORS by default" vs "things should have a good reason to be CORS" or something?

Flags: needinfo?(bzbarsky)

See also https://stackoverflow.com/questions/57349348/inline-svg-with-use-tag-stopped-working-with-recent-browsers which is about <use> rather than <mask> but is otherwise the same issue.

That's a completely separate issue, because it's due to a very different security check and has very different security properties and tradeoffs.... (Note that right now over http:// you can't do cross-origin <use>, even with CORS, unlike masks).

This is still broken as of today in Firefox 92.0.1. As Robert suggests above, disabling privacy.file_unique_origin solves the problem in a pinch, but a permanent fix would be nice.

Worse, Chrome has since overzealously patched their own security hole so it's also broken in Chrome. In Chrome, however, a CORS error is (now) logged: "Access to image at ... from origin 'null' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, chrome-untrusted, https." On Firefox, on the other hand, it took me quite a while to realize the issue didn't come from my images or elsewhere in the document.

Both browsers refrain from rendering the element entirely instead of rendering the element unmasked, which also seems less than ideal.

Has Regression Range: --- → yes
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.