922956 - Tabs ready event not firing when calling window.open on Firefox 24

Status: RESOLVED FIXED

(Add-on SDK Graveyard :: General, defect, P2)

Description

[Francisco]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36

Steps to reproduce:

1. Create an add-on using SDK 1.14 containing the following Javascript:

var tabs = require("sdk/tabs");
tabs.on('ready', function(tab){console.log(tab.url)});

2. Start the add-on, load a page using the following code:

window.open(
    'http://mozilla.org', 
    '', 
    'width=800,height=600,scrollbars=yes,resizable=no,status=yes,location=yes'
    );


Actual results:

The tabs.ready event is not fired. 'http://mozilla.org' is not shown on the console.


Expected results:

The tabs.ready event should be fired. 'http://mozilla.org' should appear on the console.

Comment 1

[Francisco]

It happens starting on Firefox 24. On previous versions it behaved as expected.

Comment 2

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Jordan, can you take a look at this?

Comment 3

[Jordan Santell [:jsantell] [@jsantell]]

Francisco, I was checking out your question on SO too -- it was working for me, but I believe I had some different configuration. Now I am getting the same results.

When using window.open, it's opening a new window not necessarily a tab -- there is no tab to fire a ready event. Generally, this should be avoided (I was asked to allow popups when running this code as well), with more info on why below:

https://developer.mozilla.org/en-US/docs/Web/API/Window.open#Avoid_resorting_to_window.open.28.29

Comment 4

[Francisco]

Jordan,

I'm aware that window.open should be avoided but it is used on a page on which I have no control. My add-on doesn't (and shouldn't) modify how pages behave, so I can't change the button firing window.open by a button opening a new tab.

I should be able to get my add-on working independently on how the page has been loaded.

Comment 5

[Dave Townsend [:mossop]]

(In reply to Jordan Santell [:jsantell] [@jsantell] from comment #3)
> Francisco, I was checking out your question on SO too -- it was working for
> me, but I believe I had some different configuration. Now I am getting the
> same results.
> 
> When using window.open, it's opening a new window not necessarily a tab --
> there is no tab to fire a ready event.

There is no tab to listen to but there is the global tabs object which you could argue should be firing a ready event even for the first new tab in a window. What do you think?

Comment 6

[Jordan Santell [:jsantell] [@jsantell]]

Looking into it more, it seems that even making the toolbar accessible still doesn't allow the ready event to fire. And also, the windows' open event should also fire, and is failing to do so. Looks like an issue, regardless of whether `window.open` should be used or not in the DOM API.

Comment 7

[Jordan Santell [:jsantell] [@jsantell]]

Irakli, is this something that can be added on the platform side?

Comment 8

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Yes I plan on exposing `DOMContentLoaded` events for all documents via observer notifications (see Bug 843910). In this case we'll just need to hook into that and if document is one loaded in a tab we should
emit tab ready.

Comment 9

[Ben McCann]

Sounds like this has been confirmed and the status should be changed from UNCONFIRMED.

Comment 10

[Erik]

Lots of people commenting and CC'd on this bug, but haven't voted for it.  If the voting mechanism is used, it'd be good to allocate them on bugs that are blocking you like this one.

Comment 11

[Jordan Santell [:jsantell] [@jsantell]]

Unassigning myself from bugs I haven't gotten around to

Comment 12

[Nicolae Albu]

I am also facing this problem. Firefox 36.0.4, SDK 1.17.
The tab ready event fires for all except from window.open with the third parameter completed.
Anyone found workaround (for what do I have to listen) till the bug gets fixed?

Thanks.

Comment 13

[Jacobo Aragunde Pérez]

Attachment: pull request

The bug seems to be fixed, I'm adding a unit test to prevent regressions and close the bug for good.

Comment 14

[Nicolae Albu]

Is it also fixed for the test case I presented in my previous comment?

Comment 15

[Jacobo Aragunde Pérez]

(In reply to Nicolae Albu from comment #14)
> Is it also fixed for the test case I presented in my previous comment?


It seems so (tried FF nightly + SDK master). I've slightly modified the test to include a call to window.open with some parameters to have that case covered.

Comment 16

[Ben McCann]

I just tested as well. It's broken on Firefox 39.0, but is working on Firefox 40.0b6. Yay!

It'll be nice to get the PR with the test for this in to ensure we don't regress. https://github.com/mozilla/addon-sdk/pull/2020

Comment 17

[[github robot]]

Commits pushed to master at https://github.com/mozilla/addon-sdk

https://github.com/mozilla/addon-sdk/commit/63b6683767efd7005e0c87b7ef501117d7084179
Bug 922956 - Add unit test to prevent regressions

https://github.com/mozilla/addon-sdk/commit/b802a9a46fd7ff87aa0b0161c21d67b589ae0461
Merge pull request #2020 from jaragunde/922956

Bug 922956: Add unit test to prevent regressions. r=Mossop

Comment 18

[Ben McCann]

Awesome! Thanks Jacobo for the fix and Mossop for the review!

Can someone mark this as fixed now? Thanks!