Closed Bug 874042 Opened 6 years ago Closed 6 years ago

Cookies in a private session are purged when opening a new private window

Categories

(SeaMonkey :: UI Design, defect, major)

defect
Not set
major

Tracking

(seamonkey2.19 fixed, seamonkey2.20 fixed, seamonkey2.21 fixed)

RESOLVED FIXED
seamonkey2.21
Tracking Status
seamonkey2.19 --- fixed
seamonkey2.20 --- fixed
seamonkey2.21 --- fixed

People

(Reporter: rsx11m.pub, Assigned: neil)

References

(Blocks 2 open bugs, )

Details

Attachments

(1 file)

Per observation in bug 872000 comment #6 and following, cookies are purged when opening the first private window (expected), but also when opening subsequent private windows (unexpected). This makes using web applications which open new windows impossible to use in a private session.

Firefox only purges cookies on opening of the first private window, then maintains the same cookie space for all private windows until the last one is closed. The respective web applications run fine with this implementation.

The optimum might be what I've suggested in Firefox bug 864640 comment #1 to open a new cookie space for each new manually invoked private window, but that's likely the most difficult way to implement this (and I'm not sure which other unexpected effects this may introduce).
Attached patch Proposed patchSplinter Review
So, I did some debugging, and I found the backend code has a funky idea of what constitutes a private browsing session.

In particular, if you set the windowtype attribute, this immediately removes the window from the private browsing session, thus clearing all the cookies (because the "last" window was removed from the session).

The workaround is to remove the windowtype attribute, which doesn't remove the window from the private session but does hide it from getMostRecentWindow().
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #760810 - Flags: review?(iann_bugzilla)
Attachment #760810 - Flags: feedback?(rsx11m.pub)
Attachment #760810 - Flags: feedback?(philip.chee)
Ah, yes, I forgot that Firefox doesn't care about any window that's not a navigator:browser.
(In reply to neil@parkwaycc.co.uk from comment #1)
> Created attachment 760810 [details] [diff] [review]
> Proposed patch

This fixes it for me with the web applications I've tested before, so that's good. Also bug 873032 seems to be fixed by this, given that "navigator:private" does no longer create its own window type.

> The workaround is to remove the windowtype attribute, which doesn't remove the
> window from the private session but does hide it from getMostRecentWindow().

This will make a solution for bug 872521 a bit trickier though, given that a theme can no longer identify a private-browsing window based on its windowtype attribute. Maybe adding a privatebrowsingmode="temporary" attribute like Firefox does would help to compensate for the lack of a private-specific windowtype?
Blocks: 872521, 873032
(In reply to rsx11m from comment #3)
> This fixes it for me with the web applications I've tested before, so that's
> good. Also bug 873032 seems to be fixed by this, given that
> "navigator:private" does no longer create its own window type.

I see that too, but I have no idea how that even works...
Comment on attachment 760810 [details] [diff] [review]
Proposed patch

(In reply to neil@parkwaycc.co.uk from bug 872521 comment #6)
> (In reply to rsx11m from bug 872521 comment #5)
> > I've added a dependency on bug 874042 given that it may remove the
> > windowtype attribute specific for private windows.
> You can still style based on that, something like this perhaps:
>   :root:not([windowtype]) #throbber-box {

Ok, I didn't try that but it sounds feasible.
Attachment #760810 - Flags: feedback?(rsx11m.pub) → feedback+
(In reply to neil@parkwaycc.co.uk from comment #4)
> I see that too, but I have no idea how that even works...

Yet another case of "solved by magic" ;-)
Comment on attachment 760810 [details] [diff] [review]
Proposed patch

f=me Although it's a bit hacky.

Any chance this could get fixed in the backend? Or is it too complicated?
Attachment #760810 - Flags: feedback?(philip.chee) → feedback+
Too complicated. There are complex issues involving non-browser windows and private session lifetimes which caused the current focus on navigator:browser windows.
For the time being, I'm sure happy with a "hacky but works" solution. ;-)
It would be nice to still get this into 2.19 to make the feature work properly.
Attachment #760810 - Flags: review?(iann_bugzilla) → review+
Pushed comm-central changeset 7d9d4b2d5284.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.21
Comment on attachment 760810 [details] [diff] [review]
Proposed patch

[Approval Request Comment]
User impact if declined: Very hard to stay logged in while using private windows.
Risk to taking this patch (and alternatives if risky): Very low
String changes made by this patch: None
Attachment #760810 - Flags: approval-comm-beta?
Attachment #760810 - Flags: approval-comm-aurora?
Attachment #760810 - Flags: approval-comm-beta?
Attachment #760810 - Flags: approval-comm-beta+
Attachment #760810 - Flags: approval-comm-aurora?
Attachment #760810 - Flags: approval-comm-aurora+
You need to log in before you can comment on or make changes to this bug.