1507375 - Can we drop window.open's feature parameter which controls UI parts visibility?

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, task, P3)

Description

[Tooru Fujisawa [:arai]]

Separated from bug 1506655.

window.open's feature parameters which controls UI parts (tabbar, menubar, toolbar, personalbar) is supported only in Firefox and IE [1],
and it causes confusing behavior around UI to control visibility of those parts (bug 1506655), and also causes trouble around sessionrestore (the same bug, bug 1506655)

Given the feature is not supported on other modern browsers, can we drop it?

The other browser's behavior is following:
  * Edge
    * opens a window which has only location bar
    * hitting Ctrl+T does nothing
  * Chrome
    * opens a window which has only location bar
    * hitting Cmd+T opens new tab in other window
  * Safari
    * opens a window which behaves samely as normal window
      (has all UI parts)
    * hitting Cmd+T opens new tab in that window

more behavior related to session store is described in bug 1506655 comment #7.

Then, I think Chrome's behavior is same as Firefox when the feature is only "locationbar".
So I think dropping support for them and open a window only with location bar regardless of those features is the simplest solution.

[1] https://developer.mozilla.org/ja/docs/Web/API/window.open#Window_features

Comment 1

[Tooru Fujisawa [:arai]]

bz, can I have your opinion again?
I think this at least won't cause much web-compat issue.

Comment 2

[Boris Zbarsky [:bzbarsky]]

I'm not quite following the proposal.  What is the actual proposed behavior when the page asks for, say, "locationbar,toolbar,menubar"?  What is the proposed behavior when the page asks for "locationbar,toolbar,menubar,tabbar,personalbar"?  What about other feature combinations?

Comment 3

[Tooru Fujisawa [:arai]]

okay, let me check more about the combinations, and write down the proposal.
hopefully in this weekend

Comment 4

[Dão Gottwald [:dao]]

(In reply to Tooru Fujisawa [:arai] from comment #0)
> Separated from bug 1506655.
> 
> window.open's feature parameters which controls UI parts (tabbar, menubar,
> toolbar, personalbar) is supported only in Firefox and IE [1],

Do we actually support all of these? I thought we only supported the toolbar feature. More precisely, toolbar=no, as toolbar=yes would be the default...

> Given the feature is not supported on other modern browsers, can we drop it?
> 
> The other browser's behavior is following:
>   * Edge
>     * opens a window which has only location bar
>     * hitting Ctrl+T does nothing
>   * Chrome
>     * opens a window which has only location bar
>     * hitting Cmd+T opens new tab in other window

I'm not sure I'm following. It sounds like Chrome presents popups just like we do, and Edge too except for refusing to open a tab.

Could it be that https://developer.mozilla.org/en-US/docs/Web/API/Window/open is just outdated? It lists Netscape 6, Netscape 7, and Mozilla 1.0 which I don't think any web developer cares about today...

Comment 5

[Tooru Fujisawa [:arai]]

(In reply to Dão Gottwald [::dao] from comment #4)
> (In reply to Tooru Fujisawa [:arai] from comment #0)
> > Separated from bug 1506655.
> > 
> > window.open's feature parameters which controls UI parts (tabbar, menubar,
> > toolbar, personalbar) is supported only in Firefox and IE [1],
> 
> Do we actually support all of these? I thought we only supported the toolbar
> feature. More precisely, toolbar=no, as toolbar=yes would be the default...

yes, window.open can control the visibility of tabbar, toolbar (backward button etc), bookmark toolbar,
in the opened window, and it's saved and restored across restart.

Comment 6

[Tooru Fujisawa [:arai]]

Attachment: testcase for combination

Comment 7

[Tooru Fujisawa [:arai]]

Attachment: Chrome, Safari, and Edge's behavior

so far, here's the behavior of Chrome, Safari, and Edge.
based on observation, I might overlook some other conditions.

features parameter can control what to open (popup, window, tab), but the visibility of UI parts are not controllable (visible UI parts are fixed for each case)

I'll prepare proposal for Firefox.

Comment 8

[Tooru Fujisawa [:arai]]

Comment on attachment 9027089 [details]
Chrome, Safari, and Edge's behavior

After some more tests, it turns out the behavior is a bit more complicated.
here's the latest document:
  https://arai-a.github.io/window-open-features/

and testcase:
  https://arai-a.github.io/window-open-features/test.html

Comment 9

[Tooru Fujisawa [:arai]]

Updated https://arai-a.github.io/window-open-features/
Also added https://arai-a.github.io/window-open-features/firefox.html for Firefox's behavior and prefs

Comment 10

[Tooru Fujisawa [:arai]]

Tested on Edge Canary, and it seems to be the same behavior as Chrome.

Comment 11

[Tooru Fujisawa [:arai]]

might also have to think about BarProp.visible.
https://html.spec.whatwg.org/multipage/window-object.html#browser-interface-elements

Chrome seems to return false for the case that the bar is visible but features specifies the bar to be hidden.

Comment 12

[Tooru Fujisawa [:arai]]

There are some amount of code that checks if size or position is specified, and this affects where the page is loaded (new window or not)
https://searchfox.org/mozilla-central/search?q=aPositionSpecified&path=

I'm not sure modifying this here is reasonable.

If not modify, the condition for whether to open popup or not depends on whether size or position is specified,
in contrast to, chrome that doesn't check size/position, and Safari that checks only width.

Comment 13

[Tooru Fujisawa [:arai]]

dom.disable_window_open_feature.* prefs doesn't work well with the idea.

those prefs control the effect of each feature separately, but the idea here just uses the set of features to whether to open popup or not,
so there's no controllability for each UI items.
I wonder if we can just remove the pref.

Comment 14

[Tooru Fujisawa [:arai]]

IIUC, the pref is used both for web content and privileged code.

https://searchfox.org/mozilla-central/rev/c52d5f8025b5c9b2b4487159419ac9012762c40c/toolkit/components/windowwatcher/nsWindowWatcher.cpp#1662-1709

https://searchfox.org/mozilla-central/rev/c52d5f8025b5c9b2b4487159419ac9012762c40c/toolkit/components/windowwatcher/nsWindowWatcher.cpp#1802-1805

https://searchfox.org/mozilla-central/rev/c52d5f8025b5c9b2b4487159419ac9012762c40c/toolkit/components/windowwatcher/nsWindowWatcher.cpp#1750-1751

if that's correct, I wonder if controlling the feature for priv code makes sense... (or, even, if it's used?)

Comment 15

[Tooru Fujisawa [:arai]]

Also, to align with other browsers, the effect of scrollbars should also be removed (except for the condition as whether to open popup or not).
(failing test: https://searchfox.org/mozilla-central/source/dom/html/test/test_bug369370.html )

Comment 16

[Tooru Fujisawa [:arai]]

about BarProp, the failing test is https://searchfox.org/mozilla-central/source/dom/tests/mochitest/bugs/test_window_bar.html

Comment 17

[Tooru Fujisawa [:arai]]

try run for WIP patch
https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&revision=c3c1fb1a7123019f0227a14bed420966288afcb8

Comment 18

[Tooru Fujisawa [:arai]]

might also have to think about BarProp.visible.
https://html.spec.whatwg.org/multipage/window-object.html#browser-interface-elements

Chrome seems to return false for the case that the bar is visible but features specifies the bar to be hidden.

IMO it doesn't make much sense to follow Chrome's behavior, because of session restore.
If we don't restore the feature parameter across restart, the property will return different value after the restart,
and if we restore feature parameter, that will cause similar confusion as current behavior.

Comment 19

[Tooru Fujisawa [:arai]]

new try run https://treeherder.mozilla.org/#/jobs?repo=try&revision=98644431f44af769470bd371b67ecda6732980ee
with:

• removed dom.disable_window_open_feature.* prefs
• updated BarProp tests
• updated to follow the latest proposed behavior https://arai-a.github.io/window-open-features/

Comment 20

[Tooru Fujisawa [:arai]]

Attachment: Bug 1507375 - Restrict the controllability of UI parts visibility with features parameter of window.open. r?smaug!

Make the features parameter of window.open just a condition for whether to open
a popup or a new tab.
Also remove dom.disable_window_open_feature.* prefs.

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6fe5ce050c0d
Restrict the controllability of UI parts visibility with features parameter of window.open. r=smaug

Comment 23

[Noemi Erli[:noemi_erli]]

Backed out changeset 6fe5ce050c0d (Bug 1507375) for failures in test_transformed_scrolling_repaints_3.html CLOSED TREE

Push with failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedJob=293811428&resultStatus=testfailed%2Cbusted%2Cexception&revision=6fe5ce050c0dfcbfaf64ce7f4770cfaa2c2a6cad

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=293811540&repo=autoland&lineNumber=21557

Backout: https://hg.mozilla.org/integration/autoland/rev/5cd032a8ac6c7cdd7fd8a4b371db27bb09a6f321

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bf0e49a9ceff
Restrict the controllability of UI parts visibility with features parameter of window.open. r=smaug

Comment 25

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/bf0e49a9ceff

Comment 26

[Tooru Fujisawa [:arai]]

So far updated the following page to make it up to date, with some note about UI-parts visibility related items
https://wiki.developer.mozilla.org/en-US/docs/Web/API/Window/open

but I haven't described the details of the conditions for whether popup or not, given it's very implementation-dependent.
I guess we can add that section once the condition gets standardized, but I'd leave it to other bug.

also updated
https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/76

Comment 32

[Kohei Yoshino [:kohei]]

Posted site compatibility note.

Comment 33

[Synetech]

So in other words, Firefox will no longer be a viable browser for web-apps because it won't be possible to run them with minimal chrome? 🤨

You do realize that web-apps are the future and if people can't run them in Firefox because there's no way to run them without their windows being forced to have a bunch of browser cruft that eats up valuable screen real-estate, then they'll just use a different browser that lets them do it correctly right? (And don't say that other current browsers don't, because that just means someone will make another browser that does, like how Brave came along to provide privacy.)

Short-sighted decisions like this are why Firefox is losing ground to Edge of all things instead of gaining ground from Chrome. ¬_¬

The solution isn't to remove the ability to control chrome altogether, it's to provide better control so that it can be done properly and safely, like using permissions and whitelisting sites so that people can keep open a low-profile window on video sites, communication sites, stock sites, and so on. Removing it altogether is like saying that someone could hack the camera so you're just going to block all access to the camera. 🤦

Comment 34

[Synetech]

You guys are destroying Firefox. How does removing user control improve the browser? 🤨 Why can't you just satisfy your concerns about security by simply setting safe defaults then letting users CHOOSE to allow stuff that MIGHT cause a problem? By your logic, you may as well just remove the ability to let users grant sites permission to access the camera because it could be misused. Why not just remove the window.open() function altogether? You've already gutted it and ruined the benefits it could provide by creating minimal-chrome web-apps. 🤦

You're copying the worst aspects of the Chrome devs. Their haughty narrow-minded attitude of doing whatever they want and ignoring users is what led me to stop contributing to Chromium and drop it altogether and switch to Firefox after nearly a decade. Unfortunately, you're doing the same to Firefox, but this time, there's nothing left to switch to.

What a shame; Firefox was doing so well for a while there too. 😒