Closed Bug 578147 Opened 12 years ago Closed 12 years ago
Select not fired (NS _ERROR _FAILURE) [ns IType Ahead Find .set Doc Shell]
From bug 576393 comment 3: The "TabSelect" event stops firing when the following error occurs. I am checking to see whether this is something to do with Tab Candy or the Firefox core code itself. Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsITypeAheadFind.setDocShell]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://browser/content/tabbrowser.xml :: updateCurrentBrowser :: line 887" data: no] This was worked around for TabCandy by adding a try/catch: http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/rev/d4a42b589b7c
Mardak, can you add that change as a patch here, and ask one of the peeps I've cc'd for review? Let's wallpaper the event-killing exception first, and then figure out why fastfind is barfing.
OS: Mac OS X → All
Hardware: x86 → All
Assignee: nobody → edilee
Status: NEW → ASSIGNED
Attachment #457110 - Flags: review?(dao)
I'd rather understand what's going on first before we effectively ignore the failure. Is this with TabCandy living in a hidden tab?
This is TabCandy in an iframe in a deck.
So TabCandy doesn't really interfere tabbrowser, other than hiding a selection of tabs? Can the issue be reproduced easily, and can it be reproduced without TabCandy?
Comment on attachment 457110 [details] [diff] [review] v1 This looks wrong to me. Switching to Mano, though, since he's been working on the find bar on and off.
Attachment #457110 - Flags: review?(dao) → review?(mano)
Comment on attachment 457110 [details] [diff] [review] v1 Same here, at least until we know what's causing that.
Attachment #457110 - Flags: review?(mano) → review-
Raymond, Ian, someone was investigating this? Do you have various STR with or without tabcandy?
It only happens with Tab Candy but can't see how change to an iframe in a deck triggers the problem. Steps to reproduce: 1) Open a window and some tabs 2) Go to the tab candy interface by switching to an iframe in a deck (http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/file/23ee7e46a0b4/browser/base/content/browser.xul) 3) Make the browser window lose the focus by switching to other window 4) When the window regains the focus, the TabSelect stops firing and throws the error in comment 0 when switching between tabs.
What is this.mCurrentBrowser.docShell when this exception is thrown?
I tried adding this.mCurrentBrowser.docShell to the reportError but couldn't trigger the exception... Perhaps it was fixed! Mitcho said that it wasn't easily reproducible and switching from the same set of tabs didn't consistently trigger the issue. Ian? Raymond? Are you able to reproduce it and figure out what's docShell?
I can't reproduce it anymore. But I figure out that it's to do with the "focus". If I comment out the following line in ui.js when error occurs again. currentWin.document.getElementById("tab-candy").contentWindow.focus(); http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/file/192b9886313a/browser/base/content/tabcandy/app/ui.js#l166 this.mCurrentBrowser.docShell is [xpconnect wrapped (nsISupports, nsIDocShell, nsIWebNavigation, nsIDocShellHistory, nsIInterfaceRequestor, nsIWebProgress)] Source File: chrome://browser/content/tabbrowser.xml I think we can remove the try/catch block around the this._fastFind.setDocShell() since it doesn't occur anymore.
Backed-out the try/catch code while preserving the original code annotation. :) http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/rev/76db011a667a Prepare to backout d4a42b589b7c from bug 576393. http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/rev/5e07109502c6 Backout tabbrowser.xml changes from bug 576393.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.