Closed Bug 1485005 Opened Last year Closed Last year

Tracking cookie restrictions breaks Facebook like button

Categories

(Firefox :: Protections UI, defect, P2)

defect

Tracking

()

VERIFIED FIXED
Firefox 63
Tracking Status
firefox63 --- verified

People

(Reporter: timhuang, Assigned: ehsan)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Preference:
  - set 'network.cookie.cookieBehavior' to 4

STR:
1. Visit de.ign.com 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)

notes:
  - The same problem is reproducible for other websites including
    - www.ltn.com.tw
    - anywhere.ebay.de
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 http://news.ltn.com.tw/news/politics/breakingnews/2526405
Flags: needinfo?(tihuang)
Thanks, I can reproduce on http://news.ltn.com.tw.

Looks like what's happening is that after the user interaction heuristic kicks in and we grant the "3rdPartyStorage^https://www.facebook.com" permission to this site, the HTTP requests on the original page to facebook.com 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
variable.

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 eakhgari@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/36601124b6ad
Part 1: Fall back to the top-level principal when computing the parent principal on the channel code path for IsFirstPartyStorageAccessGrantedFor(); r=baku
https://hg.mozilla.org/integration/mozilla-inbound/rev/9f2c780bb92b
Part 2: Get the cookie behavior from the top-level principal on the channel code path for IsFirstPartyStorageAccessGrantedFor(); r=baku
https://hg.mozilla.org/mozilla-central/rev/36601124b6ad
https://hg.mozilla.org/mozilla-central/rev/9f2c780bb92b
Status: NEW → RESOLVED
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.