204285 - file:// URLs cannot have popups unblocked

Status: RESOLVED FIXED

(Core :: Permission Manager, defect)

Description

[paxunix]

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.

Comment 1

[paxunix]

Attachment: 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.

Comment 2

[David P James]

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.

Comment 3

[John H Miller]

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?

Comment 4

[Ruy Exel]

*** Bug 220797 has been marked as a duplicate of this bug. ***

Comment 5

[Oleg Sidletskiy]

*** Bug 225759 has been marked as a duplicate of this bug. ***

Comment 6

[Kevin Ar18]

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.

Comment 7

[Brian Scott]

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.

Comment 8

[Jason Barnabe (np)]

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?

Comment 9

[Cédric Chantepie]

(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

Comment 10

[Sylvain Pasche]

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.

Comment 11

[Matt Sommer]

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!

Comment 12

[Martijn Wargers (dead)]

This was fixed since a long time ago, but regressed again when bug 400097 was fixed.

Comment 13

[Martijn Wargers (dead)]

Attachment: permission manager testcase, uses enhanced privileges

Comment 14

[Martijn Wargers (dead)]

Attachment: patch?

This fixes it for me.

Comment 15

[[e-mail]]

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?

Comment 16

[Mike Connor [:mconnor]]

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

option 3 seems to make the most sense to me.

Comment 17

[Martijn Wargers (dead)]

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.

Comment 18

[Martijn Wargers (dead)]

(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.

Comment 20

[BlueSansDouze]

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.

Comment 22

[Steve A.]

Will this ever be resolved???

HHHHHHEEEEEEEELLLLLLLLLLLLLLLLPPPPPPPPPPPPPP!!!!!!!!!!!!

Comment 24

[Mike Connor [:mconnor]]

Definitely not a blocker.

Comment 25

[John Middlemas]

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.

Comment 26

[John Middlemas]

Correction for my workaround you don't need to set user_pref("security.fileuri.strict_origin_policy", false)

Comment 28

[Nochum Sossonko [:Natch]]

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...

Comment 29

[Steve A.]

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!!!!!!!!!!!!!

Comment 30

[Martin Barry]

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.

Comment 31

[Martijn Wargers (dead)]

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.

Comment 32

[Martijn Wargers (dead)]

Attachment: patch?

This basically copies the code from bug 546857.

Comment 33

[Martijn Wargers (dead)]

Attachment: patch

This fixes the ui a bit.

Comment 34

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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?

Comment 35

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

Comment 36

[Martijn Wargers (dead)]

(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

Comment 37

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yes, similar to that.

Comment 38

[Gingerbread Man]

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.

Comment 40

[Keul]

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)

Comment 41

[J.F. Kelley]

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).

Comment 43

[Eric Sh.]

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?

Comment 46

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 471524 [details] [diff] [review]
patch

Clearing reviews on these patches based on comment #34.

Comment 48

[Steve A.]

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!!

Comment 49

[Martijn Wargers (dead)]

This could be fixed by anybody, it's probably not that difficult. See comment 36 of how to fix this.

Comment 50

[Steve A.]

For me, that code in 36 might as well be Sanskrit.  ROFL!!

Comment 51

[Saurabh]

If you want to turn off all "file://" popups, use "<file>" (sans quotes) in the popup blocker list.

Comment 52

[Saurabh]

Argh, I meant turn *on* popups, and popup *unblocker* list.

Comment 53

[Steve A.]

(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!!!!!

Comment 54

[Saurabh]

Er I only got it from comment 31, but I'll take the praise :-)

Comment 55

[Keul]

We still have to adjust the frontend to me bore intuitive.

Comment 56

[Steve A.]

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

Comment 57

[Philip Karras]

,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

Comment 58

[Steve A.]

(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.

Comment 59

[Philip Karras]

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.

Comment 60

[yee-haw]

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).

Comment 61

[Thomas D. (:thomas8)]

(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.

Comment 64

[Matthias]

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.

Comment 65

[Masatoshi Kimura [:emk]]

"<file>" stuff has been removed far back because you should be able to unblock file:/// urls normally since Firefox 21. See bug 815640.

Comment 66

[Matthias]

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.

Comment 67

[Akkana Peck]

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?

Comment 68

[Masatoshi Kimura [:emk]]

privacy.file_unique_origin=false

Comment 69

[Akkana Peck]

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

Comment 70

[Masatoshi Kimura [:emk]]

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.

Comment 71

[Akkana Peck]

Filed bug 1612453.