Closed Bug 842712 Opened 7 years ago Closed 6 years ago

strWindowName of |, strWindowName , strWindowFeatures)| should be targeting tab context, this problem only happens win8 metoro UI


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

Windows 8.1


(Not tracked)

Firefox 30


(Reporter: alice0775, Assigned: rsilveira)



(Keywords: testcase, Whiteboard: p=3 s=it-30c-29a-28b.2 r=ff30)


(2 files)

Build Identifier :
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:21.0) Gecko/20130215 Firefox/21.0 ID:20130215031040

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]
Attached file sample html
Keywords: testcase
Summary: strWindowName of |, strWindowName , strWindowFeatures)| should be targeting tab context → strWindowName of |, strWindowName , strWindowFeatures)| should be targeting tab context, this problem only happens win8 metoro UI
Component: Tabbed Browser → Browser
Product: Firefox → Firefox for Metro
Whiteboard: [metro-mvp?]
Version: 21 Branch → Trunk
I saw this while testing the pop-up blocker info bar. Not sure this is a common enough failure to block v1 though.
moving this out to v2 triage for now.
Blocks: metrov2planning
No longer blocks: metrov1triage
No longer blocks: metrov2planning
Whiteboard: [metro-mvp?]
Whiteboard: [defect]
Whiteboard: [defect] → [defect] p=0
Whiteboard: [defect] p=0 → [defect] p=3
Target Milestone: --- → Firefox 30
Assignee: nobody → rsilveira
Priority: -- → P2
QA Contact: jbecerra
Whiteboard: [defect] p=3 → [defect] p=3 s=it-30c-29a-28b.1
Whiteboard: [defect] p=3 s=it-30c-29a-28b.1 → p=3 s=it-30c-29a-28b.1 r=ff30
Target Milestone: Firefox 30 → ---
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] -
[2] -
[3] -
Whiteboard: p=3 s=it-30c-29a-28b.1 r=ff30 → p=3 r=ff30
QA Contact: jbecerra → kamiljoz
Whiteboard: p=3 r=ff30 → p=3 s=it-30c-29a-28b.2 r=ff30
Attached patch Patch v1Splinter Review
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] -
[2] -
[3] -
[4] -
Attachment #8377946 - Flags: review?(mbrubeck)
Comment on attachment 8377946 [details] [diff] [review]
Patch v1

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

Nice find!
Attachment #8377946 - Flags: review?(mbrubeck) → review+
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 30
Flagged for testing and verification.
Flags: needinfo?(kamiljoz)
Went through the following verification/testing process and found an issue. Used the following build:

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:
Flags: needinfo?(kamiljoz)
Resolution: FIXED → ---
Blocks: 975457
I've opened bug 975457 to track the issue mentioned in comment 5 and comment 10.
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Went through the following verification process with the latest Nightly build:

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
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.