Closed Bug 20546 Opened 25 years ago Closed 25 years ago

splitter not heeding collapsed state (in localstore.rdf), causes user to think they can't view mail messages

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: akkzilla, Assigned: eric)

References

Details

I click on my inbox in the folder pane, get the imap password dialog, type in my password, get all my headers, click on a header ... and nothing happens. The message pane still shows the netcenter ad. I can click around in the thread pane and select different messages -- the app isn't hung -- and I can also reply to the message I'm not seeing, and the message body gets quoted correctly in the compose window, so it's just a message pane problem. I started seeing this in a build I pulled 11/30 am, and I also see it in the 11/30 and 12/1 release builds and in the build I updated today (12/1).
BTW, you're welcome to look at my prefs in /u/akkana/.mozilla/akkana/. I haven't edited that file in a long time, so if there's anything screwy there, it came from running seamonkey.
akk, i forgot to ask you one more question...when you click on a message to display it...is there anything signficant printed out to the xterm window? (like something failed to load.....)
Nope, no messages at all to stdout.
Did you just start to see this Akkana? (may be the same or different than what Akkana is reporting here): I've been seeing something similar on Linux for the last few days, but only after I do a bunch of stuff like deleting and switching folders. I haven't found a reproducible sequence of steps yet so I haven't filed a bug.
As I mentioned, this started happening yesterday, and it's 100% reproducible -- I can never load a single message.
can you do a ls -al /tmp/nsmail.eml and paste the results back here. also, let me know which user you are running mozilla as?
Whiteboard: [PDT+]
Putting on PDT+ radar.
*** Bug 20649 has been marked as a duplicate of this bug. ***
This occurrs for some people on the Mac too....(see 20649)
OS: Linux → All
Hardware: PC → All
This is now reproducible on Seth's system after you select a few msgs first. mscott says it's the same cause as what akkana may be seeing.
*** Bug 20653 has been marked as a duplicate of this bug. ***
another data point: when I see it, I break in the debugger, and then start again, and it works. what happens when it comes back to life is biff is going off. my biff interval is every 1 minute. when it happens again, I'll get the full stack of the one imap thread.
need projected fix date in status whiteboard please
Whiteboard: [PDT+] → [PDT+] guessing 12/9....
I haven't been able to think of something that could be causing this problem yet so I'm not sure how long it will take to fix. I'll just pick a date and say 12/9 but we'll have to see. I'm worried that the problem is another symptom of linux running events from the wrong thread! =(
I'm seeing something like this in news, in my debug build
QA Contact: lchiang → pmock
changing qa assigned to pmock@netscape.com
Target Milestone: M12
Setting target fix to M12.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
This now works for Akkana in todays build! What changed? Well we no longer need to write the message body out to a temp file as of last night. Maybe it is related to removing that code? Marking as fixed. We'll probably have to re-open 20653 because that now appears to be a separate problem. But it isn't a dogfood stopper (I don't think). Marking as fixed.
Status: RESOLVED → REOPENED
Bad news -- it's baaack. I can't read mail in either this morning's release build or in my debug build updated this afternoon.
Resolution: FIXED → ---
can we try to duplicate this and get a stack trace?
daver, there won't be a stack trace since it's not crashing. mscott, if you want, I can go down to akkana's cube and break out the debugger and go medevil on this bug.
Have you tried dougt's patch, Akkana?
Blocks: 21564
I just tried his patch. It's doing something, because now I get a huge slew of "attemping to process events on the wrong thread: 'correctThread'" assertions while loading the mailbox, but the end result is the same -- I can load headers, but not a message.
Whiteboard: [PDT+] guessing 12/9.... → [PDT+] getting QA help to repro
Assignee: mscott → sspitzer
Status: REOPENED → NEW
taking bug from mscott, I'm going to debug on akkana's machine.
Status: NEW → ASSIGNED
Whiteboard: [PDT+] getting QA help to repro → [PDT+] going to debug 12-13 / 12-14 with akkana
changing status, accepting.
I see this behavior in mail and news. I see it with both the win32.zip and the installer.exe builds from the last four or five days. I have been able to work around the bug by giving focus to the browser window, the DOS console and then returning focus to the mail-news window. Sometimes I have to hit the stop button in mail-news before I switch to the browser and consle windows but I can always get the message to display by doing this maneuver. Sometimes I have to repeat the process a couple of times. I have no idea if what I'm doing makes any sense but it seems to work and that must say something.
*** Bug 20141 has been marked as a duplicate of this bug. ***
Whiteboard: [PDT+] going to debug 12-13 / 12-14 with akkana → [PDT-] it's something with akkan's prefs, not dogfood
akkana I determined that it's something in her prefs, I'm investigating more now. removing PDT+ since I'll have a work around soon.
OK, I narrowed this down some. If mail-news is the only thing I have open and I click on a header the spinner starts spinning and no message appears. I've waited as long as five minutes. If I minimize the mail-news window the message loads almost immediately ( I can see it on the console).
Summary: [DOGFOOD] can't load a message in the message pane → [DOGFOOD]can't load a message in the message pane, caused by my localstore.rdf
Whiteboard: [PDT-] it's something with akkan's prefs, not dogfood → [PDT-] it's something with akkana's localstore.rdf, not dogfood
there is a work around for akkana's problem. something is up with her localstore.rdf, when we move it to the side and start back up, she can read mail. I'm looking into what is causing the problem now. not pdt+, since there is a work around.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → WONTFIX
Summary: [DOGFOOD]can't load a message in the message pane, caused by my localstore.rdf → can't load a message in the message pane, caused by my localstore.rdf
Whiteboard: [PDT-] it's something with akkana's localstore.rdf, not dogfood → it's something with akkana's localstore.rdf, not dogfood
the following lines in akkana's localstore.rdf were causing the problem. if you remove them, it will fix the problem. akkana, did you put those lines in there by hand, in attept to close the messenger sidebar always? I'm not going to spend any more time on this, since I don't think you can do that to your localstore.rdf unless you hand edit it. removing dogfood and pdt. marking wontfix, unless of course, you can do that to your localstore.rdf without editing it by hand. <RDF:Description about="chrome://messenger/content/#gray_horizontal_splitter"> <state>collapsed</state> </RDF:Description>
Status: RESOLVED → REOPENED
Whiteboard: it's something with akkana's localstore.rdf, not dogfood → it's gray_horizontal_splitter in localstore.rdf
I did not add that by hand. Seth, does this mean I should reopen the bug? I'm not the only person who has seen this problem, either. Agreed that removing these lines cures the problem, so I'm mail-reading again and don't consider this a PDT blocker. Thanks! There are lots of problems with localstore.rdf and persistence, and perhaps the appearance of these lines is related to some of the other bugs. Cc'ing waterson.
Assignee: sspitzer → evaughan
Status: REOPENED → NEW
Summary: can't load a message in the message pane, caused by my localstore.rdf → [DOGFOOD] splitter not heeding collapsed state (in localstore.rdf), causes user to think they can't view mail messages
Whiteboard: it's gray_horizontal_splitter in localstore.rdf
Resolution: WONTFIX → ---
so putterman has figured it out. it is a real bug, sorry for marking it wontfix. the problem is that we are keeping the collapsed state of the splitter in localstore.rdf, but the splitter (in mailnews and in browser) is not heeding the state. the reason akkana's bug was happening is that at some point she collapsed the splitter between the thread and message pane, and quit. then started back up, and the state of the splitter in localstore.rdf was collapsed, but visually it was not collapsed. putterman has code that checks the state of the splitter, and if collapsed, we don't display messages (which makes sense.) as soon as the splitter heads the state, all is well, because when akkana starts up, the message pane would be closed, and to view a message, she'd have to open it. re-assign to evaughan, since this is splitter bug. the work around, for mail news, is to close and then open the message pane. putterman and I are going to see if we can figure out a fix, but don't hold your breath.
Assignee: evaughan → sspitzer
:)
Whiteboard: [PDT+]
Putting on PDT+ radar.
there's a workaround for this: collapse and reexpand your splitter.
and since there is a workaround and this is not blocking anyone from using the product, I suggest we don't pdt+ this.
Agreed -- I'm one of the main "victims" of this, and the workaround is working fine for me so far. Doesn't need to be PDT+ for M12.
Status: NEW → ASSIGNED
Summary: [DOGFOOD] splitter not heeding collapsed state (in localstore.rdf), causes user to think they can't view mail messages → splitter not heeding collapsed state (in localstore.rdf), causes user to think they can't view mail messages
Whiteboard: [PDT+]
Target Milestone: M12 → M13
removing dogfood and pdt. moving to m13
*** Bug 21125 has been marked as a duplicate of this bug. ***
Assignee: sspitzer → evaughan
Status: ASSIGNED → NEW
eric, now that this is purely a splitter bug, re-assigning to you.
*** Bug 20173 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Target Milestone: M13 → M14
*** Bug 23895 has been marked as a duplicate of this bug. ***
*** Bug 23617 has been marked as a duplicate of this bug. ***
Blocks: 24700
putting on beta1 radar
Whiteboard: Fixed awaiting checkin
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Blocks: 29813
I took out my work around and I still see the problem. Does this really work for mailnews? 1. Take out references to "hackforbug20546" in sidebarOverlay.xul and sidebarOverlay.js. 2. Collapse the sidebar by clicking on the grippy. 3. Open a new navigator window. The sidebar will be open in the new window.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
No, this isn't fixed for mailnews. I collapsed the threadpane splitter and quit. When I started up, the splitter wasn't collapsed and when I clicked on a message it didn't display. clicking on the splitter made the message display.
since this is reopened, I'm clearing the status whiteboard text which was entered before the bug was reopened.
Whiteboard: Fixed awaiting checkin
Fixed. Just add persist="collapsed" to the sibling of the splitter whose collapsed state needs to be remembered. I alreaded made the changes for the sidebar splitters and the horizontal grey line in the messenger three pane view.
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Verified as fixed on win32, macos, and linux using the following builds: win32 commercial seamonkey build 00051109-m16 installed on Dell P500, Win98 macos commercial seamonkey build 00051008-m16 installed on G3/400, MacOS 9.04 linux commercial seamonkey build 00051008-m16 installed on P200, RedHat 6.1
Status: RESOLVED → VERIFIED
No longer blocks: 21564
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.