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

RESOLVED WONTFIX

Status

Add-on SDK
General
P3
normal
RESOLVED WONTFIX
4 years ago
3 years ago

People

(Reporter: Jamie Phelps, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
Created attachment 816096 [details]
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.
Matteo, does this happen in Australis too?
Flags: needinfo?(zer0)
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)?
Flags: needinfo?(zer0) → needinfo?(jamie)
(Reporter)

Comment 3

4 years ago
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.
Flags: needinfo?(jamie)
Matteo, did you have Firefox configured as described in comment 3?
Flags: needinfo?(zer0)
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.
Flags: needinfo?(zer0)

Updated

4 years ago
Priority: -- → P3
Blocks: 821481
We are moving the widget module in bug 1118364
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.