Closed Bug 631983 Opened 9 years ago Closed 8 years ago
[tabmail] "Error: this
.m Current Browser is null" [tabbrowser .xml doc Shell property]
Now that I've fixed the constructor and destructor in tabbrowser not to fall over when in tabmail, I'm seeing other errors like this: Error: this.mCurrentBrowser is null Source file: chrome://navigator/content/tabbrowser.xml
AFAICS it's the select handler (onxblselect), triggered when you select a folder: <handler event="select" action="if (event.originalTarget == this.mPanelContainer) this.updateCurrentBrowser();"/> I cannot tell where exactly it breaks because stupid Venkman only sees very few of tabbrowser.xml's methods for some reason and hangs if I do some Step Into's and Step Out's in succession starting from the above handler breakpoint. :-(
In Tabmail: <xul:tabbox anonid="tabbox" flex="1" eventnode="document" xbl:inherits="handleCtrlPageUpDown" onselect="if (event.target.localName == 'tabs' && 'updateCurrentTab' in this.parentNode) this.parentNode.updateCurrentTab();"> If we move the onselect handler into the <handlers> section e.g.: <handler event="select" action="if (event.originalTarget == this.tabContainer) this.updateCurrentTab();"/> This should override the handler inherited from tabbrowser.
(In reply to comment #2) > This should override the handler inherited from tabbrowser. No, unfortunately onxblselect seems to trigger all associated select handlers on the inheritance chain (i.e. first the tabmail one if defined, then the tabbrowser one), and I found no way to cancel it (like event.preventDefault or event.stopPropagation). Actually I'd be interested if it's possible at all, because it might help with fixing bug 409792.
Untested suggestions: 1. In tabmail create a stub method "updateCurrentBrowser" that just points to updateCurrentTab. 2. Try <handler event="select" phase="capturing" .../>.
Thanks for those tips but I found I prematurely blamed the select handler. Since Venkman is completely useless for debugging XBL (unfortunately) I resorted to adding Components.utils.reportError statements until I found the real culprit: <property name="docShell" onget="return this.mCurrentBrowser.docShell" readonly="true"/> (tabbrowser.xml line 2608) So this is in fact one of those "docShell is null" issues. And I fear that's above my head.
Summary: [tabmail] "Error: this.mCurrentBrowser is null" → [tabmail] "Error: this.mCurrentBrowser is null" [tabbrowser.xml docShell property]
See bug 638915 for another tabmail issue that I have been seeing for quite some time already (but only now cared to file).
(In reply to Jens Hatlak (:InvisibleSmiley) from comment #5) > So this is in fact one of those "docShell is null" issues. And I fear that's > above my head. Neil/Karsten any chance we can narrow this down, I fear on this (it looks bad + it might be masking other problems)
> <property name="docShell" > onget="return this.mCurrentBrowser.docShell" > readonly="true"/> Perhaps in tabmail.xml we should get the docshell from this.currentTabInfo.getBrowser().docshell instead. Neil/Karsten?
Does anyone have any STR? (Just opening and closing the mail window isn't enough, although I did notice a strict warning from messagePaneOnResize for some reason.)
IIRC. Open a few tabs. Tab around. Close a few tabs.
Minimum STR: 1. start SM with fresh profile 2. open MailNews 3. create Blogs & News Feeds account 4. expand Blogs & News Feeds account (left pane) 5. select Trash folder under Blogs & News Feeds account (left pane)
OK, so I've traced it as far as a pagehide event, but I haven't worked out which JS object the event is being called on.
So, the pagehide event is being handled by browser.xml's onPageHide method. It checks for !this.docShell || !this.fastFind which are properties. fastFind looks for a tabbrowser and retrieves its fastFind property. The tabbrowser hasn't created a fastFind yet, so it does so. It tries to init it using its current docShell. However it doesn't have one. Thunderbird doesn't have a problem because it doesn't have a tabbrowser.
Don't confuse people into thinking we're a tabbrowser when we're not.
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #566172 - Flags: review?(mnyromyr)
Comment on attachment 566172 [details] [diff] [review] Proposed patch So, this patch works, because browserBindings.getTabBrowser tries to find an enclosing tabbrowser by walking up the DOM tree, which will fail only then. (The assumptions getTabBrowser makes are a bit overly optimistic, imo, but that's toolkit for you …)
Attachment #566172 - Flags: review?(mnyromyr) → review+
Pushed changeset 820f6ebfe077 to comm-central.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.