consequently, neither does onMsgParsed, and a number of things don't happen anymore that would as a matter of course after selecting a message without a layout change. most notably, feed messages are no longer visible. seems nsMsgStatusFeedback isn't restored. also, onEndMsgDownload normally runs each time a pop or feed message is selected, but not for imap or nntp. it may or may not be an oversight that it doesn't for imap.
Keywords: regression, regressionwindow-wanted
alta88, can you estimate or find the regression range?? is bug 535980 a duplicate, or anything else mention there?
i don't know if the reply based bugs are related. bug 531397#c6 seems to have done some analysis in addition to what i found here (a long time ago). in that bug i mention a checkin that broke layouts; that would be 781f622cb9b7 of 2009-06-25. so i'd guess the issue starts there. despite trying quite hard to figure out how to fix layouts, since widethread is very important to me, i abandoned it with a fried brain..
In reply to comment #3) > i don't know if the reply based bugs are related. bug 531397 comment 6 (standard8 comment) seems to have > done some analysis in addition to what i found here (a long time ago). I put regression range at between 20090501 and 20090502. fixing this should help bug 531397. bug 542213 and others should also be checked.(
Whiteboard: [has regression range]
http://hg.mozilla.org/comm-central/pushloghtml?startdate=2009-05-01+03%3A00&enddate=2009-05-02+05%3A00 I would guess the checkin of Bug 438429 - Meta bug to fix several RSS Summary/Web Page
Interesting. If I change layout while on the second (3pane) tab, the second tab's message reader still works, but the first (3pane) tab breaks. This suggests something bad is happening in terms of the msgWindow associated with the first tab...
And I get a this: WARNING: NS_ENSURE_TRUE(!mIsBeingDestroyed) failed: file /home/visbrero/rev_control/hg/comm-central/mozilla/docshell/base/nsDocShell.cpp, line 7948
The nsMessenger's mDocShell is apparently broken. The messenger instance gets told that by a call to setWindow. Each mail tab has their own messenger instance, and each one of those needs to issue a new call to setWindow. not it!
Jim, you love tabs and folderDisplay, right? Mayhaps you like this bug?
(In reply to comment #6) > Interesting. If I change layout while on the second (3pane) tab, the second > tab's message reader still works, but the first (3pane) tab breaks. This > suggests something bad is happening in terms of the msgWindow associated with > the first tab... I hadn't tested in a second tab. But your findings are consistent with the fact that closing 3pane and restarting it "fixes" the problem (and also consistent with reports in other bugs about restarting 3pane, for other types of issues like breakage after replies) Andrew, Thanks for testing this.
there is bug 636874 for tabs/layout.
I also encountered this bug on version 17.0.8, and fixed it myself. Andrew Sutherland is right, while changing layout, it goes to function UpdateMailPaneConfig in msgMail3PaneWindow.js, notice this line: desiredParent.appendChild(messagePaneBoxWrapper); The browser is picked up and inserted into a new element, which makes the inside DocShell changed. As the nsMsgStatusFeedback is not registered into the new DocShell, when the message finishes loading, OnEndMsgDownload is no longer reached. How I fixed: 1. nsMsgWindow::GetMessageWindowDocShell in nsMsgWindow.cpp, change "if (docShell)" into "if (true)", which means always get the messagepane's doc shell, insteading return the old one. 2. function UpdateMailPaneConfig in msgMail3PaneWindow.js, add: msgWindow.statusFeedback = msgWindow.statusFeedback; after desiredParent.appendChild(messagePaneBoxWrapper); which register the nsMsgStatusFeedback into the new doc shell.
windywater: can you attach a patch for that?
You need to log in before you can comment on or make changes to this bug.