842712 - strWindowName of |window.open(strUrl, strWindowName , strWindowFeatures)| should be targeting tab context, this problem only happens win8 metoro UI

Status: VERIFIED FIXED

(Firefox for Metro Graveyard :: Browser, defect, P2)

Description

[Alice0775 White]

Build Identifier :
http://hg.mozilla.org/mozilla-central/rev/953b1db7a246
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:21.0) Gecko/20130215 Firefox/21.0 ID:20130215031040

STR
1. Open metoro Nightly
2. Open index1.html in a curent tab, say [Tab A]
3. Click "open popup-111111" link
   --- observe "popup-111111"  is opened in a new tab, say [Tab B]
4. Switch tab to [Tab A]]
5. Click "open popup-111111" link again
   --- observe tab

Actual Results:
  "open popup-111111" tab is opened in another new tab [Tab C]

Expected Results:
  "open popup-111111" tab should be opened in [Tab B] and focus [Tab B]

Comment 1

[Alice0775 White]

Attachment: sample html

Comment 2

[Asa Dotzler [:asa]]

I saw this while testing the pop-up blocker info bar. Not sure this is a common enough failure to block v1 though.

Comment 3

[Asa Dotzler [:asa]]

moving this out to v2 triage for now.

Comment 4

[Rodrigo Silveira [:rsilveira] [:rodms]]

Time for a dump. I've set the open popups in tabs instead of window prefs on desktop to the same values we have for metro[1] and got the expected behavior. The code to open the URI that will try to find a window by name starts here [2]. Comparing desktop with metro I see that the number of targetable shells in metro is always 1 at [3], it only checks if the current tab has the name we're looking for. On desktop I get the number of tabs.

[1] - https://mxr.mozilla.org/mozilla-central/source/browser/metro/profile/metro.js#374
[2] - https://mxr.mozilla.org/mozilla-central/source/embedding/components/windowwatcher/src/nsWindowWatcher.cpp#477
[3] - https://mxr.mozilla.org/mozilla-central/source/xpfe/appshell/src/nsContentTreeOwner.cpp#242

Comment 5

[Rodrigo Silveira [:rsilveira] [:rodms]]

Attachment: Patch v1

Setting browser type to "content-targetable" instead of just "content" fixes it. It will make the browser element targetable at [1] thus showing up at [2]. The type "content-targetable" is the correct value for applications with multiple browsers according to [3]. This is what desktop is using too[4].

Note that once the popup tab is opened, opening a second link will open it on the already opened tab on the background and will not switch active tab. This is the same behavior as desktop, but in our case it feels like nothing happened because the tabs are not visible. I'll file a new bug once this one lands.

[1] - https://mxr.mozilla.org/mozilla-central/source/content/base/src/nsFrameLoader.cpp#2599
[2] - https://mxr.mozilla.org/mozilla-central/source/xpfe/appshell/src/nsContentTreeOwner.cpp#244
[3] - https://developer.mozilla.org/en-US/docs/XUL/Attribute/browser.type
[4] - https://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml#1502

Comment 6

[Matt Brubeck (:mbrubeck)]

Comment on attachment 8377946 [details] [diff] [review]
Patch v1

Review of attachment 8377946 [details] [diff] [review]:
-----------------------------------------------------------------

Nice find!

Comment 7

[Rodrigo Silveira [:rsilveira] [:rodms]]

https://hg.mozilla.org/integration/fx-team/rev/614d9c806023

Comment 8

[(PTO June 19-July 7) Ryan VanderMeulen]

https://hg.mozilla.org/mozilla-central/rev/614d9c806023

Comment 9

[Marco Mucci [:MarcoM]]

Flagged for testing and verification.

Comment 10

[Kamil Jozwiak [:kjozwiak]]

Went through the following verification/testing process and found an issue. Used the following build:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-02-20-03-02-02-mozilla-central/

Selecting a popup link from [Tab A] the second time around when [Tab B] is already open will not switch focus correctly.

Example of the issue:

1) Open index1.html [Tab A]
2) Tap on "open popup-111111" [Tab B] is created and focus is placed on [Tab B]
3) Slide in the Navigation App Bar and tap on index1.html [Tab A]
4) Select any link from the list and you'll notice that focus is not switching to [Tab B].

Initially it seems that taping on the links isn't doing anything, but in reality the website is being loaded in [Tab B] but the focus is not given to the correct tab after a link has been selected.

I tried this in IE just in case that was the default behavior, but IE is working correctly by switching focus to [Tab B] whenever one of the links is selected.

I've reproduced the original issue from comment #0 using the following build:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-02-08-03-02-07-mozilla-central/

Comment 11

[Rodrigo Silveira [:rsilveira] [:rodms]]

I've opened bug 975457 to track the issue mentioned in comment 5 and comment 10.

Comment 12

[Kamil Jozwiak [:kjozwiak]]

Went through the following verification process with the latest Nightly build:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-02-21-03-02-02-mozilla-central/

As per comment #5, comment #10 & comment #11, Bug #975457 has been created regarding the focus tab issue.

- Went through the original test case from comment #0
- Ensured that taping on all three links created a brand new tab if one wasn't already opened
- Ensured that new tabs are not being created if a popup tab is already opened
- Ensured that the correct website is being used in the previously opened tab
- Ensured that the popup tab is being created in the correct location under the Navigation App Bar
- Went through all of the above test cases in several different variations of snapped view