chromium code search won't display with fingerprinting protection

[darkdh]

Description

As title, this happens since 0.19.99

Steps to Reproduce

1. Go to https://cs.chromium.org
2. Turn on fingerprinting protection per site or globally
3. The page is white and the fingerprint protection count is 0

Actual result:

Expected result:
It should be viewable with fingerprinting protection(It used to be)

Reproduces how often:

Brave Version

about:brave info:

Brave: 0.19.100
rev: 55a964a
Muon: 4.5.16
libchromiumcontent: 62.0.3202.94
V8: 6.2.414.42
Node.js: 7.9.0
Update Channel: Release
OS Platform: macOS
OS Release: 17.2.0
OS Architecture: x64

Reproducible on current live release:

No

Additional Information

cc @diracdeltas @bbondy

[darkdh]

cc @snyderp

[bsclifton]

Possibly caused by #11784

[darkdh]

same thing happens on https://productforums.google.com/forum/

[pes10k]

Yep, this is definitely caused by #11784

Lines of code like this (ugly b/c its from be debugging the minified source)

function OCd(b){try{if(!b.contentWindow||!b.contentWindow.document)return null;return b.contentWindow.document.body.innerHTML}

I'm not sure what is best here. I don't think there is any JS/extension/short term solution for #11784 that won't also cause this pattern to break.

Barring some other quick solution for #11784 that I can't think of, I think the options are:

1. Say "shields will break some sites", and these are examples of them (not totally satisfying…)
2. Some kind of allow list to allow well known domains to talk cross frames
3. Roll back block access to child frames' contentWindow, contentDocument, place guard in blocking proxy to prevent an infinite loop #11784 and accept that Brave's fingerprinting protections can be circumvented (at least until fingerprinting protection should be done in C++ instead of js content script #12045)
4. Another option would be to hack electron to stop parent frames until the document_start hook of the child frame fires (which would solve block access to child frames' contentWindow, contentDocument, place guard in blocking proxy to prevent an infinite loop #11784 Fingerprinting protections bypassable via window.open #12110 and similar)

All those are different degrees of unsatisfying. I'm sure I'm not the person to evaluate the tradeoffs between them, though I'd be very happy to help push forward with any of those that you all decide to go with. @diracdeltas ?

[diracdeltas]

i think the best option is 3, roll back #11784, unless 4 can be done really quickly

[pes10k]

Realistically, I think 4 would take less time than #12045 (though couldn't swear to it) but it definitively wouldn't be small thing. Days or a week, plus testing.

I'll start looking into #12045 more seriously then.

Is there a test suite for these kinds of issues? Even if they're live sites and the tests might have to be updated periodically to account for changes, it might be worth the lift starting up

[bsclifton]

Fixed with fe2fced

[kjozwiak]

@darkdh has fe2fced fixed the issues you were having? QA will also check and ensure that the above two websites are now working on the three main platforms.

[kjozwiak]

Test Case Used:

• install brave 0.19.105
• enable FP via about:preferences#shields
• visit https://cs.chromium.org and ensure that the page is usable and loads without issues
• visit https://productforums.google.com/forum/ and ensure that the page is usable and loads without issues

[darkdh]

Verified it works