Make the nsILoadContext.usePrivateBrowsing property read-only

RESOLVED FIXED in Firefox 19

Status

()

Firefox
Private Browsing
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: Ehsan, Assigned: Ehsan)

Tracking

unspecified
Firefox 19
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

6 years ago
Josh, now that we have everything we need for testing private windows, do you think it still makes sense to support setting the usePrivateBrowsing property from script?

Comment 1

6 years ago
It makes it impossible to support an addon implementing per-tab mode, doesn't it?
(Assignee)

Comment 2

6 years ago
(In reply to comment #1)
> It makes it impossible to support an addon implementing per-tab mode, doesn't
> it?

It does, and I think we have good reason to do so.  Those add-ons will be partially broken today (because we cache the privacy bit in some cases) and it would be extremely hard if not impossible to keep everything working in a way which doesn't break all such add-ons, except if we end up with an API which puts a tab's docshell in PB mode as soon as it's created.  Thinking more about this, mobile might need this since all they have is a single window, so we can revisit the decision of not supporting such add-ons in the future, but they won't need to be able to set this flag anyway.
(Assignee)

Comment 3

6 years ago
So, looking closer into this, we have a while bunch of call sites in tests which set this property in order to test stuff.  We also have a couple of call sites in the front-end which call this which will eventually go away.

So, perhaps making this property read-only is not really practical after all.  Josh, what do you think about just printing a warning to the error console saying that this method is internal and is not meant to be used by folks, etc.?

Comment 4

6 years ago
How would you implement the warning, precisely? The docshell tree stuff uses the setter to propagate the value downwards.
(Assignee)

Comment 5

6 years ago
Created attachment 676905 [details] [diff] [review]
Patch (v1)

Like this.
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #676905 - Flags: review?(bzbarsky)

Comment 6

6 years ago
Comment on attachment 676905 [details] [diff] [review]
Patch (v1)

That doesn't look like it actually addresses my comment, does it? Won't we always see this warning when creating a new private window, tab in a private window, a content page attaches an iframe, etc.?
(Assignee)

Comment 7

6 years ago
(In reply to Josh Matthews [:jdm] from comment #6)
> Comment on attachment 676905 [details] [diff] [review]
> Patch (v1)
> 
> That doesn't look like it actually addresses my comment, does it? Won't we
> always see this warning when creating a new private window, tab in a private
> window, a content page attaches an iframe, etc.?

Ah, hmm, yeah you're right...  How about if I only do this when there is a JS caller?

Comment 8

6 years ago
What does a JS caller mean, precisely? That sounds like it could still trigger if JS invokes opening a new private window.
(Assignee)

Comment 9

6 years ago
(In reply to comment #8)
> What does a JS caller mean, precisely? That sounds like it could still trigger
> if JS invokes opening a new private window.

Yeah..  you're right.  I can't seem to think of any other solutions... :/
We can always use a noscript non-warning method for our internal docshell uses, right?
(Assignee)

Comment 11

6 years ago
(In reply to Boris Zbarsky (:bz) from comment #10)
> We can always use a noscript non-warning method for our internal docshell
> uses, right?

Yes, that's true.  I'll give that a shot next.
(Assignee)

Comment 12

6 years ago
Created attachment 677740 [details] [diff] [review]
Patch (v2)
Attachment #676905 - Attachment is obsolete: true
Attachment #676905 - Flags: review?(bzbarsky)
Attachment #677740 - Flags: review?(bzbarsky)
Comment on attachment 677740 [details] [diff] [review]
Patch (v2)

r=me
Attachment #677740 - Flags: review?(bzbarsky) → review+
https://hg.mozilla.org/mozilla-central/rev/b940cf551019
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 19

Comment 16

5 years ago
This bug breaks "Private Tab" functionality... I really hope there IS workardound as having private tabs is one of the fetures I have been waiting for a LOOONG time :(
(Assignee)

Comment 17

5 years ago
(In reply to comment #16)
> This bug breaks "Private Tab" functionality... I really hope there IS
> workardound as having private tabs is one of the fetures I have been waiting
> for a LOOONG time :(

Which private tab functionality?

Comment 18

5 years ago
This addon allows creation of a private tab: https://addons.mozilla.org/en-US/seamonkey/addon/private-tab/
You need to log in before you can comment on or make changes to this bug.