tracking protection blocks async load of facebook js sdk
Categories
(Web Compatibility :: Site Reports, defect, P3)
Tracking
(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
Reporter | ||
Updated•8 years ago
|
Updated•8 years ago
|
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
Comment 3•8 years ago
|
||
François, who owns triaging Tracking Protection breakage? Is this an evangelism issue?
Comment 4•8 years ago
|
||
(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•8 years ago
|
||
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•8 years ago
|
||
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.
Updated•8 years ago
|
Updated•8 years ago
|
Updated•8 years ago
|
Updated•8 years ago
|
Comment 10•8 years ago
|
||
I think that block by default Facebook and Twitter is a error, the common users not know how disable Tracking Protection generate too incidents.
Updated•8 years ago
|
Updated•8 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Updated•6 years ago
|
Comment 16•6 years ago
|
||
As this is a pretty old issue, we are wondering if this is still reproducible.
Comment 17•6 years ago
|
||
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.
Updated•6 years ago
|
Comment 18•6 years ago
|
||
Investigated Bug 1163771 It's still reproducible.
Comment 19•6 years ago
|
||
I was able to replicate it too.
Updated•6 years ago
|
Comment 21•6 years ago
|
||
Is this resolved in Firefox v62.0.3?
Comment 22•6 years ago
|
||
(In reply to Nick S from comment #21) > Is this resolved in Firefox v62.0.3? In firefox 64 still the bug
Comment 24•5 years ago
|
||
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•5 years ago
|
||
It is enabled by default in private windows and has been so since around November 2015.
Updated•5 years ago
|
Comment 26•5 years ago
|
||
It is enabled by default in all the browser: https://support.mozilla.org/en-US/kb/what-happened-tracking-protection
Comment 27•4 years ago
•
|
||
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•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
•
|
||
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•4 years ago
|
||
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.
Updated•4 years ago
|
Updated•3 years ago
|
Comment 46•3 years ago
|
||
Still blocking
Comment 47•3 years ago
|
||
Does the Facebook SDK shim added in bug 1637329 help? It's enabled in Firefox Nightly.
Comment 48•3 years ago
|
||
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.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•2 years ago
|
Comment 49•1 year ago
|
||
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.
Assignee | ||
Comment 50•1 year ago
|
||
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•1 year ago
|
||
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?
Description
•