925950 - Regression (23 → 24): _blank links prevent Widget showing in add-on bar and toolbarbutton buttons from showing in toolbar

Status: RESOLVED WONTFIX

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

Description

[Jamie Phelps]

Attachment: target-_blank-bug-demo.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9) AppleWebKit/537.71 (KHTML, like Gecko) Version/7.0 Safari/537.71

Steps to reproduce:

Nothing, this is a regression. Git bisect points to the fix for Bug 855484

* Run the attached demo module against firefox-23 and firefox-24.
* Visit a page with a link whose target attribute is "_blank". Here's a handy one: http://cdn.agilebits.com/kyle/test/newwindowtest.html
* Click the "Open Google In New Window" link



Actual results:

firefox-24: Link tags with a target="_blank" do not properly include Widgets or toolbar buttons using erikvold's toolbarbutton module.
firefox-23 works as expected.

Special notes: This only happens with the default behavior of clicking on a link with target="_blank". If you click the same link and choose Open in a New Window from the context menu, the Widget is there as expected.


Expected results:

Each window should contain the same Widgets and toolbar buttons as the previous window.

Comment 1

[Dave Townsend [:mossop]]

Matteo, does this happen in Australis too?

Comment 2

[Matteo Ferretti [:zer0] [:matteo]]

Following the OP's instructions, I can't reproduce this issue either in Firefox Release (25), Nightly (28) nor UX build.

Jamie, could you check if the behavior is still presente in Firefox release (25)?

Comment 3

[Jamie Phelps]

Just tried in Firefox 25 and a freshly downloaded UX Nightly (28) and it still occurs. Make sure that Firefox is *not* configured to open _blank links in a new tab in the current window. This does not lose the widget in the current window with the new-tab-instead-of-new-window behavior, just when a new window is actually created.

Comment 4

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

Matteo, did you have Firefox configured as described in comment 3?

Comment 5

[Matteo Ferretti [:zer0] [:matteo]]

With the additional setting, I can confirm the bug and that is happening on Australis too.
It seems that the document's readyState in that specific case, never reach "complete"; and therefore the `WindowTracker` never call the `onTrack` method.

Not sure how the Bug 855484 is involved. To me it's more something on platform side that we should investigate, because at line 87 of `window-utils`:

https://github.com/mozilla/addon-sdk/blob/master/lib/sdk/deprecated/window-utils.js#L87

When we attach a listener to load event, the load event for that window is never fired. I also checked that the document's readyState is not already "complete" before adding it:

  console.log(window.document.readyState) // "uninitialized"  
  window.addEventListener('load', _ => console.log('Loaded!'));
  window.addEventListener('load', this, true);

But the 'Logged!' is displayed everywhere but when a new window is opened via link with a blank target.
I'm puzzled here, because I think is not strictly related to SDK – the "load" event should be emitted by that window.
Not sure how to fix that, without changing too much the WindowTracker. Maybe we should understand what's happening on platform side: it seems that the fact that is opening a 'about:blank' and then loading the url given, is the culprit.
My decent guess is that doing so, the inner window is destroyed before the `load` event is emitted, or something similar.

Comment 6

[Erik Vold [:erikvold] (please needinfo? me)]

We are moving the widget module in bug 1118364