Popup blocker does not handle urls within urls correctly
Categories
(Firefox :: Site Permissions, defect)
Tracking
()
People
(Reporter: uiy12345, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0
Steps to reproduce:
Example:
https://web.archive.org/save/https://www.somesite.com
Will fail because firefox will detect it as a popup when run from a script and opened in a new tab from the script. It says that somesite.com is a popup and blocks it. I can whitelist somesite.com but it does no good.
I do not remember having this problem until I updated firefox developer a few weeks ago and it doesn't seem to always occur.
window.open("https://web.archive.org/save/https://www.somesite.com");
will be blocked(at some point(may have to open several tabs using it or other sites)). archive.org and somesite.com are whitelisted(although only archive.org should be as the inside url has nothing to do with popup blocking).
This seems like a bug in how the url is parsed for pop-up blocking.
Actual results:
New tab link opened from a script in another tab is blocked.
Expected results:
It should not be blocked. The actual website is whitelisted(in fact, they all are).
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•3 years ago
|
||
I think the popup blocker is more of a Firefox:: thing but I guess this could be a DOM issue somehow.
|
||
Comment 3•3 years ago
|
||
Hi uiy12345, does this issue still occur on your end ? I tried to reproduce it in all versions of Firefox including Developer edition but Clicking the URL from the page will always open the website in a new tab, it will never get blocked.
I also tried to create an HTML test case for it using the window.open() function:
<button onclick="myfun()">click me to open new window</button>
<script type="text/javascript">
function myfun() {
window.open("https://web.archive.org/save/https://www.somesite.com");
}
But even so it wont get blocked, do you have a reduced test case or maybe a different website where Clicking on a URL will block the page in a new tab ?
(In reply to Rares Doghi from comment #3)
Hi uiy12345, does this issue still occur on your end ? I tried to reproduce it in all versions of Firefox including Developer edition but Clicking the URL from the page will always open the website in a new tab, it will never get blocked.
I also tried to create an HTML test case for it using the window.open() function:
<button onclick="myfun()">click me to open new window</button>
<script type="text/javascript">
function myfun() {
window.open("https://web.archive.org/save/https://www.somesite.com");
}But even so it wont get blocked, do you have a reduced test case or maybe a different website where Clicking on a URL will block the page in a new tab ?
It hasn't happened lately and it doesn't always happen. All I know is that I had no issues with the code and never modified it(as it was functioning as desired) then I started getting the error about popups and it clearly was trying to block the latter part of the url and seemed like it was a parsing error on firefox's end. I had the error a few intermittent times but too sparse to make heads or tails of what could be causing it.
There is clearly some bug in firefox's code but no way for me to pin it down. It could possibly be a buffer overrun type of issue as it might occur if I leave the browser running for a very long time(weeks).
Probably the only way to figure it out would be to check any popup block url to see if it has two https strings inside it and then log it. It seems like it's a pretty obvious bug of where it is treating the 2nd https url as the url. E.g., url.split("https")[-1] which would result in such errors. Of course one would expect this to then occur every time but it doesn't so I have no idea.
|
||
Comment 5•3 years ago
|
||
We don't handle raw URLs like that but store and check permissions using principals, which makes it very unlikely for this code to fail in the way you described.
I wasn't able to reproduce the STR in Firefox Nightly with the following test page: https://output.jsbin.com/novevoxere
Closing this bug as WORKSFORME for now. Happy to take another look if you can provide more concrete steps to reproduce, perhaps with a test page.
Description
•