Bug 1095236 - [e10s] window.open(..., ..., "dialog=1") breaks with e10s enabled

So here’s what a debug build spews out when I try the test case :

The test case is just a link that runs this script:

function windowopen(){

window.open('http://www.example.com', 'test', 'dialog=yes');

}

[Child 15455] ###!!! ASSERTION: attempted to open a new window with no WindowCreator: 'mWindowCreator', file /Users/mikeconley/Projects/mozilla-central/embedding/components/windowwatcher/nsWindowWatcher.cpp, line 731

[Child 15455] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file /Users/mikeconley/Projects/mozilla-central/dom/base/nsGlobalWindow.cpp, line 12275

Ugh, so here’s the relevant piece of OpenWindowInternal:

// Now check whether it's ok to ask a window provider for a window.  Don't
// do it if we're opening a dialog or if our parent is a chrome window or
// if we're opening something that has modal, dialog, or chrome flags set.
nsCOMPtr < nsIDOMChromeWindow > chromeWin = do_QueryInterface(aParent);
if ( ! aDialog && ! chromeWin &&
! (chromeFlags & (nsIWebBrowserChrome :: CHROME_MODAL |
nsIWebBrowserChrome :: CHROME_OPENAS_DIALOG |
nsIWebBrowserChrome :: CHROME_OPENAS_CHROME))) {
nsCOMPtr < nsIWindowProvider > provider = do_GetInterface(parentTreeOwner);
if (provider) {
NS_ASSERTION(aParent, "We've _got_ to have a parent here!" );

nsCOMPtr < nsIDOMWindow > newWindow;
rv = provider -> ProvideWindow(aParent, chromeFlags, aCalledFromJS,
sizeSpec.PositionSpecified(),
sizeSpec.SizeSpecified(),
uriToLoad, name, features, & windowIsNew,
getter_AddRefs(newWindow));

if (NS_SUCCEEDED(rv)) {
GetWindowTreeItem(newWindow, getter_AddRefs(newDocShellItem));
if (windowIsNew && newDocShellItem) {
// Make sure to stop any loads happening in this window that the
// window provider might have started.  Otherwise if our caller
// manipulates the window it just opened and then the load
// completes their stuff will get blown away.
nsCOMPtr < nsIWebNavigation > webNav =
do_QueryInterface(newDocShellItem);
webNav -> Stop(nsIWebNavigation :: STOP_NETWORK);
}
} else if (rv == NS_ERROR_ABORT) {
// NS_ERROR_ABORT means the window provider has flat-out rejected
// the open-window call and we should bail.  Don't return an error
// here, because our caller may propagate that error, which might
// cause e.g. window.open to throw!  Just return null for our out
// param.
return NS_OK;
}
}
}

}

Hrm. So we special-case DIALOG’s, and then try to open them with a window creator. Great.

Is there a good reason why web content can open up dialogs? According to https://developer.mozilla.org/en-US/docs/Web/API/Window/open?redirectlocale=en-US&redirectslug=DOM%2Fwindow.open , Gecko is the only engine that obeys that directive.

5:40 PM < overholt > :) I would say yes

Send out Intent to Unship

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

One of the arguments to window.open 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, 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

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

-Mike