Closed Bug 1485005 Opened Last year Closed Last year

Tracking cookie restrictions breaks Facebook like button


(Firefox :: Protections UI, defect, P2)




Firefox 63
Tracking Status
firefox63 --- verified


(Reporter: timhuang, Assigned: ehsan)


(Blocks 1 open bug)



(2 files)

  - set 'network.cookie.cookieBehavior' to 4

1. Visit and navigate to any news which has a like button in it.
2. Click the like button and log in with a Facebook account.

Expected result:
  - The like button is checked.

Actual result:
  - Nothing happens to the like button
  - If you click the like button again, it will pop-up a window and disappear immediately. Still, nothing happens to the like button again.

Affected version:
63.0a1 (2018-08-21) (64-bit) (build id: 20180821100053)

  - The same problem is reproducible for other websites including
Where do you find the like buttons on these sites?  (I don't speak the languages.  :-)
Flags: needinfo?(tihuang)
Hi Ehsan,

You can find one like button on the left side of the page
Flags: needinfo?(tihuang)
Thanks, I can reproduce on

Looks like what's happening is that after the user interaction heuristic kicks in and we grant the "3rdPartyStorage^" permission to this site, the HTTP requests on the original page to will be submitted without cookies still.  If the original page is reloaded after this point, the HTTP requests on the original page will now be submitted with cookies and everything will work correctly after that.
Blocks: 1485088
No longer blocks: etp-breakage
Priority: -- → P3
Blocks: etp-breakage
No longer blocks: 1485088
Depends on: 1485099
OK, I found two places where I think we're using the wrong principal objects, and fixing them fixes the bug.  I would prefer for baku to review these changes when he gets back...
This is the fix for the bug.  In this case, the top-level principal is
picked from the loading principal of the load info object, and it is
different from the triggering principal.

Since we already fall back to the triggering principal while computing
the top-level principal, there is no need to do that explicitly here.
In fact we need all of the same rules as previously implemented above
in the same function, so we may as well use the toplevelPrincipal

I couldn't think of a good way to write a test case for this, sadly.
This isn't related to this bug report, but while reading this code,
I noticed that we are using the wrong principal object here too.
Assignee: nobody → ehsan
Priority: P3 → P2
Pushed by
Part 1: Fall back to the top-level principal when computing the parent principal on the channel code path for IsFirstPartyStorageAccessGrantedFor(); r=baku
Part 2: Get the cookie behavior from the top-level principal on the channel code path for IsFirstPartyStorageAccessGrantedFor(); r=baku
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → Firefox 63
I reproduced this issue using Fx 63.0a1(2018-08-21)on Windows 10 x64.
I can confirm this issue is fixed, I verified using Fx 63.0b13, on Windows 10 x64, macOS 10.13.6 and Ubuntu 14.04 LTS.
You need to log in before you can comment on or make changes to this bug.