window.open() calls create windows with read-only location/address bar in recent Firefox
Categories
(Core :: DOM: Core & HTML, defect, P2)
Tracking
()
People
(Reporter: stephen.cunliffe, Unassigned)
References
(Depends on 2 open bugs, Regression, )
Details
(Keywords: regression)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0
Steps to reproduce:
Something changed in a recent Firefox version where popup windows opened via window.open() calls render with read-only location/address bars, regardless what window features are specified:
Test code, Paste in the console of any Firefox window:
function testPopup(){
var url = "https://www.google.com/";
window.open(url, '_blank', 'height=800,bookmarks=1,left=0,directories=1,location=1,menubar=1,personalbar=1,resizable=1,scrollbars=1,status=1,titlebar=1,toolbar=1,top=0,width=1000');
}
testPopup();
Actual results:
popup opened, but the location/address bar is read-only (user can not modify/edit it)
Expected results:
location/address bar should always be editable
Reporter | ||
Comment 1•4 years ago
|
||
Note, for the simplest test case, just set either a width or height parameter to ensure window opens as a popup vs a new tab.
e.g.
function testPopup(){
var url = "https://www.google.com/";
window.open(url, '_blank', 'width=1000');
}
testPopup();
Comment 2•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Updated•4 years ago
|
Comment 3•4 years ago
|
||
Presumably part of bug 1507375, which removed support for most? features.
Updated•4 years ago
|
Comment 4•4 years ago
|
||
Most UI-visibility related features are now just conditions for whether to open a popup or not (a new window, a new tab, or current tab, depending on user's configuration).
Here's the details: https://arai-a.github.io/window-open-features/
Then, for popup case, the behavior haven't been changed.
Location bar has been read-only before bug 1507375 change.
Comment 5•4 years ago
|
||
(In reply to Tooru Fujisawa [:arai] from comment #4)
Location bar has been read-only before bug 1507375 change.
But the regression window I got is
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1ea98ae8b0676bb766da1c1e1b2256f26fdbdbd0&tochange=bf0e49a9ceffb337517dccdedf99c78c819de87a
arai, could you take a look? Thanks.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 6•4 years ago
|
||
(In reply to Edgar Chen [:edgar] from comment #5)
(In reply to Tooru Fujisawa [:arai] from comment #4)
Location bar has been read-only before bug 1507375 change.
But the regression window I got is
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1ea98ae8b0676bb766da1c1e1b2256f26fdbdbd0&tochange=bf0e49a9ceffb337517dccdedf99c78c819de87aarai, could you take a look? Thanks.
Yes, the behavior for the original testcase in comment #0 has been changed, because of bug 1507375 change.
It has been opening a new window, but now it opens a popup (because it specifies "width" feature).
Then, if a website opens a popup, location bar is read-only.
This matches to other browsers (chrome and chromium edge are both read-only. Safari doesn't show location bar)
With the simplified testcase in comment #1, it has been opening a popup, before bug 1507375 change,
and the location bar has been read-only.
Comment 7•4 years ago
|
||
to be clear, after bug 1507375 change, a website cannot open a new non-popup window,
unless the user explicitly specifies by browser.link.open_newwindow
pref [1].
Now, if the feature string matches to the condition to open a popup, it opens a popup,
and if the feature string doesn't match to the condition, it opens a new tab by default.
and the latter behavior depends on the user's preference.
[1] https://arai-a.github.io/window-open-features/#IsNewWindow-Firefox
Comment 8•4 years ago
|
||
Thanks for the explanation!
Updated•4 years ago
|
Comment 9•4 years ago
|
||
Hi,
I was able to reproduce onwindows 10 pro, nigthly 82.0a1 (2020-08-25) (64-bit) but as per comment 6, and comment 7, is it ok then to close this issue?
I'll await confirmation.
Thanks!
Best regards,
Clara
Reporter | ||
Comment 10•4 years ago
|
||
While noted in comment 6: "This matches to other browsers (chrome and chromium edge are both read-only. Safari doesn't show location bar)" I don't think that this action is good either... and I would argue that that behavior is ALSO buggy.
I don't see any valid scenario where making the UI controls for a window to the end user to be "read-only" is helpful in a usability regard. What benefit does it server to stop the user from being able to edit/inspect/select/modify the URL? what if the window was opened (e.g. the "see our other store locations") as a popup from my big box store (wallmart, home depot, costco, whatever)... as a user am I not allowed to then decide what I want to do with that window?... what if I want to navigate away to another domain? e.g. I want to go to "https://maps.google.com/" so that I can get the full interactive experience and map directions from my location to a store/whatever.
The only thing that is different about a popup window is that it opens in a smaller window than a fullscreen tab... and when used in many webapps, there are browser chrome features that may not be desired/needed that can be requested to be removed for visual clarity (e.g. the bookmarks bar is likely not required)... or the scrollbars may want to be controlled if the UI presented creates a "dialog" affect with a fixed header/footer and a scrollable "body" section (if the content overflows)
Comment 11•4 years ago
|
||
Anne, do you know the reasoning behind making the popup's location bar read-only, or hidden?
Comment 12•4 years ago
|
||
Well, originally the intent behind the various APIs to manage windows was very much about emulating the X Window System as far as I can tell. That was not a great idea and we have been paying for it ever since.
Now that we have removed UI control over that window (other than sizing and positioning), it does not seem problematic to let users use it for other purposes. I.e., the address bar should probably be read-write. I wonder though if we should consider taking it even further: make a popup a sized and positioned otherwise-normal window with a tab in it so users can drag it back into their main window if they want as well.
Looking at https://arai-a.github.io/window-open-features/#IsPopup (great resource!), I wonder why we went with a new behavior and did not stick with either Chrome or Safari? I rather like Safari's behavior of only considering something a popup if you specified width
. That would also simplify the processing model a lot as we would not have to process the other features I think.
Hope this helps.
Comment 13•4 years ago
|
||
Thank you.
I'll look into making it read-write.
Then, If we go with changing the popup to normal window, it might be better looking into standardizing the window.open behavior before changing the implementation.
To my understanding, one benefit of using minimal popup is to maximize the content area in small screen size.
and unconditionally making it normal window might break some website.
I wonder if we can make it switchable between minimal popup and normal window, from toolbar or something also available in minimal popup.
then, about IsPopup condition, it was a mix of the other browsers and previous behavior.
we can change it if necessary, but I think this should also be done after looking into standardization.
Comment 14•4 years ago
|
||
One concern that was raised out-of-band is that enterprise might rely on it being readonly and cares about the distinction with normal tabs/windows. So I would suggest we first talk with other browsers to see if they are prepared to collectively make changes here.
Comment 15•4 years ago
|
||
where would be the right place to talk about that?
should we move to the spec repository?
Comment 16•4 years ago
|
||
Sorry, yeah, whatwg/html. Might as well open a fresh issue there as the older issue has a lot of discussion that's no longer relevant.
Comment 17•4 years ago
|
||
Comment 18•3 years ago
|
||
bug 1714939 is going to add an option to use regular window/tab instead of minimal popup, that will solve this bug partially, that the issue is specific only to minimal popup.
we can revisit read-only part after that.
Description
•