Closed Bug 1566825 Opened 4 months ago Closed 3 months ago

[Pinterest] Login on pinterest using google account while in Private Browsing mode is not possible

Categories

(Core :: Privacy: Anti-Tracking, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla70
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox68 --- unaffected
firefox69 - disabled
firefox70 --- verified

People

(Reporter: simona.marcu, Assigned: ehsan)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(3 files)

Attached video 2019-07-17_16h28_07.mp4

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0
Build ID: 20190717093640

[Affected versions]:
latest Nightly 70.0a1
Firefox 69 beta 5

[Affected platforms]:
Windows 10
Ubuntu 18.04
Mac OS X

[Steps to reproduce]:

  1. Open Firefox
  2. Open menu -> and open a New Private Window
  3. Log into Pinterest using your Google account

[Expected result]:
Fx successfully completes the log-in process to Pinterest using the Google account.

[Actual result]:
The login is not completed, after entering your Google credentials you are taken back to the login page.
For more details, please see the attached screencast.

This scenario is not reproducible on Firefox 68 release.
This issue is not reproducible when Firefox is in normal mode.
The log in to Pinterest using your Facebook account is properly done.
I will work on the regression range as soon as possible.

Component: Desktop → Private Browsing
Product: Web Compatibility → Firefox

@Simona, any luck on finding that regression range?
@Ehsan, is this possibly related to ETP?

Flags: needinfo?(simona.marcu)
Flags: needinfo?(ehsan)

Hi, here are the results from mozregression, it seems that Bug 1505931 is the culprit here:

changeset: c466f72acdec9998b647307d582e52bb46454ab6
pushlog_url: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ad63f8b4f0cd9d460dd6368d19fc78f776f3b65b&tochange=c466f72acdec9998b647307d582e52bb46454ab6

Flags: needinfo?(simona.marcu)
Regressed by: 1505931

(In reply to Simona Badau from comment #2)

Hi, here are the results from mozregression, it seems that Bug 1505931 is the culprit here:

changeset: c466f72acdec9998b647307d582e52bb46454ab6
pushlog_url: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ad63f8b4f0cd9d460dd6368d19fc78f776f3b65b&tochange=c466f72acdec9998b647307d582e52bb46454ab6

I believe this "regression" just means that this bug can be caused when ETP level 2 blocking is turned on inside private windows.

From the anti-tracking log right after clicking on the "Continue with Google" button on the login page, we have:

[Child 5032: Main Thread]: D/AntiTracking Adding a first-party storage exception for https://accounts.google.com...
[Child 5032: Main Thread]: D/AntiTracking The current resource is first-party
[Child 5032: Main Thread]: D/AntiTracking Computing whether window 0000020FBB30D420 has access to URI https://www.pinterest.ca/
[Child 5032: Main Thread]: D/AntiTracking Our window isn't a third-party tracking window
[Child 5032: Main Thread]: D/AntiTracking Computing whether window 0000020FBB30D420 has access to URI https://www.pinterest.ca/
[Child 5032: Main Thread]: D/AntiTracking Our window isn't a third-party tracking window
[Child 5032: Main Thread]: D/AntiTracking Asking the parent process to save the permission for us: trackingOrigin=https://accounts.google.com, grantedOrigin=https://accounts.google.com
[Child 5032: Main Thread]: D/AntiTracking Computing whether window 0000020FBF01E820 has access to URI https://accounts.google.com/o/oauth2/iframe#origin=https%3A%2F%2Fwww.pinterest.ca&rpcToken=1818551667.6760478&clearCache=1
[Child 5032: Main Thread]: D/AntiTracking Deciding whether the user has overridden content blocking for https://www.pinterest.ca/
[Child 5032: Main Thread]: D/AntiTracking No user override found
[Child 5032: Main Thread]: D/AntiTracking Failed to obtain the parent principal and the tracking origin

So yes, I believe this is indeed caused by ETP. I will look at this more.

See Also: → 1570430
Component: Private Browsing → Privacy: Anti-Tracking
Product: Firefox → Core

This is caused because we bail out early here since we're in private mode:
https://searchfox.org/mozilla-central/rev/b38e3beb658b80e1ed03e0fdf64d225bd4a40327/toolkit/components/antitracking/AntiTrackingCommon.cpp#81

even though we already support handling private browsing mode correctly everywhere else in this code. :-(

Assignee: nobody → ehsan
Flags: needinfo?(ehsan)
Regressed by: 1469714
No longer regressed by: 1505931
Depends on: 1570801
Depends on: 1570802

I have fixes for the bug itself. I filed a couple of follow-up bugs for the left-over work that I didn't have time to finish today. But let's fix this bug for now...

(In reply to :Ehsan Akhgari from comment #5)

I have fixes for the bug itself. I filed a couple of follow-up bugs for the left-over work that I didn't have time to finish today. But let's fix this bug for now...

Actually there's one last test failure which I didn't get to fix today.

This was reverted in bug 1525245 part 2 without any apparent reason.

Pushed by eakhgari@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/15de0b815be9
Part 1: Switch back to using TestPermissionWithoutDefaultsFromPrincipal(); r=baku
https://hg.mozilla.org/integration/autoland/rev/7fcd3effcc45
Part 2: Support storing and querying for anti-tracking permission grants in private windows; r=baku
Flags: needinfo?(ehsan)
Pushed by eakhgari@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ee9bda8ba5b4
Part 1: Switch back to using TestPermissionWithoutDefaultsFromPrincipal(); r=baku
https://hg.mozilla.org/integration/autoland/rev/e8ad4083b9bc
Part 2: Support storing and querying for anti-tracking permission grants in private windows; r=baku
See Also: 1570430
Duplicate of this bug: 1570430
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
Flags: qe-verify+

[Tracking Requested - why for this release]:

Note that I don't think this requires a backport to beta, since it only impacts Firefox when ETP with Level 2 blocking is turned on, which affects early betas only at this point, so fixing this only on trunk should be sufficient.

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0
Build ID:20190807215212

Verified as fixed on the latest Nightly 70.0a1 - tested on Windows 10 x64-bit, Mac OS X 10.15 and Ubuntu 18.04x64-bit.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.