Closed Bug 711204 Opened 13 years ago Closed 4 years ago

While viewing mail from list, delete email, next opens, then closes instantly

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Version:
10 Branch
Platform:
x86_64
Windows 10
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: dmccammishjr, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2

Steps to reproduce:

Reading mail from Inbox, delete message, next message flashes open, then closes.  Still shows unread.   Normally, next message opens and stays open.   


Actual results:

See above


Expected results:

See above.   Next message should have stayed open.
(In reply to doug2 from comment #0)
Try doing this with addons disabled. Start Thunderbird in safe-mode and check: http://kb.mozillazine.org/Safe_Mode
Well, I am running Earlybird which doesn't have any compatible add-ons at the moment, but I did switch to safe mode and can't recreate the problem now.  I tried setting several email (SMTP) to unread and then read through them (F-key) with no problems.  I will keep trying to recreate and maybe try T-bird in safe mode also.
I didn't see this for a while in Earlybird, but am now seeing it again. Seems to be view 1st unread, delete or next, next pops up, closes immediately, still marked unread.  (my settings call for mark read immediately)   I thought maybe folder compression was involved (had set to ask), but now set to don't ask and still happens.   Tried running EB in safe mode and recreating by marking several unread, then reading through them and then deleting one, but not able to recreate so far.
Doug2 : nothing in the Error console when you see the issue ?
Over the last several days, this bug happens 1st thing every morning on the 1st email I open.  It has become a lot more consistent.
Error console: 
 2/15 7:22:49 Empty string passed to getElementByld().
 2/15 7:22:50 Use of getAttributeNodeNS() is depreciated.  Use getAttributeNS() instead.

I can provide .xul files

Also:  Unknown property 'box-sizing'... 'transition' 'transform' 'transition'...

I'll see if I can make it happen and check error console more quickly.
Re-created with new mail on Earlybird startup.  1st unread open, delete - immediately opens next and closes.
Error console Error "this.folderDisplay.view.dbView is null"

Cursor was in "this.folderDisplay.view.dbView.rowCount == 0) {" code below.

code snippet
  onSelectedMessagesChanged: function () {
    // If the message we're displaying is deleted, we won't have any selection
    // for a while, but we'll soon select a new message. So don't test the
    // selection count -- instead see if there are any messages in the db view
    // at all.
    if (!this.aboutToLoadMessage &&
        this.folderDisplay.view.dbView.rowCount == 0) {
      window.close();
      return true;
    }
    return false;
  },
Re-created with new mail again.  same response.
Same Error in console.  same cursor position in code above.
This problem persists in Earlybird 13.0a2
Noticed that the problem "appears" to go away when filters turned off.
There are some known issues in mail display at Tab/Stand alone window, in thread pane display, when auto-compact is invoked and compact is executed, and if local mail folder and offset of currently shown mail is changed by Compact, some other issues may occur. For example, bug 479064, bug 520115, bug 525227.

Local mail folder? (POP3, Local Folders) Or IMAP folder?

Do you enable auto-compact?
If yes, what do you set in mail.purge.ask? (Tools/Options/Advanced/General, Confid Editor)
If false, change to mail.purge.ask=true and restart Tb(restart of Tb is mandatory). By true, prompt is shown before start of auto-compact.

Does your problem occur even when "Cancel" is replied at the prompt?
Do you see your problem even when the prompt is not shown after delete mail?
Options, Compact .. when it will save over .. is unchecked, but I may have unchecked it after having the problems.  I have changed mail.purge.ask to true.

There were so many seemingly interrelated problems that I don't know where to begin.
- second message open and then immediately close (may have been filter related)
- messages duplicated in compaction, and moved to strange places
- messages totally disappearing (not sent to trash or any other folder) on 3/26 & 3/27.  
I have gone back to released TBird, but have set the account to leave mail on server so I could go back to EB and try again.
Now that the compaction problems seem to be resolved, this issue has changed. I have auto-compaction turned on, but with ask-first.  With a list of unread, open first (oldest) unread, then delete, then 2nd unread appears, then "do you want to compact" pops up and 2nd unread is closed (still marked unread).  
Once compaction is complete (i.e., rule about saving space has been satisfied), try sequence again, auto-compaction rule is false, 2nd unread stays open.  
So, it appears the logic is that, if the compaction rule is true, pop up the question dialog ("do you want to compact") and close the open mail window leaving the mail marked unread. ????   (unread mark time option is set to immediate)
Ask before compact question no longer applies?
Note that I'm using SMTP.  
The problem persists in 41.0 beta.
Running beta 42.0  bug still exists.  Using auto compact.  problem occurs after 1st delete of mail in inbox.
Blocks: 498274
See Also: → 520115
Whiteboard: [dupme]
beta 52.0b1 worse. Previous beta did not seem to have this problem.
OS: Windows 7 → Windows 10
can you test and propose a patch?
Flags: needinfo?(dmccammishjr)
I just tested using 52.2.1 32 bit in both normal and safe mode and I don't see the problem.  It has happened recently, so I'm not sure what has changed in the last few days, if anything.  I'm currently running on the release track. 
Running Windows 10 64 bit.  
If you need me to switch tracks, let me know.
Flags: needinfo?(dmccammishjr)
Running on 56.0.b2 32 bit on beta channel at the moment.  I have been testing for the open/close problem with several mail streams and do not see it.  I did have some similar problems at initial startup of this beta (at least one full crash which was reported), but the beta seems stable now??  
All this is running with SMTP and POP on Windows 10 64 bit.
OK, I'm here now. So I guess you're using: Open messages in: A new message window. Or is it an existing message window? Both options exist.
New message window, sorry.
OK, I've changed my setup to open messages in a new window now. The problem is that I hardly ever open a message, I read them in the preview pane. And the ones I do open are important, so I will never delete them as I usually keep all my mail, apart from junk, and that stuff I don't open.

So what exactly is the bug? You open a message. It opens in a new window. You delete the open message, how? Clicking on the delete button? Hitting the "Delete" key? And then what happens? The window closes and a new one opens and closes straight away? Or the next message shows briefly in the window that contained the message you deleted, and then the original window closes?

I need to know what to look for.
Sorry.  Apparently I sleep and you don't. 
Not sure that delete has anything to do with it. It happens often to me, but only once in a "session" - that is, I begin to read mail. I either delete a mail (key or icon) or move forward to a new piece of mail and the window opens and then disappears. I will try to make it happen today and watch my steps more carefully.
Been trying to make it happen or catch it all day. Nothing. I think the sequence is: open a piece of mail, delete it, the next new window opens, flashes closed, stays closed, but is marked read.  I will keep trying to catch it.
Meanwhile, no crashes all day.  23 new Inbox messages read, plus 10 in another folder.
Not able to make it happen. Have tried new mail. Have tried marking mail unread and then going through steps. Have tried copying unread mail from another folder into inbox.  Have tried both Delete Key and Delete button.  
Any possibility that this and bug 1368786 are related? Junk left by 1368786 coming into play?  
I'll keep watching. Forget this one and work on real problems until I can get a sequence.
Still not able to make it happen. Ran this AM about half way through new mail with the test build from 1368786 with no problem, then downloaded the "official" daily and opened all the others.  This morning mail review is when I usually have this problem. My call would be to set this aside until I see it happening often and can better document the sequence & circumstances.
Went back to 56.0b3 to try to make this happen. Reading new mail. Hit delete "button" (not key) and mail I was reading (last in unread in InBox) was deleted.  Last read message flashed and then went away.  I am convinced (with little evidence) that this was fixed somehow in the last daily since I've been watching it carefully for 36 hour with no failure until I switched to the beta.
Happens consistently in 57.0b1 after new mail received (POP) and open first or second unread.  After it happens once, can read rest of new mail with no problem.
Consistenly after 1st delete.  If read new mail and (F) move to next new, no problem.  However, if delete a mail, next mail appears and closes almost immediately, then shows as "read."  Reminder - Win 10, beta 57.0b1, Pop mail open in new window.
Running 58.0b2.  Win 10 with latest updates.  Symptoms more frequent than with 57.0b1.
This is bug 520115
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Whiteboard: [dupme]
Seeing some recurrences of this or very similar in 59.0b2 (windows 10, pop mail, using mail windows).  Now and then, reading mail (new or old), mail window opens, then closes.  No action on my part to close.
Now running Tbird 60.0b1 and seeing this bug more often than with previous beta.
Continues to be an issue in 60.0b2
Why is this a dupe of 520115. What does this have to do with compacting. New report just in: Bug 1510783.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
See Also: → 1510783

(In reply to Jorg K (GMT+1) from comment #33)

Why is this a dupe of bug 520115 (windows closed after compact). What does this have to do with compacting. New
report just in: Bug 1510783.

But since closed.

So the bottom line of comment 11, in short form, is this bug is NOT compact related?

And is mail.close_message_window.on_delete at the default value of false? Or was it changed to true?

Flags: needinfo?(dmccammishjr)

I am seeing this in the current beta 65.0b2 Seemed to have gone away for some time, but reappeared in the last two betas (which came close together). Don't know what other info I can give you.
Interestingly, I have not yet seen the Gloda problem in this beta after a couple of days, but have not pressure-tested it. I'll try to run regression on this build tomorrow for the Gloda problem.

Flags: needinfo?(dmccammishjr)

"And is mail.close_message_window.on_delete at the default value of false? Or was it changed to true?" I have not changed any settings and the problem is not consistent so doubt that it is related to some setting. It might happen on the first or second mail read in a series, but then not again in that session. (That is, read, delete, read next, mail window closes, mail item just previously opened is marked read, but not deleted. Open mail, read, delete or move to next for several mail items with no problem.) Since it happens when the system has been "waked up," and thus MIGHT be compacting, then it MIGHT be related.

Using Mozregression gui, I tested 2019-01-10, 2019-01-13 this morning and was not able to make either of them go into the Gloda loop. Both daily builds (66.0a1) DID encounter Gloda errors when compacting, but did not go into an endless loop.
I don't know the build number for 65.0b3, but I have not seen it fail (endless loop of Gloda errors) in normal use.

(In reply to doug2 from comment #37)

Using Mozregression gui, I tested 2019-01-10, 2019-01-13 this morning and was not able to make either of them go into the Gloda loop. Both daily builds (66.0a1) DID encounter Gloda errors when compacting, but did not go into an endless loop.
I don't know the build number for 65.0b3, but I have not seen it fail (endless loop of Gloda errors) in normal use.

Does it also fail to reproduce when using 67.0b1? (just out)

Flags: needinfo?(dmccammishjr)

Don't know build date for 67.0b1, but tested build 2019-03-31 and DID see Gloda infinite loop errors on compact. Have NOT seen Gloda issue in daily use of 67.0b1 (2 days use). Will try to find time later today to run bisection on late March builds.

Flags: needinfo?(dmccammishjr)

Gloda running away in 67.0b1 after waking up machine. Appears that "waking up" causes compaction and then Gloda went crazy.

The "wake-up" compaction in 67.0b1 is driving me nuts! It stops use of TBird for at least 30 seconds on my laptop with my settings. If it is "preventive measure" for this bug, it isn't working as such.

This bug is "active" in 69.0b4 on Win10 with mail opened in windows (not tabs). Again, it seemed "dormant" for a while, but now occurs whenever the mail list window has been minimized or quiet for a while. No indication that it is compaction related. Don't see an obvious way to recreate it in mozregression or otherwise capture data. (Not seeing the "wake-up" compaction time noted in comment 41, however.)

Converted to 64 bit 73.0b2 to see if this problem persists - it does. Also, replaced mechanical disk with semiconductor SDD drive. No difference. Symptom continues to be (on this machine!) after any "rest" of TBird (e.g., first use in AM or after any period not using for an hour) the first deleted email triggers closing any open window. I will try tabs (vs. separate windows) to see if any difference.

See Also: → 944194

from bug 561272 comment 32 ... I believe bug 711204 is also resolved "coincidentally?" in Daily. I have hesitated to close it but have not seen that strange closing window action in a while (which I believe is related to a compaction happening when I first open TBird after a "nap").

Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago → 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.