1518872 - Blank page on microsoft.sharepoint.com with Standard content blocking settings

Status: RESOLVED FIXED

(Core :: Privacy: Anti-Tracking, defect, P1)

Description

[Kathleen Wilson]

Attachment: Screen Shot 2019-01-09 at 10.37.04 AM.png

When a typical user gets a blank page when browsing to a site they've previously used, how are they supposed to know that they need to click on the icons next to the URL to get the popup and turn off blocking for the site?

I was in a meeting, and needed to quickly get to the webpage, so I switched to a different browser which worked. Later I went back to Nightly to figure out what was wrong, and found it was due to content blocking -- screenshot attached.

I think a typical user would just continue using the other browser. :-(

Comment 1

[Johann Hofmann [:johannh]]

Can you give us some way to reproduce this? Like a URL that can be accessed without login credentials to see the white page. Or, if you can reliably reproduce it only with credentials, maybe we could make a new account with that site for testing.

In general, some STR would be highly appreciated.

Thank you!

Comment 2

[Kathleen Wilson]

Ehsan now has login credentials for this page, and I have sent the steps to reproduce the problem.

Comment 3

[Johann Hofmann [:johannh]]

Reminder needinfo for Ehsan to update us on the background and priority of this bug :)

Thanks!

Comment 4

[(no longer active)]

There is an iframe from https://ppc-onenote.officeapps.live.com/o/onenoteframe.aspx?edit=1&new=1&ui=en%2DUS&rs=en%2DUS&WOPISrc=https%3A%2F%2Fmicrosoft%2Esharepoint%2Ecom%2Fteams%2FCCADB%2F%5Fvti%5Fbin%2Fwopi%2Eashx%2Ffolders%2Fb7995c9485a548f4bd179b994c592714&wdEnableRoaming=1&wdFR=1&mscc=1&hid=953fb99e-504a-0000-b5a9-f543a1e1e901&wdorigin=ExternalSite on one of the pages where I can reproduce this bug. That iframe is classified as a tracker because live.com is on the Disconnect content list https://github.com/mozilla-services/shavar-prod-lists/blob/6cb4367c87585dd21ff83e4e530d3563f05d5f3b/disconnect-blacklist.json#L7647.

The iframe tries to run this JS code from https://c4-onenote-15.cdn.office.net/o/s/161131732725_App_Scripts/onenoteBoot.min.js:

e.indexedDBFactory = window.indexedDB || window.mozIndexedDB || window.webkitIndexedDB || window.msIndexedDB || window.shimIndexedDB

window.indexedDB throws a SecurityError exception because the iframe is classified as a third-party tracker. This exception isn't handled by the JS code on the page which breaks the execution of this code. That then results in the |wacBoot| object which is being defined in this script to not be successfully defined at the global scope. Later on when the page proceeds to access this variable we get a TypeError exception ("window.wacBoot is undefined") and JS execution is aborted. At this point the application hasn't yet fully initialized and that's why the screen remains blank.

In order to work around this bug, changing the value of the urlclassifier.trackingAnnotationSkipURLs pref to "google.com/recaptcha/,*.google.com/recaptcha/,ppc-onenote.officeapps.live.com/" is sufficient to make the application work again.

As to how to fix this bug, I think the real problem here is that we are classifying live.com as a tracker on sharepoint.com in the first place. Both of these properties belong to the same entity (Microsoft) but sharepoint.com doesn't exist on the Disconnect list, which means that we don't know about the entity relationship. I filed this issue with Disconnect in order to add sharepoint.com to the TP list, that should help fix this bug: https://github.com/disconnectme/disconnect-tracking-protection/issues/69

Comment 5

[Johann Hofmann [:johannh]]

Thanks for investigating!

Sounds like we want to update urlclassifier.trackingAnnotationSkipURLs for 66 then. Ideally we could do this remotely when bug 1511111 is resolved, but to be safe we might want to update the list manually for now.

Comment 6

[Steven Englehardt [:englehardt]]

https://github.com/mozilla-services/shavar-prod-lists/pull/52 was filed to address this. I'll update this bug once it is merged.

Comment 7

[(no longer active)]

(In reply to Johann Hofmann [:johannh] from comment #5)

Thanks for investigating!

Sounds like we want to update urlclassifier.trackingAnnotationSkipURLs for 66 then. Ideally we could do this remotely when bug 1511111 is resolved, but to be safe we might want to update the list manually for now.

No, why would we need to do that?

Comment 8

[Johann Hofmann [:johannh]]

(In reply to :Ehsan Akhgari from comment #7)

(In reply to Johann Hofmann [:johannh] from comment #5)

Thanks for investigating!

Sounds like we want to update urlclassifier.trackingAnnotationSkipURLs for 66 then. Ideally we could do this remotely when bug 1511111 is resolved, but to be safe we might want to update the list manually for now.

No, why would we need to do that?

I didn't realize we could add these entities so quickly, I expected the process with disconnect to take longer.

That's great, though!

Steven, I'm assigning you on this one then :)

Comment 9

[(no longer active)]

My main point was that this breakage is caused by the strict list, so technically we only need the fix for when we decide to ship that list. :-) Until then, this bug will only affect Nightlies and early betas which have the strict list enabled for cookie blocking.

Comment 10

[Steven Englehardt [:englehardt]]

Kathleen confirmed that this is fixed now that https://github.com/mozilla-services/shavar-prod-lists/pull/52 was merged.