Open Bug 1657738 Opened 11 months ago Updated 11 days ago

window.open() calls create windows with read-only location/address bar in recent Firefox

Categories

(Core :: DOM: Core & HTML, defect, P2)

79 Branch
defect

Tracking

()

UNCONFIRMED

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

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();

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Widget: Win32
Product: Firefox → Core
Component: Widget: Win32 → DOM: Core & HTML

Presumably part of bug 1507375, which removed support for most? features.

Flags: needinfo?(arai.unmht)

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.

Flags: needinfo?(arai.unmht)

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

Flags: needinfo?(arai.unmht)
Regressed by: 1507375
Severity: -- → S3
Priority: -- → P2

(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=bf0e49a9ceffb337517dccdedf99c78c819de87a

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

Flags: needinfo?(arai.unmht)

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

Thanks for the explanation!

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

Flags: needinfo?(stephen.cunliffe)

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)

Flags: needinfo?(stephen.cunliffe)

Anne, do you know the reasoning behind making the popup's location bar read-only, or hidden?

Flags: needinfo?(annevk)

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.

Flags: needinfo?(annevk)

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.

Depends on: 1661657

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.

where would be the right place to talk about that?
should we move to the spec repository?

Flags: needinfo?(annevk)

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.

Flags: needinfo?(annevk)
Depends on: 1714939
You need to log in before you can comment on or make changes to this bug.