172392 - Deleting msg in standalone causes loss of selection in 3 pane

Status: RESOLVED WONTFIX

(SeaMonkey :: MailNews: Message Display, defect)

Description

[jglick]

Windows Trunk 2002100108.

1. Open a msg in standalone window.
2. Delete msg in standalone window. Next msg appears in standalone window.
3. Repeat step 2 as desired.
4. Close standalone window.

Results: selection in 3 pane mail window is lost. Nothing is selected.
Expected: msg that was just viewed in standalone should have selection in 3 pane.

4.x parity, plus very disorienting for standalone users. Not clear to user where
they left off reading msgs in thread pane.

This could be related to bug 27417 (When tree item deleted, next item should be
selected (selection should not be destroyed)), but i don't think so. Bug 27417
seems to be fixed in the cases i've tested (deleting cookies, deleting AB cards,
Download manager, Mailing List).

Plus, if you don't open a message in standalone, and just delete msgs in thead
pane, selection works as expected.

Comment 1

[David :Bienvenu]

is this new? It might be a result of a change made to the view code, or the
delete code.

Comment 2

[jglick]

Its not new, been around for quite a while (way before the 'only Del once in
standalone' bug). I was assuming it was being caused by bug 27417, but i've
tested  the original case (cookies) and all the cases of dup'd bugs listed in
27417 and they all seem to be working correctly. So my hunch is this bug is
being caused by something else.

I added myself to 27417 on 2002-04-03, and i noticed it a bit before i started
watching that bug.

Comment 3

[laurel]

I believe there is already a bug about this... 

Comment 4

[scottputterman]

reassigning to ssu

Comment 5

[Sean Su]

Attachment: patch v1.0

Comment 6

[scottputterman]

Is this the same as http://bugzilla.mozilla.org/show_bug.cgi?id=112662. 
Presumably this patch will fix the window title as well?

Comment 7

[Sean Su]

*** Bug 112662 has been marked as a duplicate of this bug. ***

Comment 8

[Sean Su]

*** Bug 62938 has been marked as a duplicate of this bug. ***

Comment 9

[J Luh]

Does the patch work? Is there any chance this patch will make it into Mozilla 1.2?

Comment 10

[(not reading, please use [e-mail] instead)]

I'm not sure this is the right approach.

the 3 panes (and other msg windows) should get notified when a message is
deleted, and they should handle it, instead of a the msg window notifying the
other 3 panes like ssu is doing it.

I'll investigate further.

Comment 11

[(not reading, please use [e-mail] instead)]

looking into this for 1.3 beta.

Comment 12

[(not reading, please use [e-mail] instead)]

Comment on attachment 102390 [details] [diff] [review]
patch v1.0

needs work.

Comment 13

[(not reading, please use [e-mail] instead)]

the patch that I'm working on does this:

we pass around the instigator so that when we get back to
nsMsgDBView::OnKeyDeleted(), if the instigator is not the view, and the delete
key was part of the selection, we handle it.

need to worry about:  {delete, move, cancel} x {imap, news, local} x {search and
normal views}

I have a feeling I'll start small, like getting the basics working for the
common case (delete from the stand alone window horks 3 pane), and then spin off
more bugs for less common cases.

Comment 14

[(not reading, please use [e-mail] instead)]

I'm not 100% sure we should be selecting a new message in the 3 pane in this
scenario.

selecting the next message in the 3 pane would mean loading it (unless the
message pane was collapsed)

think about the scenario where the next message has a return receipt.  doing a
delete in the stand alone msg window could force a switch to the 3 pane, to
prompt you if you wanted to do a return receipt.

also think about the scenario where stand alone msg window loads a message, but
that message isn't in the thread pane.  (say, you double clicked a message from
your inbox, and before you hit delete in the stand alone msg window, you did a
qs or a view change)

also thrown into this mix is the "mark as deleted" imap model.  (But we might be
ok there, as the onkeydelete() should not be called, as a key is not being deleted.)

I'm thinking we should do this:

1)  if one message selected, and that message is deleted out from underneath
you, select nothing and clear the message pane (and title).  it should look the
same as when you first select a folder, but haven't selected a message.

2)  if 2 messages are selected, and a message is deleted out from underneath
you, we load the other message.  (we don't want a state where we have a message
selected, but nothing loaded, right?)

3)  if > 2 messsages are selected, and a message is deleted out from underneath
you, we just update the selection.  (this should already work)

comments?

Comment 15

[(not reading, please use [e-mail] instead)]

> 3)  if > 2 messsages are selected, and a message is deleted out from underneath
> you, we just update the selection.  (this should already work)

this actually doesn't work.

Comment 16

[(not reading, please use [e-mail] instead)]

>> 3)  if > 2 messsages are selected, and a message is deleted out from underneath
>> you, we just update the selection.  (this should already work)
>
> this actually doesn't work.

whoops, it does.  I had just messed up something in my local tree.  (whew!)

Comment 17

[(not reading, please use [e-mail] instead)]

I don't think the instigator thing is necessary for this bug.

I'll attach my change for HandleDeleteOrMoveMsgCompleted() that appears to be
working.

Comment 18

[(not reading, please use [e-mail] instead)]

Attachment: a fix, plus some code cleanup

Comment 19

[(not reading, please use [e-mail] instead)]

note, this fixes the case where the message is deleted from the stand alone msg
window, or the search window.

but the search window still has problems if messages are deleted from another
window.

I'll log another bug on that.

Comment 20

[(not reading, please use [e-mail] instead)]

Attachment: fix, minus the code cleanup

Comment 21

[(not reading, please use [e-mail] instead)]

fixed.  (this had r/sr=bienvenu)

but I'm not claiming 4.x parity.

to summarize the new behaviour:

1)  if one message is selected in the thread pane, and it is deleted from the
stand alone msg window, there will be no message selected in the thread pane
(and the title will look like it does if you don't have any messages selected
and message pane will clear).

2)  if two messages are selected in the thread pane, and one is deleted from the
 stand alone msg window, we will select and load the other one.  (otherwise,
we'd have a selection, but no loaded message).

3)  if > 2 are selected in the thread pane, and one is deleted from the stand
alone msg window, we will just update the selection.

before deciding if #1 and #2 are correct, take into account QS and mail views
(which we didn't have in 4.x)

I have an issue with #2, to discuss if we should clear selection in this case.
I've spun that off to bug #185146

I've spun off the related search window bug to bug #185147

marking as fixed.

Comment 22

[Thomas Winzig]

There might be a regression here... at least the bug I am seeing seems related
to the fix detailed here...

I am using yesterday's build, #2002122208 of Mozilla 1.3a. 

I am using the three-pane view on an IMAP account. When I delete a highlighted
message by pressing the delete key, no message is selected. (Previously the next
message would be selected.) So now if I want to read my email, I have to delete
the message, then use the arrow down key to select the next message, etc. 

This could be related to bug 183394.

For the settings on this account, I have the following:

"When I delete a message: Remove it immediately."

If I change that setting to "mark it as deleted," then when I press delete, it
marks it as deleted and moves to the next message as expected.

Comment 23

[jglick]

I'm still seeing the orginal problem.

1. 3 Pane Mail. Preview Pane is closed.
2. Double click a msg to open it in Standalone.
3. Click Delete in standalone. Message deleted and next msg is displayed in open
standalone window.
4. Close standalone window.

Results: Nothing in Thread pane has focus.
Expected: Msg that was just closed from standalone should have focus. Match 4.x
behavior.

Comment 24

[grylchan]

hey Jennifer,
Based on Seth's comments in comment 21
he intended this behavior even though your original bug
was about this problem.

>1)  if one message is selected in the thread pane, and it is deleted from the
>stand alone msg window, there will be no message selected in the thread pane
>(and the title will look like it does if you don't have any messages selected
>and message pane will clear).

Comment 25

[jglick]

Hey Seth. Let's talk ;-)

3 Pane mail window. Preview Pane collapsed.
1. Select a msg.
2. Click Delete
Results: Msg deleted. Next msg is selected.

3 Pane mail window. Preview Pane open.
1. Select a msg. It loads in preview pane.
2. Click Delete
Result: Msg deleted. Next msg selected and loaded in 3 pane.

I think standalone should work the same. If a msg in standalone is deleted, the
next msg in thread pane should be selected (in the thread pane) and displayed in
standalone.

Comment 26

[(not reading, please use [e-mail] instead)]

accepting.  I must have mis-understood.

Comment 27

[[e-mail]]

Wasn't there some issue with loading the same message in two panes
simultaneously? (fix was not to call NotifyFolderEvent twice)
But you could ensure that the current message (dotted outline) kept track.

Comment 28

[[e-mail]]

Some more issues:
1. Context-deleting scrolls the selected message back into view
2. When deleting from two 3-pane windows at once, open on different folders,
possibly only one updates the selection?
(I haven't reproduced this, because normally my server is fast enough...)

Comment 29

[(not reading, please use [e-mail] instead)]

sliding to 1.4 alpha

Comment 30

[Rafael Ebron (:rebron)]

adt: nsbeta1-

Comment 31

[Mike Cowperthwaite]

Another, possibly related issue, is bug 161999 comment 96: when a message in the 
trash is viewed in the 3-pane, and then Empty Trash is selected, the focus 
(actually, the tree's selection) is removed -- that is, neither the trash folder 
nor any other tree node is selected, but using arrow keys you can select the 
nodes as expected.  (If that's not related to this, maybe it should be its own 
bug.)

Comment 32

[Mike Cowperthwaite]

*** Bug 219315 has been marked as a duplicate of this bug. ***

Comment 33

[Wayne Mery (:wsmwk)]

dup of or dependent on Bug 268098 ?

Comment 34

[Mike Cowperthwaite]

I think comment 14 was entirely on-track: the behavior described in this bug should be the expected behavior.  Once the standalone is open, the 3pane's selection is almost entirely independent; if you're navigating from the standalone using the F/N/B/P keys, there is no change in the selection either. (Altho you do see unread messages changing to read as they are loaded in the standalone.)  In fact, if you change the sorting order in the 3pane, and then type F repeatedly thru the standalone, you'll find yourself moving thru the original sort order -- essentially, the standalone has a virtual, invisible thread pane of its own.

Recommend WontFix.

This behavior is actually Backend, isn't it?  TB does the same.


(In reply to comment #33)
> dup of or dependent on Bug 268098 ? 

No, that's a different issue.

Comment 35

[djk]

(In reply to comment #34)
> Once the standalone is open, the 3pane's
> selection is almost entirely independent; if you're navigating from the
> standalone using the F/N/B/P keys, there is no change in the selection either.

I think that's what the bug is about.  The selection in 3pane does not follow what's in the standalone window.


> (Altho you do see unread messages changing to read as they are loaded in the
> standalone.)

Which is kinda inconsistant.  There is a 'link' from standalone to the 3pane WRT marking messages read, why not have the selection be 'linked' also?

> ...essentially, the standalone has a virtual, invisible
> thread pane of its own.

Aack!  Virtual, invisible stuff should not happen with the UI, IMHO.

David

Comment 36

[Magnus Melin [:mkmelin]]

I'd support wontfix...

Comment 37

[Karsten Düsterloh]

It's possible (and probably even likely) to have multiple standalone message windows open - which one should be relevant for updating the main mail window?
You can even have multiple main mail windows, all with different folder than those whose messages are shown in the standalone windows...
The (invisible) selection used by the standalone window is entirely independent of  the main mail window selection.
-> WONTFIX