Closed Bug 1422033 Opened 5 years ago Closed 5 years ago

window.open throws NS_ERROR_FAILURE when opener has no features and no other window with features is opened

Categories

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

57 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla59
Tracking Status
firefox59 --- fixed

People

(Reporter: abahcecioglu, Assigned: nika)

Details

Attachments

(2 files)

Attached file pages.zip
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Steps to reproduce:

I've got 3 pages. In the first page there is a Button to open the second page with the following javascript command:

window.open("./page2.html", "page2", "menubar=no, status=no, toolbar=no, location=no, resizable=yes");

So in the second page there are 3 buttons. The first button listens to the following click callback:

window.open("./page3.html", "page3", "menubar=no, status=no, toolbar=no, location=no, resizable=yes");

The second button listens to:

window.open("./page3.html", "page3", "menubar=yes, status=yes, toolbar=yes, location=yes, resizable=yes");

And the third button listens to:

window.open("./page3.html", "page3", "");


Actual results:

All 3 window.open calls works fine until the window with page1 is still open.

The third butten opens the new window as a new tab in the same browser window where page1 is opened. 

If i click the third button, while there is no other browser window opened with the toolbar aktive, the window.open function throws a NS_ERROR_FAILURE.


Expected results:

The window.open call with an empty string as feature parameter should open a new browser window without throwing a NS_ERROR_FAILURE.
Component: Untriaged → DOM
Product: Firefox → Core
Nika has done some docshell work so may have an idea if we're spec-compliant here.
Flags: needinfo?(nika)
Priority: -- → P2
Maybe this is e10s-related, too, like bug 1422603 is?
This is technically spec compliant, because there's a nice "catch-all" case in the spec saying that a user agent can always refuse to open a window ^.^ (https://html.spec.whatwg.org/#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name)

    If the user agent has been configured such that in this instance it will not find a browsing context
        Do nothing.

That being said, this isn't great behaviour. We should do better. I've got some idea of why this doesn't work. I'll look into fixing it.
Assignee: nobody → nika
Flags: needinfo?(nika)
Chrome's behaviour here is to open a new normal browsing window, and open the new tab in that window, which I think we should copy.
This patch unfortunately doesn't come with a test yet, because it's not possible to close the window which you start with in a mochitest-browser without breaking the test harness.

I could probably do it with a Marionette test. Let me know if that would be a good idea.

MozReview-Commit-ID: DzSllBVdUhq
Attachment #8934697 - Flags: review?(bzbarsky)
Comment on attachment 8934697 [details] [diff] [review]
Support opening a new window when no windows are avaliable for a new tab

r=me, but what about the non-e10s codepath?  Or does that already have this behavior?
Flags: needinfo?(nika)
Attachment #8934697 - Flags: review?(bzbarsky) → review+
(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #6)
> r=me, but what about the non-e10s codepath?  Or does that already have this
> behavior?

Yes, in my test the non-e10s codepath already handled this correctly.
Flags: needinfo?(nika)
Pushed by nika@thelayzells.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a65ee5a914a9
Support opening a new window when no windows are avaliable for a new tab, r=bz
https://hg.mozilla.org/mozilla-central/rev/a65ee5a914a9
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.