1684230 - Resist Fingerprinting breaks WebGL Peaks of Austria site because RFP's max texture size is too small

Status: NEW

(Core :: Graphics: CanvasWebGL, defect)

Description

[Kevin Locke]

Attachment: Screenshot of garbled rendering.

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

[Gian-Carlo Pascutto [:gcp]]

Still reproduces on Linux / NVIDIA proprietary / current Nightly 95.

Comment 2

[Gian-Carlo Pascutto [:gcp]]

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.

Comment 3

[Thorin [:thorin]]

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

Comment 4

[Kevin Locke]

Attachment: Screenshot showing rendering issue and allow canvas extraction dialog

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

[Thorin [:thorin]]

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.........

Comment 6

[Kevin Locke]

(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

[Thorin [:thorin]]

Attachment: console.png

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

Comment 8

[Kevin Locke]

(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

[Thorin [:thorin]]

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

[Thorin [:thorin]]

what timing, I was hunting thru the bugs trying to find the RFP webgl ones, you bet me to it

Comment 11

[Kevin Locke]

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

[Thorin [:thorin]]

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/

Comment 13

[Tom Ritter [:tjr]]

We could probably update the constants here.