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
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.
(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?
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
Irakli, is this something that can be added on the platform side?
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.
Sounds like this has been confirmed and the status should be changed from UNCONFIRMED.
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
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.
Is it also fixed for the test case I presented in my previous comment?
(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.
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
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
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.