If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Should private browsing mode in docshell disable bfcache?

REOPENED
Unassigned

Status

()

Core
Document Navigation
REOPENED
5 years ago
4 years ago

People

(Reporter: smaug, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
Filing this just that I don't forget the issue.
Feel free to mark INVALID if this isn't an issue.

As far as I know we may change private browsing mode of a docshell.
What happens if: We're first in pb and load a page. Then load another page and decide to
un-pb, and then go back. Do we let that page, which was loaded in pb mode to be
re-activated in a docshell which isn't in pb mode anymore?
I thought we weren't trying to support changes in a docShell's PB state after creation.

Comment 2

5 years ago
Yes, I suspect this is a problem that we're not going to bother dealing with.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 3

5 years ago
So we let page which has been loaded in pb mode to be re-activated in non-pb mode?

Currently the code in no way prevents changing the state. If we don't want to let state to be
changed, better to throw an exception if one tries to do it.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Which code are you talking about?  The bf-cache code or the docshell's private flag?

Also, any reason why we should keep this bug hidden?
(Reporter)

Comment 5

5 years ago
Docshell's code. If we don't support changing pb flag after setting it, docshell should
actually throw if someone tries to re-set it.

And yes, I guess we can open this.
Group: core-security
(In reply to comment #5)
> Docshell's code. If we don't support changing pb flag after setting it,
> docshell should
> actually throw if someone tries to re-set it.

I'm not sure if there's a very easy way to detect whether the flag is being set on a "new" docshell or on an "old" docshell...
(Reporter)

Comment 7

5 years ago
By default the flag is not set, right? So after it has been set once, never allow changes.
That would at least prevent the case when a page is first loaded in pb mode and then
navigated back from shistory to docshell which isn't in pb mode anymore.
Is this warning not enough? http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp#2029
(Reporter)

Comment 9

5 years ago
Uh, that is bizarre. Why do we have an attribute in nsIDocshell which warns always when set?
(In reply to comment #9)
> Uh, that is bizarre. Why do we have an attribute in nsIDocshell which warns
> always when set?

That is the only way that external code can set this attribute.  Copies internal to nsDocShell.cpp should all be safe.
You need to log in before you can comment on or make changes to this bug.