Closed Bug 204285 Opened 20 years ago Closed 10 years ago

file:// URLs cannot have popups unblocked

Categories

(Core :: Permission Manager, defect)

Product:
Core
Component:
Permission Manager
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla21

People

(Reporter: paxunix, Assigned: mounir)

References

(Blocks 1 open bug)

Details

(Whiteboard: [workaround: comment 51/52])

Attachments

(4 files, 1 obsolete file)

Test case document
59 bytes, text/html
Details
permission manager testcase, uses enhanced privileges
957 bytes, text/html
Details
patch?
4.54 KB, patch
jaws
: review-
Details | Diff | Splinter Review
patch
1.65 KB, patch
jaws
: review-
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030426 Mozilla Firebird/0.6
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030426 Mozilla Firebird/0.6

If the body element in a file:// URL document has an onload handler and the user
has popup blocking enabled, the blocked-popup indicator icon will appear when
loading that document via the file URL.  Clicking the indicator icon opens the
dialog that shows which pages had popups blocked.  All this is as expected.  If
I click the 'Unblock Site' button to unblock the file:// page, I receive an
alert 'will now be able to open unrequested popup windows' and the URL is
removed from the blocked list.  The indicator remains, and reloading the page
gives the same behavior.

Reproducible: Always

Steps to Reproduce:
1. Create document with a body element that has an onload handler that opens a
window.  Save this document to your local hard drive.
2. Choose File|Open File and load that document, click the blocked-popup indicator.
3. Select the URL you just loaded from the list.  Click Unblock Site.




Expected Results:  
It is certainly consistent to block popups from file:// URLs, but at least allow
them to be added to the unblocked list.  It may be more feasible/sensible to
simply allow popups if the origin is a file:// URL.

This is annoying if you regularly keep popup blocking enabled but are working
with web pages on local storage that need to open windows from onload handlers.
Attached file Test case document — 
Enable popup blocking, save this attachment to a local file and open it.  Try
to unblock the URL to see the issue.
Confirmed using a Linux build

OS --> All
Status --> New

Don't be surprised to see this WONTFIXed some day though. It would seem to be a
lot of work for a fairly minor issue, and if you run a local webserver through
localhost the pop-up unblocking works.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 98 → All
I create Web Slide Shows of my photo library and this is a problem for me
because my web pages popup a window for the accompanying music.  My work around
now is to use IE but I prefer not to use IE :-(  I hope it can be fixed?
QA Contact: asa
*** Bug 220797 has been marked as a duplicate of this bug. ***
*** Bug 225759 has been marked as a duplicate of this bug. ***
Severity: trivial → major
Can someone clarify if I understand the meaning of this bug correctly?  The way
I understand it, is that you can NOT add file:// type URLs to the list of sites
that are allowed to open pop-ups.
Either that, or you can add them (and they appear in the list), but Firebird
still blocks the pop-ups.
This bug/behavior breaks certain features of Lotus Sametime Client.
Specifically, Sametime uses a local file to open a new window with a specific
size. Sametime works with IE, and it works with Mozilla with popup blocking
turned off.
This seems to work now on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8b) Gecko/20050204 Firefox/1.0+. Can anyone confirm?
(In reply to comment #8)
> This seems to work now on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.8b) Gecko/20050204 Firefox/1.0+. Can anyone confirm?

Still doesn't work on firefox Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;
en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Blocks: popups
Assignee: bross2 → nobody
QA Contact: general
Is this bug still valid on Firefox > 2? There is no "Unblock Site" button any more in the UI. Moreover, you can unblock file:// URLs by going in Preferences > Content > pop-up windows Exceptions, and remove the scheme:file entry.
This is still present in Firefox 3 Beta 2. I don't remember seeing this with Firefox 3 Beta 1 though. This is definitely a major problem, as now I have to use IE to do something! Any issue that makes you have to use IE is a major issue!
This was fixed since a long time ago, but regressed again when bug 400097 was fixed.
Blocks: 400097
Attached patch patch? (obsolete) — — Splinter Review 
This fixes it for me.
Attachment #300930 - Flags: review?(dwitte)
Flags: blocking-firefox3?
Comment on attachment 300930 [details] [diff] [review]
patch?

>Index: extensions/cookie/nsPermissionManager.cpp
>===================================================================
>-  if (NS_FAILED(rv) || aResult.IsEmpty())
>+  if (NS_FAILED(rv))
>     return NS_ERROR_UNEXPECTED;

so, the problem with this is that any URI without a host (irrespective of scheme, path etc) will get dumped in the same boat - whether you're setting the permission or testing it. and UI has to deal appropriately, which it doesn't atm - would need to check for blank hosts and display "(none)", for instance - and possibly even allow setting a blank entry (e.g. in the text entry box in the cookie/popup/image permissionviewers). fyi, the schemes i know can have empty hosts now are file:// and data://, possibly more.

what we used to do before bug 400097 landed was use the scheme if the host was blank, which i removed because it seems hackish. we could add that back again, which would mean the UI could then display something like "file://" in place of a host, but i'm not enthusiastic to do so.

a third option would be to keep throwing like we do now, and change all the consumers that set/test permissions to deal with the throw and do something sensible. (in the case of popup blocking - allow the popup? what does it do in similar failure cases now?)

any thoughts?
nice to have, I don't think this blocks at this point.

option 3 seems to make the most sense to me.
Flags: wanted-firefox3+
Flags: blocking-firefox3?
Flags: blocking-firefox3-
This is not "nice to have". As I mentioned in comment 12, this used to work in Firefox 2 but regressed again during the Firefox 3 timeframe.
(In reply to comment #15)
> a third option would be to keep throwing like we do now, and change all the
> consumers that set/test permissions to deal with the throw and do something
> sensible. (in the case of popup blocking - allow the popup? what does it do in
> similar failure cases now?)
> 
> any thoughts?

So popups would always be allowed for local pages? That seems like a bad idea to me.
Why shouldn't nsIPermissionManager be able to deal with local file urls?
It seems to me that it at least should be documented in nsIPermissionManager.idl, that it doesn't handle file urls.
Version: unspecified → Trunk
The same bug happends with Firefox 3.0 for Linux. I use flash to open popup from a local file (file://) and the popup is blocked. I can't say to firefox to ignore popup for theses local file.

When I click on the bottom icon, it says me "Accept popup from ". When I click on it, nothing happends, so I can't find a way to open popup from flash on a local file.

On top of that, when I add "scheme:file" in the white list, it just writes "scheme", and the popup are blocked as usual.
Blocks: 256039
Will this ever be resolved???

HHHHHHEEEEEEEELLLLLLLLLLLLLLLLPPPPPPPPPPPPPP!!!!!!!!!!!!
Flags: blocking-firefox3.1?
Definitely not a blocker.
Flags: blocking-firefox3.1? → blocking-firefox3.1-
With 16 votes this seems to be the main page for this problem. The following appear to be duplicates of this bug, Bug 416747, Bug 256039, Bug 253487, Bug 204328.

In Firefox 3.0 the only way I could workaround it for my local file application was to use javascript to set navigator.preference("dom.disable_open_during_load", false) (Block/Unblock popups), then open the popup, and then reset the pref to what it was originally. This is a messy solution though since you also need to set user_pref("security.fileuri.strict_origin_policy", false) plus set privileges (UniversalPreferencesWrite/Read)and you get a security prompt.

I hope somebody can solve this since it will mess up many local applications. I lost ages on it trying to figure out what was wrong before finding it was a bug. Thought maybe I had to use user_pref("capability.policy.localfile.Window.open", "allAccess") but that was a dead end since it is always overridden by dom.disable_open_during_load.
Correction for my workaround you don't need to set user_pref("security.fileuri.strict_origin_policy", false)
I think the patch here will result in chrome://, about: and any other urls without a host (http, https, ftp) to be handled, which may in turn result in crashes (null derefs).

I'm also not sure how this helps as permissions can't be added for uris without a host afaik...
This first post was on 2003-05-02 22:04:12 PDT.  That was 6 1/2 years ago!!!!!!

We're now up to Firefox ver. 3.5.6 and there's STILL no fix for this.  WTF??????  I'm really sick of dealing with this B.S.!!!!!

FIX THIS DA** PROBLEM!!!!!!!!!!!!!
This is still present in Firefox 3.6

For me it is preventing the way Cisco has implemented the launch of a locally installed version of SDM. I have to disable the popup blocker completely to get it working.

I'd suggest that rather than enabling it for all scheme:file it should be possible to specify a file or directory so the security exposure is minimised.
Patch https://bugzilla.mozilla.org/attachment.cgi?id=464750 from bug 546857 added "<file>" stuff in the permissionmanager for CommonTestPermission.
So I guess "<file>" support should be added for the other methods of permissionmanager.
Then the frontend code of Firefox can be adjusted to support this.
Attached patch patch? — — Splinter Review 
This basically copies the code from bug 546857.
Attachment #300930 - Attachment is obsolete: true
Attachment #471509 - Flags: review?(dwitte)
Attachment #300930 - Flags: review?(dwitte)
Attached patch patch — — Splinter Review 
This fixes the ui a bit.
Attachment #471524 - Flags: review?(dwitte)
I don't think we should make it so that allowing popups for one file, enables it for all files. Especially if we add UI for other, more riskier, policies.

Our same-domain policy for file:// is pretty complicated, but if we could make it so that if you apply a policy for file://foo/bar/baz.html, then that policy applies only to file://foo/bar and nothing else.

Btw, we do use the uri of the principal when setting these policies, right? Not the uri of the document?
Sorry, I meant to say that it should apply to file://foo/bar and all files and subdirectories within it, but not to file://foo or file://foo/sweden
(In reply to comment #34)
> Our same-domain policy for file:// is pretty complicated, but if we could make
> it so that if you apply a policy for file://foo/bar/baz.html, then that policy
> applies only to file://foo/bar and nothing else.

I guess the relevant code to do such a thing is here:
http://mxr.mozilla.org/mozilla-central/source/caps/src/nsPrincipal.cpp#417
It looks to me like bug 442589 is a duplicate of this bug. It's been sitting as unconfirmed for over two years now. Please mark it appropriately.
Use popup for video-projector with a local html file and JS
(local webserver is not a good workaround as it takes more place, require to launch extra service/program, and witch must come with a version for each OS)
Still a problem in 7.0.1

I voted because it's not trivial.  There's a big difference for an html hacker/designer between launching an html file by simply double-clicking it and downloading and installing and configuring a localhost server.

Also, there's a big difference between sending some arbitrary client a prototype html file to double-click and asking some arbitrary client to install a localhost server first (or between sending a file and setting up a secure domain/folder with some web hosting company).
I am having the same problem with Firefox 8.0

This bug is very old, and has major priority, can someone please take a look so we can close this bug?
Attachment #471509 - Flags: review?(dwitte) → review-
Comment on attachment 471524 [details] [diff] [review]
patch

Clearing reviews on these patches based on comment #34.
Attachment #471524 - Flags: review?(dwitte) → review-
Let's face it.  They obviously couldn't care less about their users.  This issue started with Firefox 3 and has NEVER been fixed.  I'm guessing it NEVER will be.  

Has anyone tried Google Chrome?  Maybe they appreciate users and actually address issues within a decade!!
This could be fixed by anybody, it's probably not that difficult. See comment 36 of how to fix this.
For me, that code in 36 might as well be Sanskrit.  ROFL!!
If you want to turn off all "file://" popups, use "<file>" (sans quotes) in the popup blocker list.
Argh, I meant turn *on* popups, and popup *unblocker* list.
(In reply to C Khan from comment #51)
> If you want to turn off all "file://" popups, use "<file>" (sans quotes) in
> the popup blocker list.

YOU'RE A FREAKIN' GENIUS!!!!!!!   We've fought with this for YEARS and you fixed it in SECONDS!!   I gotta say it again, YOU'RE A FREAKIN' GENIUS!!!!!
Er I only got it from comment 31, but I'll take the praise :-)
We still have to adjust the frontend to me bore intuitive.
OK.  One problem resolved but it created another one.  :(

First of all, I know this is somewhat unrelated so if you need to delete/move this, feel free.

I have a script that will open my browser window outside of my screen (left and top are negative) so I don't have to see the the menu bar and left section of a page.  Just save a little real estate.   It's been perfect for years but now that it'll open like it's supposed to, it opens the window at 0,0.  Any ideas on how to fix this??

I got this script from a friend who's no longer with us and this kinda stuff is over my head!  Thanks for the help!!

function popup(URL) {
day = new Date();
id = day.getTime();
eval("page" + id + " = window.open(URL, '" + id + "', 'directories=0,status=0,toolbar=1,scrollbars=1,location=0,statusbar=0,menubar=0,resizable=0,width=1365,height=705,left = -274,top = -210');");
top.opener = self
top.close()
}
// End -->
</sc
,left= -274,top = -210'

Both are set to negative values which should put the window at screen position 0.0 since it can not go negative.

NOTE: I've read that "top" is only recognized by IE but I think I remember using it in Firefox as intended.

Anyway change those two items to something positive & play with it, perhaps one at a time to see what each does.

Phil
(In reply to Philip Karras from comment #57)
> ,left= -274,top = -210'
> 
> Both are set to negative values which should put the window at screen
> position 0.0 since it can not go negative.
> 
> NOTE: I've read that "top" is only recognized by IE but I think I remember
> using it in Firefox as intended.
> 
> Anyway change those two items to something positive & play with it, perhaps
> one at a time to see what each does.
> 
> Phil

I've had these set to negatives and used them for over a year with Firefox.  Once I set <file> it stopped putting them where they were supposed to be.  I removed the <file> and the windows open beyond the screen (i.e. -274x-210) like I need them to.
I understand that but you have changed something, you added "<file>", so you may now need to change these to work with this change. it happens, so give it a try so we know what changing these items does. These were defined as the items used to position the window when it opens up & were never intended to be negative as far as I understand.
Could somebody entitled to to so please set this bug to SOLVED as it actually seems to be solved in its original version. I had the respective problem and interpreted the status NEW as "not solved" yet. Reading through the comments for curiosity reasons then unexpectedly led me to the solution in #51/52.
Works fine for me (13.0.1).
(In reply to yee-haw from comment #60)
> Could somebody entitled to to so please set this bug to SOLVED as it
> actually seems to be solved in its original version. I had the respective
> problem and interpreted the status NEW as "not solved" yet. Reading through
> the comments for curiosity reasons then unexpectedly led me to the solution
> in #51/52.
> Works fine for me (13.0.1).

yee-haw, I'm glad the workaround of comment 50 and comment 51 works for you. However, it is completely undiscoverable from the UI.
Pls follow instructions of comment 1 with testcase attachment 122368 [details] to see that the original problem of this bug (comment 0) is not solved, at all.
Whiteboard: [workaround: comment 51/52]
Assignee: nobody → mounir
Severity: major → normal
Status: NEW → RESOLVED
Closed: 10 years ago
Component: General → Permission Manager
Flags: wanted-firefox3+
Flags: in-testsuite+
Flags: blocking-firefox3.5-
Flags: blocking-firefox3-
Product: Firefox → Core
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
The Problem is not fixed in Firefox 50.1.0. 
When adding "<file>" without quotes to exceptions, "http://" automatically appears just before "<file>". "http://" can't be deleted.
"<file>" stuff has been removed far back because you should be able to unblock file:/// urls normally since Firefox 21. See bug 815640.
Thank you, I tested as you described and popups opened without any problems in Firefox 50.1.0.
It is not working in Seamonkey 2.46, but I'll post this to Seamonkey forum.

Three years later, apparently this has changed again, and neither file:// nor file:/// unblocks popups for file URLs. I've also tried file:///* and file:///path/to/directory/ which is really what I want, but the only thing that actually works is a full file:///path/to/directory/filename.html (for every HTML file in the directory).

Has anyone found a workaround that works in FF 72?

privacy.file_unique_origin=false

Nope, privacy.file_unique_origin=false doesn't help, even after a restart (in 72.0.1 from ubuntu).

So please file a new bug. It is very likely to have a different cause and commenting on closed bugs will not attract much attention.

Filed bug 1612453.

You need to log in before you can comment on or make changes to this bug.