Preconditions

In about:config set:
extensions.webcompat.enable_shims to true

Affected versions

Firefox 91.0a1
Firefox 90.0b11

Affected platformsimgur

Windows 10 x64
macOS 10.15
Ubuntu 20.04 x64

Steps to reproduce

1. Open Firefox
2. Enable “Strict” Tracking protection via about:preferences#privacy
3. Go to https://www.todoexpertos.com/ or pinterest.com
4. Interact with the website by clicking on a third-party Facebook login button
5. Click on the shield icon -> Tracking Content or Social Media trackers
6. Observe the console

Expected result

Smart block should be triggered after clicking on Facebook login

Actual Result

• Smart block is not triggered even after clicking on Facebook login
• In the console "Facebook SDK is being shimmed by Firefox." but after interacting with the "Continue with Firefox" button there isn't any message in the console that "Facebook SDK is being allowed for this browsing session due to user opt-in."

Note

• Facebook login is still working on pinterest but on todoexpertos I received an error “Login Failed: You can’t use Facebook to log into this app or website because there’s an issue with its implementation of Facebook Login.”

Tom, can you take a look at this? :)

I do see a console error on pinterest.com when I try to log in, which should be fixable (it appears to be related to URL parsing).

But the issue with todoexpertos isn't related to SmartBlock, as I find it happens in ETP standard mode as well on their site. Johann, we should probably figure that out separately, as it's not happening in Chrome.

The console error should be fixed now as of bug 1723752 landing (though it was really just a bit of console spam).

Paul, can you make sure that this is being looked at again in breakage triage? Thanks!

As per our discussion in the last meeting, Tom is looking into this.

The issue is that these sites don't open the login popup directly to Facebook's oauth URL, but rather to their own server (which then redirects to the FB oauth URL). This case isn't handled by the shim properly, so no opt-in is actually performed. In Pinterest's case, things still work out, because they end up falling back to a different method for logging in which doesn't rely on the shim. In TodoExpertos' case, their FB login isn't configured properly anyway, so it's broken regardless of whether I try it in Strict mode or with ETP off, or even in Chrome.

Fixing this case will basically require the FB shim to only inform the SmartBlock background script that the user is opting in, and to listen for popups for the page to actually hit the FB oauth URL after that point, and THEN do the opt-in (rather than the shim to only do this if the window.open call directly open the URL to begin with). I'll investigate this approach ASAP.

I've been experimenting with adjustments to the shim to support these cases (where the user is logged in not via the Facebook SDK's scripted login methods like window.FB.login, but rather by the site loading an frame of their own which they eventually redirect to the FB oauth login form).

What I'm doing is listening for sites which attempt to access FB oauth landing URLs, basically [m|www].facebook.com/*/oauth. If those requests ultimately redirect to the expected URL (implying that oauth has succeeded, and the user has logged in via FB), then I treat that login as an opt-in by the user to allow Facebook's SDK to run on that site.

Amusingly, because I'm waiting until successful login to allow the FB SDK, we actually won't see any UI changes for the two sites listed in this bug report. Pinterest doesn't actually seem to load the FB SDK at all once you've logged in. That means that while you will have opted in, the SDK still won't show up in the shield icon, since it hasn't actually been requested yet.

Likewise, since the user cannot successfully log in on TodoExpertos (due to their FB login being currently broken), the SDK will continue to be blocked and thus won't show up in the Shield icon as "opted in". Perhaps if other users are somehow able to log in with FB on TodoExpertos, then we'll find out, as this should indeed fix the UI indicator once the site tries to load the SDK.

But still, this approach seems like an improvement overall, so I'll continue investigating it and see if I can't find another site hitting this case to test with.