Closed Bug 640062 Opened 9 years ago Closed 9 years ago

Panorama tabs-from-other-windows button displays  


(Firefox Graveyard :: Panorama, defect, P4)



(blocking2.0 -)

Firefox 6
Tracking Status
blocking2.0 --- -


(Reporter: ashughes, Assigned: raymondlee)



(Whiteboard: [4rc])


(2 files, 2 obsolete files)

When searching for a tab from another window, Panorama displays a message at the bottom with a button to switch to the tab. The button itself works but displays "&nbps;" as the label.

1. Open a few tabs in the main window to different pages
2. Open a new window
3. Open the Tab Groups view
4. Click the search button
5. Type the name of one of the loaded pages

Tabs from other windows [ ]

Tabs from other windows [something_more_identifiable]
Attached image Screenshot
1. Yahoo! Canada is loaded in the 2nd-last tab on the main window
2. Search from Panorama for "Yahoo" in the 2nd window
3. Button label at the bottom of the Panorama window
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0) Gecko/20100101 Firefox/4.0

Works fine for me
I am able to reproduce the problem as reported, for some web pages. For the search currently being made in another window, two tabs show up with correct titles and two as [ ]. The following worked correctly:

The following showed up as [ ]:

Windows XP
Mozilla/5.0 (Windows NT 5.2; WOW64; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre
Some more experiments:

1. A tab open to bug 640062 from previous experiments, second window in existence.
2. Open a new tab with .
3. Search for "64" in the Tab Groups window.

Result: The "640062" tab showed up correctly, but "640044" showed up as [ ].

4. Closed the searching window, created a new window, opened tab groups, searched for 64:

Result: Both tab titles showed up correctly -- PROBLEM FIXED.

5. Opened second tab containing bug 640062 and searched 640052.

Result: one tab showed up correctly, the other didn't.

6. Trying to test the pattern I noticed, closed the second window, created a new window, open the tab group search and searched for 640062.

Result: This time the problem was NOT FIXED, one tab still showed up as [ ].

7. Closed the tab group window and created a new one:

Result: Still NOT fixed.
Sorry for the multiple comments, but I can't stop testing this bug.

The tab group search will normally search on URLs and tab titles. It appears that in situations where [ ] shows in the search result, the tab group search does not search on the tab title.

Also (and this may be related or a separate bug), when a tab title change, tab group search doesn't notice.

These two behaviors are demonstrated in this sequence:

1. Open .
2. Create a second window and enter tab groups.
3. Click on a link in the Yahoo Canada tab. For me this went to:

Title: Seven years on, Bertuzzi hockey violence saga still heading to court

4. Open another tab with the article in step 3.
5. In tab groups, search for "4398825" (URL from article in step 3).

Result:  Two "tabs from other windows" displayed, one says "Yahoo! Canada", the other says "Seven year on, Bertuzzi hockey".
Expected: Both say "Seven year on, Bertuzzi hockey".

6. Search tab groups for "hockey".

Result: One search match.
Expected: Two search matches.
This seems to work fine in Ubuntu 10.10, Windows XP, and Windows 7 with 4.0rc1. Looks like it could be a Mac-only bug.
I'll try to find a regression window for this bug.
(In reply to comment #7)
> I'll try to find a regression window for this bug.

This is a bug which has been present since this feature was added.  I think it's caused by the fact that we're using innerHTML to grab the tab title, instead of textContent.

I'm asking if this should block final, be taken as a ride-along, or should we wait until a 4.x to fix it?
blocking2.0: --- → ?
I don't even think it's a .x fix, just a visible bug :(
blocking2.0: ? → -
I agree with Mike. I'll add it to our list, thanks for all the testing!
Blocks: 603789
Priority: -- → P4
Target Milestone: --- → Future
Target Milestone: Future → ---
Attached patch v1 (obsolete) — Splinter Review
trivial patch
Attachment #524005 - Flags: feedback?(tim.taubert)
Comment on attachment 524005 [details] [diff] [review]

Looks good!
Attachment #524005 - Flags: review?(ian)
Attachment #524005 - Flags: feedback?(tim.taubert)
Attachment #524005 - Flags: feedback+
Comment on attachment 524005 [details] [diff] [review]

Attachment #524005 - Flags: review?(ian) → review+
Assignee: nobody → raymond
OS: Mac OS X → All
Hardware: x86 → All
Attached patch v2 (obsolete) — Splinter Review
Minor update to fix the test.

Passed Try.
Attachment #524005 - Attachment is obsolete: true
Attachment #525043 - Flags: review?(ian)
Comment on attachment 525043 [details] [diff] [review]

Attachment #525043 - Flags: review?(ian) → review+
Attachment #525043 - Attachment is obsolete: true
Keywords: checkin-needed
Keywords: checkin-needed
Whiteboard: [4rc] → [4rc][fixed-in-cedar]
Target Milestone: --- → Firefox 6
Closed: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [4rc][fixed-in-cedar] → [4rc]
Verified on Mozilla/5.0 (Windows NT 5.1; rv:6.0a1) Gecko/20110421 Firefox/6.0a1
No longer blocks: 603789
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.