Closed Bug 490198 Opened 11 years ago Closed 11 years ago

Import dialog isn't completely disabled while staying in Private Browsing mode


(Firefox :: Private Browsing, defect)

3.5 Branch
Not set





(Reporter: whimboo, Unassigned)


Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090423 Shiretoko/3.5b4pre ID:20090423163827

With bug 464736 only the front-end was disabled without touching the import dialog itself. Users can still trying to import data by calling the following command inside the error console or an extension could provide this functionality. 

window.openDialog("chrome://browser/content/migration/migration.xul","migration", "modal,centerscreen,chrome,resizable=no");

Disabling the front-end is only the half work. We should also disable the dialog itself.
Flags: blocking-firefox3.5?
1. Start Firefox and switch into Private Browsing mode
2. Enter the given url into the eval field of the Error Console
Summary: Import dialog isn't completely disabled → Import dialog isn't completely disabled while staying in Private Browsing mode
I don't have a problem with disabling it more completely, but I don't think anything that requires users to manually open XUL pages using js eval'd from their error console can block the release of Firefox 3.5.
I'd lean towards WONTFIX, even. It might be valuable to add a global method for opening the migration dialog that takes PB mode into account to avoid the possibility of either internal or extension code forgetting about bug 464736, but I think actively trying to prevent extensions or people evaluating code in the JS console from using this dialog would be a waste of effort and code.
Flags: blocking-firefox3.5?
There are several cases where we only disallow the user's access path to some feature in private browsing mode.  I don't think we should attempt to disable the migration dialog itself to the extent suggested in comment 0, because the next step is to disable the API used by the migration dialog, and so on.

Really, the goal of bug 464736 was to protect against Murphy, not Machavelli.  :-)  If the user/extension is sophisticated enough to figure out the hack in comment 0, they can figure out deeper hacks by themselves.

I'm WONTFIXing based on this rationale.  Please re-open if you have a use case where this could actually hate a user without resorting to such hacks.
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.