21945 - Select elements don't remember their current selection when the frame is deleted

Status: VERIFIED FIXED

(Core :: XUL, defect, P3)

Description

[Jean-Francois Ducarroz]

It's the same case than for input element that waterson fixed few days ago.

Case 1, during a tree scroll:
1) Open a new message compose
2) Change the select value of the first recipient to "Cc:"
3) Type "A" + <enter> into the first recipient --> a new row appears
4) Type "B" + <enter> into second recipient
5) Type "C" + <enter> into third recipient
6) Now, scroll one row up and then down
7) --> the first row should be visible again but notice that the select element
doesn't say "Cc:" anymore but "To:"

Case 2, during a toolbar collapse/expand:
1) Open a new message compose
2) Change the select value of the first recipient to "Cc:"
3) Collapse and then expand back the addressing toolbar
4) --> the select element say now "To:" instead of "Cc:"

Comment 1

[Jean-Francois Ducarroz]

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

Comment 2

[rods (gone)]

updated milestone

Comment 3

[rods (gone)]

moving to M15

Comment 4

[Jean-Francois Ducarroz]

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

Comment 5

[Jean-Francois Ducarroz]

MsgComposition need this bug be fixed before beta as the fact that the value of the recipient type dropdown list (to,
cc, bcc, etc.) is lost when you address a message to more that 3 recipients. Mark it as dogfood in the hope it will
obtain a PTD+

Comment 6

[rods (gone)]

It appears that some container frame who is destroying and creating frames
should be using the nsIStateful interface to save off the frame states and
restore them. Here is the stack when the combobox deleted:

nsComboboxControlFrame::~nsComboboxControlFrame() line 122
nsComboboxControlFrame::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsFrame::Destroy(nsFrame * const 0x0120421c, nsIPresContext * 0x01f9e9a0) line
407 + 34 bytes
nsContainerFrame::Destroy(nsContainerFrame * const 0x0120421c, nsIPresContext *
0x01f9e9a0) line 98
nsBlockFrame::Destroy(nsBlockFrame * const 0x0120421c, nsIPresContext *
0x01f9e9a0) line 1160
nsAreaFrame::Destroy(nsAreaFrame * const 0x0120421c, nsIPresContext *
0x01f9e9a0) line 70
nsComboboxControlFrame::Destroy(nsComboboxControlFrame * const 0x0120421c,
nsIPresContext * 0x01f9e9a0) line 1315
nsLineBox::DeleteLineList(nsIPresContext * 0x01f9e9a0, nsLineBox * 0x0292a560)
line 234
nsBlockFrame::Destroy(nsBlockFrame * const 0x023afec4, nsIPresContext *
0x01f9e9a0) line 1157 + 16 bytes
nsFrameList::DestroyFrames(nsIPresContext * 0x01f9e9a0) line 35
nsContainerFrame::Destroy(nsContainerFrame * const 0x01204168, nsIPresContext *
0x01f9e9a0) line 97
nsTreeCellFrame::Destroy(nsTreeCellFrame * const 0x01204168, nsIPresContext *
0x01f9e9a0) line 465
nsFrameList::DestroyFrames(nsIPresContext * 0x01f9e9a0) line 35
nsContainerFrame::Destroy(nsContainerFrame * const 0x01204108, nsIPresContext *
0x01f9e9a0) line 97
nsFrameList::DestroyFrame(nsIPresContext * 0x01f9e9a0, nsIFrame * 0x01204108)
line 121
nsTreeRowGroupFrame::DestroyRows(nsTableFrame * 0x011f43e0, nsIPresContext *
0x01f9e9a0, int & 0) line 231
nsTreeRowGroupFrame::DestroyRows(nsTableFrame * 0x011f43e0, nsIPresContext *
0x01f9e9a0, int & 0) line 219
nsTreeRowGroupFrame::PositionChanged(nsTreeRowGroupFrame * const 0x011f468c,
nsIPresContext * 0x01f9e9a0, int 0, int 1) line 723
nsSliderFrame::CurrentPositionChanged(nsIPresContext * 0x01f9e9a0) line 665
nsSliderFrame::AttributeChanged(nsSliderFrame * const 0x023e8820, nsIPresContext
* 0x01f9e9a0, nsIContent * 0x02881d80, int 0, nsIAtom * 0x01a41b30 {"curpos"},
int 2) line 198 + 18 bytes
nsScrollbarFrame::AttributeChanged(nsScrollbarFrame * const 0x023e86b4,
nsIPresContext * 0x01f9e9a0, nsIContent * 0x02881d80, int 0, nsIAtom *
0x01a41b30 {"curpos"}, int 2) line 365
nsCSSFrameConstructor::AttributeChanged(nsCSSFrameConstructor * const
0x01f9c130, nsIPresContext * 0x01f9e9a0, nsIContent * 0x02881d80, int 0, nsIAtom
* 0x01a41b30 {"curpos"}, int 2) line 7618 + 35 bytes
StyleSetImpl::AttributeChanged(StyleSetImpl * const 0x01f9f640, nsIPresContext *
0x01f9e9a0, nsIContent * 0x02881d80, int 0, nsIAtom * 0x01a41b30 {"curpos"}, int
-1) line 996
PresShell::AttributeChanged(PresShell * const 0x01f98418, nsIDocument *
0x01f98ba0, nsIContent * 0x02881d80, int 0, nsIAtom * 0x01a41b30 {"curpos"}, int
-1) line 2363 + 57 bytes
nsXULDocument::AttributeChanged(nsXULDocument * const 0x01f98ba0, nsIContent *
0x02881d80, int 0, nsIAtom * 0x01a41b30 {"curpos"}, int -1) line 1388
nsXULElement::SetAttribute(nsXULElement * const 0x02881d80, int 0, nsIAtom *
0x01a41b30 {"curpos"}, const nsString & {"1"}, int 1) line 2250
nsScrollbarButtonFrame::MouseClicked() line 172 + 70 bytes
nsScrollbarButtonFrame::MouseClicked(nsIPresContext * 0x01f9e9a0) line 125
nsTitledButtonFrame::HandleEvent(nsTitledButtonFrame * const 0x023dd15c,
nsIPresContext * 0x01f9e9a0, nsGUIEvent * 0x0012f768, nsEventStatus *
0x0012fa74) line 1196
nsScrollbarButtonFrame::HandleEvent(nsScrollbarButtonFrame * const 0x023dd15c,
nsIPresContext * 0x01f9e9a0, nsGUIEvent * 0x0012f768, nsEventStatus *
0x0012fa74) line 94
nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const
0x0234aeb0, nsIPresContext * 0x01f9e9a0, nsMouseEvent * 0x0012fb68,
nsEventStatus * 0x0012fa74) line 1366 + 30 bytes
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x0234aeb0,
nsIPresContext * 0x01f9e9a0, nsGUIEvent * 0x0012fb68, nsIFrame * 0x023dd15c,
nsEventStatus * 0x0012fa74, nsIView * 0x028816f0) line 551 + 24 bytes
PresShell::HandleEvent(PresShell * const 0x01f98414, nsIView * 0x028816f0,
nsGUIEvent * 0x0012fb68, nsEventStatus * 0x0012fa74) line 2742 + 43 bytes
nsView::HandleEvent(nsView * const 0x028816f0, nsGUIEvent * 0x0012fb68, unsigned
int 8, nsEventStatus * 0x0012fa74, int & 0) line 841
nsView::HandleEvent(nsView * const 0x023620c0, nsGUIEvent * 0x0012fb68, unsigned
int 8, nsEventStatus * 0x0012fa74, int & 0) line 826
nsView::HandleEvent(nsView * const 0x01f9f730, nsGUIEvent * 0x0012fb68, unsigned
int 28, nsEventStatus * 0x0012fa74, int & 0) line 826
nsViewManager::DispatchEvent(nsViewManager * const 0x01f9aa50, nsGUIEvent *
0x0012fb68, nsEventStatus * 0x0012fa74) line 1678
HandleEvent(nsGUIEvent * 0x0012fb68) line 69
nsWindow::DispatchEvent(nsWindow * const 0x01f9c1d4, nsGUIEvent * 0x0012fb68,
nsEventStatus & nsEventStatus_eIgnore) line 502 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fb68) line 523
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000 {x=???
y=???}) line 3438 + 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000 {x=???
y=???}) line 3656
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 9896275, long *
0x0012fdc8) line 2728 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x078405a0, unsigned int 514, unsigned int 0, long
9896275) line 689 + 27 bytes
USER32! 77e71820()

Comment 7

[rods (gone)]

Hyatt, I heard you were working on this, and therefore this may be a duplicate.

Comment 8

[David Hyatt]

Assuming you are saving your state off like you're supposed to, then this would
be a dup of a bug I already have.  Is that piece done?

Comment 9

[David Hyatt]

rods, looks like this one's coming back to you now.

It looks like, for comboboxes only, at the time that the state is restored, 
mListControlFrame is null.  Probably hasn't even been built yet.  So your 
restore state function bails without ever restoring the state.  

What you can do is pull the state out and hold onto it until you get the list 
built.  The state is an nsIPresState object, and you can retrieve an 
nsISupportsArray of your selected objects from it.  Whenever the list box gets 
built within the combo box, you should be able to restore selection from that 
array.

Comment 10

[David Hyatt]

Gimme a call tomorrow if you want a more articulate rundown.

Comment 11

[Phil Peterson]

Nominate for beta1 due to dependency on the addressing widget in the message 
composition window. Would like to see this fixed in M14 rather than M15.

Comment 12

[rods (gone)]

setting milestone to M14 adding dependencies, I have a fix in my tree that needs 
to be tested.

Comment 13

[leger]

Putting on PDT+ radar for beta1.

Comment 14

[rods (gone)]

Attachment: testcase for selects

Comment 15

[rods (gone)]

Ignore the "Set" pushbuttons in the testcase. But the "hide" "show" work.

fix is in my tree

Comment 16

[rods (gone)]

Attachment: A better testcase

Comment 17

[Jean-Francois Ducarroz]

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

Comment 18

[rods (gone)]

updated status whiteboard

Comment 19

[rods (gone)]

Fixed, it should all work now

Comment 20

[Paul MacQuiddy]

handing off to lchiang to verify in mail

Comment 21

[lchiang]

Laurel - pls verify for just the mail cases.  thanks.

Comment 22

[laurel]

Cannot really verify until 26618, 25103 are fixed.

Comment 23

[laurel]

OK, now that #26618 and #25103 are fixed, I can't verify this until bug #28856
(no scrollbar in address block) is fixed.

Comment 24

[laurel]

I'm reopening this based on use with mar15 beta builds (NT and Mac, haven't done
unix yet).  Here's the deal:

Good: 
Within the compose window as in this bug's Case 1 and Case 2, all is fine. 
While still in a new message compose window, the headers remain the same when
scrolling.  As this particular bug was originally described is okay in current
beta1 builds.

Bad:  bug #18685 is marked duplicate of this and that condition still exists as
it is written -- one message sent to 4 recipients all with To: headers will
display as a message with 4 To: recipients, but will change headers when a Reply
All is done to that message.

Bad, really bad:  A message sent with multiple recipients on each type of header
will often turn into other headers when message is received.  The worst cases of
this which I've seen are that Bcc: addressees wind up in the To: header list
(augh!) and newsgroup addressees wind up as To: headers and so the news posting
never makes it.

Based on the duplicate bug condition from #18685, I'm reopening this since it
was all linked. 

I believe the last open issue I raised is important in that there is data loss
in the newsgroup case and privacy loss in the Bcc: case.

I also believe we may be better served to separate the two lingering issues (and
I'll provide much more detailed steps for the last issue), unlink them from this
bug, but I'll let someone in development make that call.  

Comment 25

[Jim Roskind]

Please break this into individual bugs.  The descriptions seem different from
the original bug... so I think it might be good to close this one, and open
fresh ones.
The bug that "bcc: can transition to to: in addressing" seems very bad!
I *think* this hit me today (extra entries on the "BCC" line got moved to the
end of the "TO" line :-(.

Comment 26

[laurel]

I'm reopening bug #18685.
I've logged my last issue as new bug #32119.
I'll close this one as verified.

Comment 27

[laurel]

Verified in mar15 beta commercial builds.

Comment 28

[rods (gone)]

I did a bunch of testing and I am not convinced it is an issue with PresState. I 
need someone to describe the exact steps I need to re-create the problem(s)