Intent to unship: dialog=1 for window.open from web content

[Mike Conley]

One of the arguments to window.open[1] is a “feature string” that is
used to do things like set the size of the newly opened window, to set
whether or not it is resizable, etc.

Gecko currently supports a “dialog” feature that is really only evident
on Windows platforms. This dialog feature essentially hides the
minimize, maximize and restore buttons in the window titlebar. It also
hides the “command” icon (that’s the program icon usually visible in the
top-left corner of a popup window on Windows). Note that it doesn’t
disable the minimizing / maximizing capabilities of the window, it just
hides the buttons. Right-clicking on the titlebar brings up a popup that
allows the user to control the window.

>From what I can tell, this is a super old feature, and Gecko is the only
web engine to support it. All other engines just ignore that setting.

Bug 1095236 was filed because when an e10s-enabled Gecko encounters a
window.open with “dialog=1” or “dialog=yes” in the feature string, it
failed to open the window. I didn’t find enough cause for Gecko to keep
supporting the feature when I posted to dev-platform earlier in the
week[2], so I have prepared patches that cause Gecko to ignore the
feature as well for both e10s and non-e10s. This will allow this
window.open calls to work with e10s-enabled Gecko again.

Note that this does not disable the dialog=1 feature when window.open is
called from privileged code from the parent process.

Patches are available in the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1095236

fxcompat has already put up a post:
https://www.fxsitecompat.com/en-US/docs/2015/dialog-option-for-window-open-is-no-longer-supported/

I’ll be landing these patches early next week in mozilla-central unless
I hear a really compelling argument not to.

-Mike

References:

[1]: https://developer.mozilla.org/en-US/docs/Web/API/Window/open
[2]:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/cDpULPod8nQ