Closed Bug 644983 Opened 10 years ago Closed 10 years ago
.top .content is null (unable to view feed entries)
STR: - install webtabs from http://firstname.lastname@example.org - open a twitter tab - switch to the main mail:3pane tab - select multiple threads (so that you get the MultiMessageSummary) - switch to the twitter tab - switch back to the main mail:3pane tab - click on one of your RSS feeds - there should be a message displayed ; instead, the message pane is blank, and the error console reads Error: window.top.content is null Source File: chrome://messenger/content/mailWindowOverlay.js Line: 3072 This happens *without* Thunderbird Conversations. Double-clicking on a feed item fixes the issue.
Does anyone have an idea for that? This is pretty annoying, and it also breaks navigation with the space key, since window.content is null too... I think I'll try to tackle this soon. Any advice would be most welcome :-)
blocking-thunderbird5.0: --- → ?
Not sure this would block 3.3, but most definitely wanted. I think the way I would approach it would be that you need to ask tabmail (iirc) for the browser associated with the active tab, then you can do browser.content.document I think. This would also help the future case where we'd like to drop the single 'messagepane' browser per window (i.e. have one browser instance per tab).
Assignee: nobody → jonathan.protzenko
Status: NEW → ASSIGNED
So this is more or less what you described in comment #2. The tabmail now exposes a new property, called "currentBrowser", which in turn asks the current tab for its current browser. For chrome tabs, and content tabs, this is the browser that holds the page. For the 3pane tab, this is either the multimessage browser if in multimessage mode, or the messagepane if in single message. This seems to solve the issues I experienced...
Attachment #536398 - Flags: review?(mbanner)
Comment on attachment 536398 [details] [diff] [review] Ask the tabmail for the current tab's browser Unless I'm very much mistaken, getBrowserForSelectedTab already does exactly what you want. I think also in mailWindowOverlay you should probably just check for a null browser returned, just in case someone does a tab type without a browser element.
Attachment #536398 - Flags: review?(mbanner) → review-
Mark, I've updated the patch to use the builtin getBrowser() function which makes things simpler. I've also added a comment explaining why it's safe to get the current browser. I don't think we can have both no 3pane *and* gFolderDisplay.selectedMessageIsFeed at the same time (or that would be very, very wrong).
Comment on attachment 537788 [details] [diff] [review] New version that uses builtin functions (simpler) This looks good. Please land on comm-central and comm-miramar, we'll do comm-aurora in a day or so.
http://hg.mozilla.org/comm-central/rev/e4bf37abb9f4 http://hg.mozilla.org/releases/comm-miramar/rev/db20d8fcbe36 Just ping me when you want me to land this on comm-aurora.
Will do, but we can call this fixed for now (the approval flag can track it).
Attachment #537788 - Flags: approval-comm-aurora? → approval-comm-aurora+
Checked into aurora: http://hg.mozilla.org/releases/comm-aurora/rev/0b9e76f868ba
You need to log in before you can comment on or make changes to this bug.