Closed Bug 1226498 Opened 8 years ago Closed 1 year ago

tracking protection blocks async load of facebook js sdk

Categories

(Web Compatibility :: Site Reports, defect, P3)

Firefox 62
Unspecified
Windows 7

Tracking

(platform-rel -, firefox44 affected, firefox47 affected)

RESOLVED FIXED
Tracking Status
platform-rel --- -
firefox44 --- affected
firefox47 --- affected

People

(Reporter: m.moeseneder, Assigned: denschub)

References

(Blocks 2 open bugs, )

Details

(Keywords: webcompat:needs-diagnosis, Whiteboard: [platform-rel-Facebook] [tp-social] [tp-content][tp-shim-complex][tp-embedded-media][tp-federated-login])

User Story

facebook.com
fbcdn.net
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36

Steps to reproduce:

I am loading the facebook js sdk asynchronous in my project with the following code:

window.fbAsyncInit = function () {
    FB.init({
        appId: settings.facebookAppId,
        cookie: true,  // enable cookies to allow the server to access the session
        xfbml: true,  // parse social plugins on this page
        version: 'v2.0' // use version 2.0
    });
    FB.Canvas.setAutoGrow();
};

// Load the SDK asynchronously
(function (d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
    js = d.createElement(s);
    js.id = id;
    js.src = "//connect.facebook.net/de_DE/sdk.js";
    fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));


Actual results:

the tracking protection blocks the asynchronous load of the facebook js sdk.
but it seems to be only blocked, when i am not logged in on facebook.

you can see the problem here: http://artworx.at/promotion/werbeplanung/onliner/html/kategorien.php


Expected results:

as the script under //connect.facebook.net/de_DE/sdk.js is not for tracking, but for using facebook functionality it should not be blocked by the tracking protection
OS: Unspecified → Windows 7
Blocks: tp-breakage
Component: General → DOM: Security
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Firefox/42.0

This happens to me as well. Disabling "Use Tracking Protection in Private Windows" allows it to load properly in non-private windows. Shouldn't that option only apply to private windows?
Can confirm this is still happening in FF 44 private browsing mode. Brave browser has this issue too: https://github.com/brave/browser-laptop/issues/780.

Also confirmed in various places around the web, such as http://stackoverflow.com/questions/30599918/firefox-tracking-protection-breaks-facebook-login.

Test case: https://quora.com
François, who owns triaging Tracking Protection breakage? Is this an evangelism issue?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(francois)
(In reply to Chris Peterson [:cpeterson] from comment #3)
> François, who owns triaging Tracking Protection breakage?

I'm not sure. We haven't really discussed it. Maybe Javaun knows.

> Is this an evangelism issue?

In this particular case, I'm not sure there's a whole lot that can be done since that domain is on the blocklist.
Component: DOM: Security → Safe Browsing
Flags: needinfo?(francois) → needinfo?(jmoradi)
Product: Core → Toolkit
For now, we're logging breakage to block bug 1101005 as Boris has done. We're about to gather more data on the extent of damage to understand how pervasive and how severe the breakage might be. We don't have any action beyond that, we need to really assess the impact to the UX.
Flags: needinfo?(jmoradi)
This also happens with embedded twitter cards. The widget.js file from platform.twitter.com doesn't load, and so the cards do not appear as twitter cards but simply unformatted blocks of text. Disabling "Tracking Protection" fixes this here as well.
Component: Safe Browsing → Tracking Protection
Product: Toolkit → Firefox
Version: 42 Branch → unspecified
Whiteboard: [platform-rel-Facebook]
platform-rel: --- → ?
platform-rel: ? → ---
Whiteboard: [platform-rel-Facebook]
I think that block by default Facebook and Twitter is a error, the common users not know how disable Tracking Protection generate too incidents.
platform-rel: --- → ?
Whiteboard: [platform-rel-Facebook]
platform-rel: ? → -
Whiteboard: [platform-rel-Facebook] → [platform-rel-Facebook] tp-product
Priority: -- → P3
Whiteboard: [platform-rel-Facebook] tp-product → [platform-rel-Facebook]
Whiteboard: [platform-rel-Facebook] → [platform-rel-Facebook] tp-needsrepro
As this is a pretty old issue, we are wondering if this is still reproducible.
Flags: needinfo?(m.moeseneder)
The exact breakage reported in this bug is not as important since we have made all of the other Facebook SDK breakage reports duplicates of this one. As long as one of them is valid, we should keep this open.
Blocks: tplogin
User Story: (updated)
Component: Tracking Protection → Desktop
Product: Firefox → Tech Evangelism
Whiteboard: [platform-rel-Facebook] tp-needsrepro → [platform-rel-Facebook] [tp-social] [tp-content]
Version: unspecified → Firefox 62
Investigated Bug 1163771

It's still reproducible.
I was able to replicate it too.
No longer blocks: tp-breakage
Is this resolved in Firefox v62.0.3?
(In reply to Nick S from comment #21)
> Is this resolved in Firefox v62.0.3?

In firefox 64 still the bug

This issue still persists (tried it in Firefox 64.0.2 on Mac version 10.13.3.

When I loaded a website which uses the FB SDK js file, it failed to load with below error:

The resource at “https://connect.facebook.net/en_US/all.js” was blocked because content blocking is enabled.

Question:
Is the tracking protection setting enabled by default in latest Firefox versions? Because I don't remember enabling this setting myself.

It is enabled by default in private windows and has been so since around November 2015.

Product: Tech Evangelism → Web Compatibility

The artworx URL reported on this bug is now a 404, but the Quora-based example in comment 2 is working fine for me on today's Linux nightly as it is now using the newer FB SDK (sdk.js rather than all.js). I'm not aware of any sites still using the legacy and (unsupported) FB SDK using all.js, but if it is still usable yet being blocked it would be good to have a live URL to test with.

That said, the sdk.js is being blocked by strict TP, which breaks the login button.

The FB sdk.js file calls a window.fbAsyncInit function (which the calling site defines) after it has loaded and has defined window.FB (etc). So we could just re-fire the same request for sdk.js later, even if we canceled it the first time, and nothing on the page should really break.

For instance, we could detect when the user clicks on a likely FB login button, and first re-trigger the same sdk.js request, allow it to load this time, and then finish processing the click event (or just cancel the click, and re-fire another one that allows user-interaction so the FB popup isn't blocked).

We just need to take care to load the correct sdk.js, since the page may request different versions for different locales (en_US, etc).

Flags: needinfo?(m.moeseneder)

Another approach which seems to be working (at least with quora.com) is to still block the load to sdk.js, but instead provide our own skeleton definition for window.FB which pretends FB is ready by calling window.fbAsyncInit(), so the page thinks it's ready, and then waits for the page to call login whenever the users clicks a FB login button (so we don't have to guess if the user is clicking on one). I have this working with a demo addon on quora.com, mimicking strict mode when not in that mode by blocking the initial SDK request. If we had an addon API to request that an upcoming request not be blocked by Strict mode, I could probably package it up for wider testing.

This approach also seems to be working on es.wallapop.com, despite them also loading the Facebook pixel (fbevents.js), which remains blocked.

It's worth noting that while sites seem to tend to call FB.init in their fbAsyncInit callback, some do not. For instance, moviesanywhere.com calls it right away and has no fbAsyncInit callback at all. And since the FB.init method must be called before login (and with the parameters the site provides), we will need to take that into account with this potential fix. With that fix, I can log into Facebook properly on moviesanywhere.com, though their site seems to reject all logins from Facebook I've tried anyway (even in Chrome or without TP on at all).

I've also noticed that Twitch grabs an early reference to the window.FB object, so any spoofed version we use should probably act as a proxy to the final version once it's loaded. With that fixed, a spoof works fine on Twitch, but since they are soon removing support for logging in via Facebook entirely it's a bit of a moot point.

It also seems that some sites will simply break if the <script> they inject for the Facebook SDK fails to load (for instance, https://www.todoexpertos.com/ in bug 1602690 and https://plug.dj/ in bug 1515027). As such, we would probably be best off actually "hijacking" the request, not sending it, but just returning our spoof. In my tests this works for all of the cases I've run across so far.

There is also all.js in addition to sdk.js. Shimming it just how I might shim sdk.js unbreaks the image gallery arrows on bug 1377002.

Whiteboard: [platform-rel-Facebook] [tp-social] [tp-content] → [platform-rel-Facebook] [tp-social] [tp-content][tp-shim-complex][tp-embedded-media][tp-federated-login]
No longer blocks: 1516552

Still blocking

That shim does help with the Facebook federated login buttons, but other uses of the FB SDK are still being blocked while we improve that shim.

Assignee: nobody → dschubert
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 19 duplicates.
:denschub, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dschubert)

As far as I can tell, breakage is worked around with shims and other means, and there is no actual breakage as result of this. If that's the case, S3 seems appropriate.

Flags: needinfo?(dschubert)

We appreciate your report. I was not able to reproduce the issue:
https://prnt.sc/d542SrR1Z2JP

If the reporter or anyone can reproduce the issue, please feel free to reopen the issue.

Tested with:

Browser / Version: Firefox Nightly 111.0a1 (2023-01-18) (64-bit)
Operating System: Windows 10 PRO x64

Suggestion: Try clearing cache/data/cookies, disabling add-ons and Ad-blocker (if available) and extensions or use a clean profile, and check again? If there are any changes made to the default settings of the browser (e.g. in about:config) please revert to the default settings and try again. Also, have the required cookies been accepted for this page?

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.