1226498 - tracking protection blocks async load of facebook js sdk

Status: RESOLVED FIXED

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

Description

[m.moeseneder]

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

Comment 1

[Dakoda]

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?

Comment 2

[yan]

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

Comment 3

[Chris Peterson [:cpeterson]]

François, who owns triaging Tracking Protection breakage? Is this an evangelism issue?

Comment 4

[François Marier [: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.

Comment 5

[Javaun Moradi [:javaun]]

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.

Comment 6

[isaacmray1984]

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.

Comment 10

[u554345]

I think that block by default Facebook and Twitter is a error, the common users not know how disable Tracking Protection generate too incidents.

Comment 16

[Sergiu Logigan [:sergiu]]

As this is a pretty old issue, we are wondering if this is still reproducible.

Comment 17

[François Marier [:francois]]

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.

Comment 18

[Sergiu Logigan [:sergiu]]

Investigated Bug 1163771

It's still reproducible.

Comment 19

[Nick S]

I was able to replicate it too.

Comment 21

[Nick S]

Is this resolved in Firefox v62.0.3?

Comment 22

[susso0]

(In reply to Nick S from comment #21)
> Is this resolved in Firefox v62.0.3?

In firefox 64 still the bug

Comment 24

[kshamaz]

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.

Comment 25

[(no longer active)]

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

Comment 26

[susso0]

It is enabled by default in all the browser: https://support.mozilla.org/en-US/kb/what-happened-tracking-protection

Comment 27

[Thomas Wisniewski [:twisniewski]]

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.

Comment 28

[Thomas Wisniewski [:twisniewski]]

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

Comment 29

[Thomas Wisniewski [:twisniewski]]

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.

Comment 30

[Thomas Wisniewski [:twisniewski]]

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

Comment 32

[Thomas Wisniewski [:twisniewski]]

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

Comment 33

[Thomas Wisniewski [:twisniewski]]

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.

Comment 37

[Thomas Wisniewski [:twisniewski]]

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.

Comment 39

[Thomas Wisniewski [:twisniewski]]

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.

Comment 46

[Chandima]

Still blocking

Comment 47

[Mathew Hodson]

Does the Facebook SDK shim added in bug 1637329 help? It's enabled in Firefox Nightly.

https://searchfox.org/mozilla-central/rev/2e592c660fbed485a5376be8d14fde99671a4df3/browser/extensions/webcompat/data/shims.js#147

Comment 48

[Thomas Wisniewski [:twisniewski]]

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.

Comment 49

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 50

[Dennis Schubert [:denschub]]

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.

Comment 51

[Raul Bucata]

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?