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. Steps: 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 Result: Tabs from other windows [ ] Expected: Tabs from other windows [something_more_identifiable]

NOTE: 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: https://bugzilla.mozilla.org/show_bug.cgi?id=640062 https://wiki.mozilla.org/Firefox/4/Triage The following showed up as [ ]: http://www.google.com/search?q=yahoo+canada&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:unofficial http://ca.yahoo.com/ http://www.google.com/ https://encrypted.google.com/ http://www.cnn.com/ http://www.npr.org/ https://www.mozilla.org/ about:support 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 https://bugzilla.mozilla.org/show_bug.cgi?id=640044 . 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 http://ca.yahoo.com/ . 2. Create a second window and enter tab groups. 3. Click on a link in the Yahoo Canada tab. For me this went to: URL: http://ca.sports.yahoo.com/nhl/news?slug=starph-ca-4398825 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. <http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabview/search.js?force=1#128>

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?

I don't even think it's a .x fix, just a visible bug :(

I agree with Mike. I'll add it to our list, thanks for all the testing!

bugspam

trivial patch

Comment on attachment 524005 [details] [diff] [review] v1 Looks good!

Comment on attachment 524005 [details] [diff] [review] v1 Excellent

Minor update to fix the test. Passed Try. http://tbpl.mozilla.org/?tree=MozillaTry&rev=21c513bfa4e6

Comment on attachment 525043 [details] [diff] [review] v2 Cool.

Verified on Mozilla/5.0 (Windows NT 5.1; rv:6.0a1) Gecko/20110421 Firefox/6.0a1