file:// URLs cannot have popups unblocked except for specific single files
Categories
(Core :: Permission Manager, defect)
Tracking
()
People
(Reporter: akkzilla, Unassigned)
Details
Attachments
(1 file)
|
415 bytes,
text/html
|
Details |
This is a regression of bug 204285.
Create a test file that includes some javascript that does this:
window.open(window.location + '#popup', 'popupWin', 'width=300,height=300');
(I'll attach a working file). Name it /tmp/foo.html (or whatever you prefer). Now browse to file:///tmp/popup.html and observe the "Firefox prevented this site from opening a popup window" banner.
Open preferences, Privacy and Security, Block pop-up windows, exceptions. Add file:/// and try again. The popup is still blocked. Try adding file:///tmp/ -- same thing, popup still blocked. The only way to get popups is to add the specific file, file:///tmp/popup.html.
Bug 204285 covered the same issue, which was fixed for quite a while and only regressed relatively recently. When I raised this regression there, someone suggested setting privacy.file_unique_origin=false, but that didn't make any difference. I was told to file a new bug rather than reopening that one.
Comment 1•5 years ago
|
||
More fine-grained permissions seems like a feature? Would you like to run Mozregression to figure out when this regressed? Maybe that will give us more insight into whether the old behavior was actually intentional.
| Reporter | ||
Comment 2•5 years ago
|
||
I'm willing to (I guess I need to use the Python module, the program shown in the video seems to be a Windows binary), but I need to find a starting point since I don't have a good idea when it regressed, only that it used to work. Where can I download these nightly builds that mozregress uses, so I can download a few older builds and get a reasonable starting point for a bisection?
Comment 3•5 years ago
|
||
The priority flag is not set for this bug.
:johannh, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 4•5 years ago
|
||
(In reply to Akkana Peck from comment #2)
I'm willing to (I guess I need to use the Python module, the program shown in the video seems to be a Windows binary), but I need to find a starting point since I don't have a good idea when it regressed, only that it used to work. Where can I download these nightly builds that mozregress uses, so I can download a few older builds and get a reasonable starting point for a bisection?
Since it's binary search you can actually tell mozregression to start testing quite early and it won't have a big impact on your search time. Otherwise Firefox releases are here: https://ftp.mozilla.org/pub/firefox/releases/
Personally I would still consider this working as expected unless we know for sure that this was regressed.
| Reporter | ||
Comment 5•5 years ago
|
||
Argh. I can't seem to make it work now in older browsers, though I know I saw it work in the past.
In bug 204285, several people say they had it working in Firefox 50.1.0. The comments aren't super clear about how they enabled it, but it sounds like 50.1.0 allowed file:/// in the pop-up blocker preferences. However, that's not working for me.
In both that bug and bug 815640, lots of people say using <file> in the pop-up blocker preferences used to work; apparently bug 777072 broke that and then bug 815640 fixed it by adding it back. But I don't know what version of Firefox that fixed; presumably something older than 50.1.0 since it was 7 years ago. And now the regression mentioned in those bugs is back: adding <file> in all the versions I tested changes to http://<file> and there's no way to edit it back to just <file>, so even if the backend still honors that, the prefs UI won't allow it. (And I don't think the backend honors it anyway; I tried modifying permissions.sqlite to change the origin http://<file> to <file> and the popup was still blocked.)
Since I can't get either of these methods to work in the firefox versions where people in the bugs reported it working, I'm stymied. You can read those bugs to see lots of people besides me claiming it used to work. All I can guess is that there's some other setting that I no longer have set that interacts with the popup blocker preference to enable this.
Comment 6•5 years ago
|
||
Again, I don't understand why specifying fine-grained file paths is an issue for you.
| Reporter | ||
Comment 7•5 years ago
|
||
In my case, it's an issue because I tend to be working in a directory that may have 20-30 files in it, which all include the same .js file that pops up a separate window. Often I start at one file, but not always. And if I type the directory name into the urlbar, autocomplete may not show me the official starting-point file, but may show others in the same directory.
Comment 8•5 years ago
|
||
Marking this as WONTFIX. As an alternative suggestion, why don't you disable popup blocking while you're working on those local files?
Description
•