Closed
Bug 204285
Opened 21 years ago
Closed 11 years ago
file:// URLs cannot have popups unblocked
Categories
(Core :: Permission Manager, defect)
Core
Permission Manager
Tracking
()
RESOLVED
FIXED
mozilla21
People
(Reporter: paxunix, Assigned: mounir)
References
(Blocks 1 open bug)
Details
(Whiteboard: [workaround: comment 51/52])
Attachments
(4 files, 1 obsolete file)
59 bytes,
text/html
|
Details | |
957 bytes,
text/html
|
Details | |
4.54 KB,
patch
|
jaws
:
review-
|
Details | Diff | Splinter Review |
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.
Enable popup blocking, save this attachment to a local file and open it. Try to unblock the URL to see the issue.
Comment 2•21 years ago
|
||
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
Comment 3•21 years ago
|
||
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?
Updated•21 years ago
|
QA Contact: asa
*** Bug 220797 has been marked as a duplicate of this bug. ***
Comment 5•20 years ago
|
||
*** Bug 225759 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Severity: trivial → major
Comment 6•20 years ago
|
||
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•20 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
(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
Updated•17 years ago
|
Assignee: bross2 → nobody
QA Contact: general
Comment 10•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
This was fixed since a long time ago, but regressed again when bug 400097 was fixed.
Blocks: 400097
Comment 13•16 years ago
|
||
Updated•16 years ago
|
Flags: blocking-firefox3?
Comment 15•16 years ago
|
||
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•16 years ago
|
||
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-
Comment 17•16 years ago
|
||
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•16 years ago
|
||
(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.
![]() |
||
Updated•16 years ago
|
Version: unspecified → Trunk
Comment 20•16 years ago
|
||
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•16 years ago
|
||
Will this ever be resolved??? HHHHHHEEEEEEEELLLLLLLLLLLLLLLLPPPPPPPPPPPPPP!!!!!!!!!!!!
![]() |
||
Updated•16 years ago
|
Flags: blocking-firefox3.1?
Comment 24•16 years ago
|
||
Definitely not a blocker.
Flags: blocking-firefox3.1? → blocking-firefox3.1-
Comment 25•15 years ago
|
||
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•15 years ago
|
||
Correction for my workaround you don't need to set user_pref("security.fileuri.strict_origin_policy", false)
Comment 28•15 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
This basically copies the code from bug 546857.
Attachment #300930 -
Attachment is obsolete: true
Attachment #471509 -
Flags: review?(dwitte)
Attachment #300930 -
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
Comment 36•13 years ago
|
||
(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
Yes, similar to that.
Comment 38•13 years ago
|
||
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•13 years ago
|
||
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)
Blocks: 687581
No longer blocks: 687581
Comment 41•12 years ago
|
||
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•12 years ago
|
||
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?
Updated•12 years ago
|
Attachment #471509 -
Flags: review?(dwitte) → review-
Comment 46•12 years ago
|
||
Comment on attachment 471524 [details] [diff] [review] patch Clearing reviews on these patches based on comment #34.
Attachment #471524 -
Flags: review?(dwitte) → review-
Comment 48•12 years ago
|
||
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•12 years ago
|
||
This could be fixed by anybody, it's probably not that difficult. See comment 36 of how to fix this.
Comment 50•12 years ago
|
||
For me, that code in 36 might as well be Sanskrit. ROFL!!
Comment 51•12 years ago
|
||
If you want to turn off all "file://" popups, use "<file>" (sans quotes) in the popup blocker list.
Comment 52•12 years ago
|
||
Argh, I meant turn *on* popups, and popup *unblocker* list.
Comment 53•12 years ago
|
||
(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•12 years ago
|
||
Er I only got it from comment 31, but I'll take the praise :-)
Comment 55•12 years ago
|
||
We still have to adjust the frontend to me bore intuitive.
Comment 56•12 years ago
|
||
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•12 years ago
|
||
,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•12 years ago
|
||
(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•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
(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 | ||
Updated•11 years ago
|
Assignee: nobody → mounir
Severity: major → normal
Status: NEW → RESOLVED
Closed: 11 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
See Also: → https://launchpad.net/bugs/290867
Comment 64•7 years ago
|
||
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•7 years ago
|
||
"<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•7 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
privacy.file_unique_origin=false
Comment 69•4 years ago
|
||
Nope, privacy.file_unique_origin=false doesn't help, even after a restart (in 72.0.1 from ubuntu).
Comment 70•4 years ago
|
||
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•4 years ago
|
||
Filed bug 1612453.
You need to log in
before you can comment on or make changes to this bug.
Description
•