The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in seamonkey2.21

Status

SeaMonkey
UI Design
--
major
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: rsx11m, Assigned: neil@parkwaycc.co.uk)

Tracking

(Blocks: 2 bugs)

Trunk
seamonkey2.21
Dependency tree / graph

SeaMonkey Tracking Flags

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

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
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).
(Assignee)

Comment 1

4 years ago
Created attachment 760810 [details] [diff] [review]
Proposed patch

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)
(Assignee)

Updated

4 years ago

Comment 2

4 years ago
Ah, yes, I forgot that Firefox doesn't care about any window that's not a navigator:browser.
(Reporter)

Comment 3

4 years ago
(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
(Assignee)

Comment 4

4 years ago
(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...
(Reporter)

Comment 5

4 years ago
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+
(Reporter)

Comment 6

4 years ago
(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 7

4 years ago
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+

Comment 8

4 years ago
Too complicated. There are complex issues involving non-browser windows and private session lifetimes which caused the current focus on navigator:browser windows.
(Reporter)

Comment 9

4 years ago
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.

Updated

4 years ago
Attachment #760810 - Flags: review?(iann_bugzilla) → review+
(Assignee)

Comment 10

4 years ago
Pushed comm-central changeset 7d9d4b2d5284.
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.21
(Assignee)

Comment 11

4 years ago
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?

Updated

4 years ago
Attachment #760810 - Flags: approval-comm-beta?
Attachment #760810 - Flags: approval-comm-beta+
Attachment #760810 - Flags: approval-comm-aurora?
Attachment #760810 - Flags: approval-comm-aurora+
(Assignee)

Comment 12

4 years ago
https://hg.mozilla.org/releases/comm-aurora/rev/b6c2f215640a
http://hg.mozilla.org/releases/comm-beta/rev/aa4aa44c5a7f
status-seamonkey2.19: --- → fixed
status-seamonkey2.20: --- → fixed
status-seamonkey2.21: --- → fixed
You need to log in before you can comment on or make changes to this bug.