Resist Fingerprinting breaks WebGL Peaks of Austria site because RFP's max texture size is too small
Categories
(Core :: Graphics: CanvasWebGL, defect)
Tracking
()
People
(Reporter: kevin, Unassigned)
References
(Blocks 1 open bug, )
Details
Attachments
(3 files)
Visiting the "Peaks of Austria" page at https://felixpalmer.github.io/peaks-of-austria with privacy.resistFingerprinting=true results in a confused/broken rendering, as shown in the attached screenshot produced using:
mozregression --pref privacy.resistFingerprinting:true -a https://felixpalmer.github.io/peaks-of-austria
The issue appears on Firefox 84.0 and current nightlies. Both tested on Debian testing with Intel 3rd Gen Core processor graphics.
The website source is available at https://github.com/felixpalmer/peaks-of-austria I have not reached out to the author yet, but would be willing to do so if that would be helpful.
Comment 1•3 years ago
•
|
||
Still reproduces on Linux / NVIDIA proprietary / current Nightly 95.
Comment 2•3 years ago
|
||
I'm guessing this is because of
Blocked https://felixpalmer.github.io/peaks-of-austria/ from extracting canvas data because no user input was detected. procedural-gl.js:41474:27
So I think this is expected.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 3•3 years ago
|
||
When you load https://felixpalmer.github.io/peaks-of-austria/ you will see a canvas icon in the urlbar, you can click this and allow (or allow for session by unchecking Remember this decision
Can probably be duped to Bug 1631673 which is a bit of a think tank on this problem
- we reduced prompt fatigue with
privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts
- now as more site use canvas, the lack of education on RFP (it is not front facing) and the silent breakage is becoming more problematic
- possibly auto-allowing per eTLD+1 per session after a user-gesture (which is problematic as eliciting a gesture is not hard)
tom? dupe to Bug 1631673
Reporter | ||
Comment 4•3 years ago
|
||
Thanks all for weighing in on this issue!
(In reply to Simon Mainey from comment #3)
When you load https://felixpalmer.github.io/peaks-of-austria/ you will see a canvas icon in the urlbar, you can click this and allow (or allow for session by unchecking
Remember this decision
I gave this a shot with 95.0a1 (2021-10-07) (64-bit) launched via mozregression:
mozregression --pref privacy.resistFingerprinting:true -a https://felixpalmer.github.io/peaks-of-austria --launch 2021-10-07
After clicking Allow (and force-reloading) the rendering is still broken for me. (Screenshot attached.) Without --pref privacy.resistFingerprinting:true
it renders correctly with 95.0a1 (2021-10-07) (64-bit).
Comment 5•3 years ago
|
||
I have to admit I didn't actually test it, sorry ... however, I don't think that's RFP ... I see console errors galore (also on Nightly 95)
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://maps1.wien.gv.........
Reporter | ||
Comment 6•3 years ago
|
||
(In reply to Simon Mainey from comment #5)
I have to admit I didn't actually test it, sorry ... however, I don't think that's RFP ... I see console errors galore (also on Nightly 95)
No worries, still a good suggestion. I don't mind doing the testing. I am also seeing the "Cross-Origin Request Blocked" console errors, but the site works for me with mozregression -a https://felixpalmer.github.io/peaks-of-austria --launch 2021-10-07
in spite of the errors and not with --pref privacy.resistFingerprinting:true
. Are you seeing different behavior? What makes you think it's not RFP?
Comment 7•3 years ago
|
||
Are you seeing different behavior? What makes you think it's not RFP?
I was being lazy and making you do the testing :) Sorry, not sorry :) I see the same as you. Here are the console errors
- left: RFP is on with a canvas exception, force reload
- right: RFP is off
IDK why the code thinks the image is now too big to be supported? I see the waypoints, and can move around, there's just no imagery
Reporter | ||
Comment 8•3 years ago
|
||
(In reply to Simon Mainey from comment #7)
IDK why the code thinks the image is now too big to be supported?
Good catch! I should have looked more closely at the error messages. It looks like this is the result of the RFP analog (Bug 1217290) of "WebGL Minimal-Capabilities Mode" (Bug 686732) which defines the maximum texture size as 2048. See: https://hg.mozilla.org/mozilla-central/rev/61d074cfdeaf#l3.36
So this appears to be working as intended. Feel free to close or track as appropriate.
Comment 9•3 years ago
|
||
for the record, this can be reproduced as far back as FF60 (I didn't go back any further: just spot checked 78, 68, 60). Bug 967895 was added in FF58 and Bug 1217290 & Bug 1409677 were in FF57, I suspect it's one of the latter two
Comment 10•3 years ago
|
||
what timing, I was hunting thru the bugs trying to find the RFP webgl ones, you bet me to it
Reporter | ||
Comment 11•3 years ago
|
||
Great timing! Thanks again Simon.
For reference, now that we know what's going on, I opened an issue to let the site developer know: https://github.com/felixpalmer/peaks-of-austria/issues/1
Comment 12•3 years ago
|
||
Six years is a long time - https://bugzilla.mozilla.org/show_bug.cgi?id=1217290#c2 .. perhaps 2048
is too low these days for a minimum
[1] https://www.khronos.org/registry/webgl/specs/latest/1.0/
[2] https://www.khronos.org/registry/webgl/specs/latest/2.0/
Updated•2 years ago
|
Comment 13•2 years ago
|
||
We could probably update the constants here.
Description
•