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)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect

Tracking

(Not tracked)

Status:
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 ago → 25 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 ago → 25 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 ago → 25 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.