Closed Bug 1485005 Opened Last year Closed Last year
Tracking cookie restrictions breaks Facebook like button
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. :-)
Hi Ehsan, You can find one like button on the left side of the page http://news.ltn.com.tw/news/politics/breakingnews/2526405
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.
Some early testing shows that the problem seems to be that when clicking on the like button, this URL <https://www.facebook.com/plugins/like.php?href=http://news.ltn.com.tw/news/politics/breakingnews/2526405&ret=optin&act=connect&hash=XXXXXXXXXXXXX> is opened with the triggering principal of the pop-up window (aka <https://www.facebook.com/plugins/close_popup.php?reload=https%3A%2F%2Fwww.facebook.com%2Fplugins%2Flike.php%3Fhref%3Dhttp%253A%252F%252Fnews.ltn.com.tw%252Fnews%252Fpolitics%252Fbreakingnews%252F2526405%26ret%3Doptin%26act%3Dconnect%26hash%3DXXXXXXXXXXXXXX#_=_>)
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.
Pushed by email@example.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
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.