Closed Bug 282593 Opened 20 years ago Closed 20 years ago

switching between mail folders fails: GetMessagePaneFrame() has no properties

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 282938

People

(Reporter: spam, Assigned: sspitzer)

References

Details

(Keywords: regression) 

2005021614 and yestedays trunk build as well, XP

Mail is now nearly unusable. Folder view fails to change most of the time when
you click another folder, and is stuck with the previous view. JS errors:

when starting mailnews, this appears:

Error: myDefaultStatus is not defined
Source File: chrome://messenger/content/mailWindow.js
Line: 383

When clicking inbox first time, the inbox displays with content.
But click another folder and this JS errors spawns, and the msgview is the same
as for inbox - it doesn't change!

Error: GetMessagePaneFrame() has no properties
Source File: chrome://messenger/content/msgMail3PaneWindow.js
Line: 1144

This can probably cause severe dataloss if someone selects the messages and
deletes them, thinking they are in the trash folder, but in reality are in the
inbox.
Flags: blocking1.8b?
Summary: siwtching between folders fails → siwtching between folders fails: GetMessagePaneFrame() has no properties
Flags: blocking1.8b2?
if i delete XUL.mfl, this works again - untill i click a link in mail:
that will fail, and this bug reappears "forevermore". Untill i delete XUL.mfl
again. The improvement deleting the corrupted XUL.mfl causes, will last through
restarts. But as mentioned: if i click a link, the cardhouse collapses.

Clicking links in mail now failing i reported in bug 282594. Since nobody else
sees that bug i'll resolve them both as invalid.

It must be a local misconfiguration. This is WinXP SP2 with all updates, and a
less than two months old PC.
Outlook, here I come.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
happens only in alternate threepane, message pane at bottom is testes.
Default 3-pane is OK. Reopening.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Summary: siwtching between folders fails: GetMessagePaneFrame() has no properties → swtching between folders fails: GetMessagePaneFrame() has no properties
Summary: swtching between folders fails: GetMessagePaneFrame() has no properties → switching between folders fails: GetMessagePaneFrame() has no properties
Too late for 1.8b1, plussing for 1.8b2, assuming that it is reliably
reproducable with alternate 3-pane.
Flags: blocking1.8b?
Flags: blocking1.8b2?
Flags: blocking1.8b2+
Flags: blocking1.8b-
funky, I can more or less repro this on 2005021714-trunk mac mozilla build.

1. click on a folder, can display messages; clicking on another folder also
displays its appropriate content.

2. go back to Inbox, select a message with a link, and click the link (encounter
bug 282594).

3. click on another folder (call this folder #2).

results: still displays Inbox's contents.

4. click on yet another folder (call this folder #3).

results: able to see folder #3's contents.

5. click back on folder #2, and you'll be able to see its contents correctly, but...

6. ...if you click on Inbox again, then any other folder, you'll run into the
non-updating issue again.

it's an annoying, but clicking on a non-Inbox folder seems to workaround this
weirdness.

rkaa, how does this workaround behave for you?
OS: Windows XP → All
Hardware: PC → All
I wouldn't call that a workaround. Test this, while the bug is occuring, and you
see what i mean:

click inbox, click sent, click inbox, click sent, click inbox, click sent

etc etc etc

Every second time you click Sent it will display its own content.
And every other time it will display the content of inbox

You can click Inbox/trash/inbox/trash and get the same result. Etc.

Now test this: WHILE it's seemingly displaying the content of the Inbox in Sent,
click a message there and you can read it, delete it or whatever.

And: After deleting a message from a bogus display in Sent and then clicking
Trash, the TRASH folder now displays the content of the inbox instead.
So, a situation where you click another folder than inbox first, and still get a
wrong display on next click.

This is just messed up. Since clicking a link initially seems to have something
to do with it, it's tempting to believe that the same checkin caused both this
and bug 282594. There was a "clicking link in mail fails" bug fixed some weeks
ago, for instance.

I haven't been able to narrow it down further than a window between Jan 15th and
Feb. 2nd.
I'm experiencing this bug on 2/15 build(Win-2K).
But I couldn't receate this bug on 2/9 build.
(I don't remeber whether I experinced bug during almost a week use of 2/9 build.)

My quick scan for check-ins during 2/9 00:00 to 2/14 23:59 says nexts are
suspectable.
> 2005-02-11 05:18 Bug 281568.
      MSAA events EVENT_MENUEND/EVENT_MENUPOPUPEND fired too late, when dialog
      opens from menu action. Screen readers get confused.
    Changes on next modules, and menuEvent related codes are modified.
      nsMenuBarFrame.cpp , nsBoxFrame.h         , nsBoxFrame.cpp
      nsIMenuFrame.h     , nsRootAccessible.cpp , nsMenuFrame.cpp
> 2005-02-12 12:17 Bug 258102
    Very very big changes (but mainly on mozilla/js/test ...)
WADA: This bug is in the build from Feb 2nd as well as 4th. It would be very
strange if it's not in tbe build from the 9th.

If you wish to test it:
-make sure you install a trunk build
-verify that you  are using the alternate threepane
-click a link in a mail (it womt open in browser)
-then switch folders back/forth between Inbox and Sent 4 times, for instance.
(In reply to comment #8)
> WADA: This bug is in the build from Feb 2nd as well as 4th. It would be very
> strange if it's not in tbe build from the 9th.

>(a) make sure you install a trunk build
>(b) verify that you  are using the alternate threepane
>(c) click a link in a mail (it womt open in browser)
>(d) then switch folders back/forth between Inbox and Sent 4 times, for instance.

I always clear (a),(b) and (d) but not on (c).
Please note that (c) is problem of bug 282594 as you say, and possibly different
from this bug.

I'm experiencing this bug, problem on (d), not on (c), with 2/15 build.
 (1) When click a folder in folder pane, and when(and only when)
     the JavaScript error(mentioned in comment #0) is issued, 
     message pane(thread pane) display is not changed.
     This is not always.
 (2) When the problem occured on a folder,
     clicking another folder works in many cases,
     and when click the folder on which problem occured again,
     the folder is opened successufully in many cases.
 (3) Even when (2) doesn't work, several try of (1) & (2) opens target folder.
And I couldn't recreate problem in my several try of (1) on 2/9 build.

I can not say 2/9 build doesn't have problem (1) because only several try of
problem recreation.
And I'm not sure whether problem (1) occured or not during my 2/9 build use in
the past.
But, as far as I rememeber, I didn't experience problem (1) with build in
Janualy(probably 1/31 build but I'm not sure...).

R.K.Aa.: Which problem, (c) or (d), does occur on 2/1 and 2/4 build? Or both?
(Sorry but I can't recall whether I downloaded/used or not 2/1 build.)
Sorry, coment #0 contained 2 JavaScript error messages.
Next is the message when folder click.
> Error: GetMessagePaneFrame() has no properties
> Source File: chrome://messenger/content/msgMail3PaneWindow.js
> Line: 1144
When clear JavaScript messages then folder click, this error message only is
issued  on JavaScript console. 
Adding suspects to CC
Status: REOPENED → NEW
I could recreate the problem on 2/9 build after 2 hour usage.
I tested 2/9 build yesterday just after restart only.
If just after restart of Mozilla, I couldn't recreate problem even on 2/15.

I could get 2/4 build but I can't still reach to mirror site for 2/1 build or
before.
How can I get older builds?

Same cause as for bug 282877.
also same cause as bug 282593 - GetMessagePaneFrame(), which is really just
window.content, returns null.
(In reply to comment #14)
> also same cause as bug 282593 - GetMessagePaneFrame(), which is really just
> window.content, returns null.

This is bug 282593, did you want to comment to bug 282877 ?

*** Bug 283946 has been marked as a duplicate of this bug. ***
*** Bug 283974 has been marked as a duplicate of this bug. ***
(In reply to comment #0)


R.K.Aa.,

could you please add the words "mail" and "account" to the summary! It does not
have the slightest hint in it's title that a "normal" user would associate with
this behaviour. Otherwise we will see hundreds of duplicates, since this bug
cannot be found when doing a search for one of these words (which I did).
Summary: switching between folders fails: GetMessagePaneFrame() has no properties → switching between mail folders fails: GetMessagePaneFrame() has no properties
https://bugzilla.mozilla.org/show_bug.cgi?id=282877#c7

*** This bug has been marked as a duplicate of 282938 ***
Status: NEW → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
So is this actually fixed in a build with the fix for bug 282938 in it?  
It's fixed. Thank you, Neil.
You need to log in before you can comment on or make changes to this bug.