Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110311 Firefox/4.0b13pre The context menu "Search Google for" is broken in popup windows. STR: 1. Open a popup without navigation toolbar and tab bar: In the error console, evaluate this: window.open("http://www.mozilla.org", "", "location=no") 2. In the popup window, select any text, right-click, and select "Search Google for" in the context menu. Expected result: new tab opened either in the popup window (like in 3.6) or the main window. Actual results: 1. Nothing. 2. When you close the supposedly single tab in the popup by pressing Ctrl+w, there's your search tab, hidden behind the one you just closed. After a second or two, an alert dialog opens: Assertion Failed ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589) Stack Trace: 0:([object XULElement],[object XULElement],0) 3. After closing that dialog, interacting with the search results page is broken in strange ways and throws several errors.
Instead of step 1, open the testcase and click the link to open the popup. Then proceed with step 2.
Being a release build, Firefox 4.0rc1 doesn't display the Assertion Failed dialog and reports to the error console instead.
And a hidden tab is created after doing search select. Firefox should open the new tab in a full browser window. I think this should block 2.0
Summary: context/right-click menu "Search Google for" broken in popup windows, displays assertion failed dialog → context/right-click menu "Search Google for" broken in popup windows, displays assertion failed dialog, And Firefox should open the new tab in a full browser window
Though this makes us obey the browser.tabs.loadBookmarksInBackground pref where we wouldn't before, which I think may be problematic. Maybe this should depend on the aInBackground changes from bug 610203's patch...
Nope, this uses browser.tabs.loadInBackground just like gBrowser.loadOneTab.
(In reply to comment #6) > Nope, this uses browser.tabs.loadInBackground just like gBrowser.loadOneTab. Oh, I missed that loadOneTab checks the pref. It checks browser.tabs.loadInBackground, though, whereas with that patch won't we end up using browser.tabs.loadBookmarksInBackground (aFromChrome is true via openLinkIn)...
(In reply to comment #8) > Oh, I missed that loadOneTab checks the pref. It checks > browser.tabs.loadInBackground, though, whereas with that patch won't we end up > using browser.tabs.loadBookmarksInBackground (aFromChrome is true via > openLinkIn)... openUILinkIn sets fromChrome, openLinkIn doesn't.
Quite true. I misread the patch. I hate it when I do that.
OS: Windows 7 → Windows XP
Whiteboard: [4rc] → [4rc] fixed-in-cedar
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Whiteboard: [4rc] fixed-in-cedar → [4rc]
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.2a1pre) Gecko/20110326 Firefox/4.2a1pre
Status: RESOLVED → VERIFIED
OS: Windows XP → All
Hardware: x86 → All
Verified fixed on Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110404 Firefox/4.2a1pre
You need to log in before you can comment on or make changes to this bug.