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

RESOLVED FIXED

Status

Add-on SDK
General
P2
normal
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: Francisco, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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.
(Reporter)

Comment 1

5 years ago
It happens starting on Firefox 24. On previous versions it behaved as expected.
Jordan, can you take a look at this?
Assignee: nobody → 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
Flags: needinfo?(fexposito)
(Reporter)

Comment 4

5 years ago
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.
Flags: needinfo?(fexposito)
(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?
Flags: needinfo?(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.
Depends on: 854982
Flags: needinfo?(jsantell)
Priority: -- → P2
Irakli, is this something that can be added on the platform side?
Flags: needinfo?(rFobic)
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.
Flags: needinfo?(rFobic)

Comment 9

4 years ago
Sounds like this has been confirmed and the status should be changed from UNCONFIRMED.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 10

4 years ago
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.
Unassigning myself from bugs I haven't gotten around to
Assignee: jsantell → nobody

Comment 12

3 years ago
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.
Created attachment 8630480 [details] [review]
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

3 years ago
Is it also fixed for the test case I presented in my previous comment?
Flags: needinfo?(jaragunde)
(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.
Flags: needinfo?(jaragunde)

Comment 16

3 years ago
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

3 years ago
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

3 years ago
Awesome! Thanks Jacobo for the fix and Mossop for the review!

Can someone mark this as fixed now? Thanks!
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.