Open Bug 823467 Opened 12 years ago Updated 2 years ago

Should private browsing mode in docshell disable bfcache?

Categories

(Core :: DOM: Navigation, defect)

x86
Linux
defect

Tracking

()

REOPENED

People

(Reporter: smaug, Unassigned)

Details

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.
Yes, I suspect this is a problem that we're not going to bother dealing with.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
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?
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...
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.
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.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.