Firefox 68: not working css mask from local storage (file:///...)
Categories
(Core :: CSS Parsing and Computation, defect, P3)
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.
|
||
Updated•5 years ago
|
|
||
Comment 1•5 years ago
|
||
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.
|
||
Comment 3•5 years ago
|
||
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.
|
||
Comment 5•5 years ago
|
||
Emilio, do you know offhand where masks do a same-origin check and what behavior in other browsers is?
|
||
Comment 6•5 years ago
|
||
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.
|
|
||
Comment 7•5 years ago
|
||
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?
|
|
||
Comment 8•5 years ago
|
||
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.
|
|
||
Comment 9•5 years ago
|
||
Yeah, Epiphany's network panel shows "Origin null is not allowed by Access-Control-Allow-Origin".
|
|
||
Comment 10•5 years ago
|
||
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?
|
|
||
Comment 11•5 years ago
|
||
Note that that Chrome folks are pushing back on whether these loads should be CORS at all.
|
|
||
Comment 12•5 years ago
|
||
Is there any public document on that, or something I could read for their rationale?
|
||
Comment 13•5 years ago
|
||
The priority flag is not set for this bug.
:emilio, could you have a look please?
For more information, please visit auto_nag documentation.
|
|
||
Comment 14•5 years ago
|
||
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.
|
|
||
Comment 15•5 years ago
|
||
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?
|
|
||
Comment 16•5 years ago
|
||
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.
|
|
||
Comment 17•5 years ago
|
||
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).
|
|
||
Updated•5 years ago
|
|
||
Comment 18•3 years ago
|
||
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.
|
|
||
Updated•3 years ago
|
|
||
Updated•2 years ago
|
Description
•