Closed
Bug 21945
Opened 25 years ago
Closed 25 years ago
Select elements don't remember their current selection when the frame is deleted
Categories
(Core :: XUL, defect, P3)
Tracking
()
VERIFIED
FIXED
M14
People
(Reporter: bugzilla, Assigned: rods)
References
Details
(Whiteboard: [PDT+])
Attachments
(2 files)
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:"
Assignee | ||
Updated•25 years ago
|
Target Milestone: M14
Assignee | ||
Comment 2•25 years ago
|
||
updated milestone
Assignee | ||
Comment 3•25 years ago
|
||
moving to M15
Reporter | ||
Updated•25 years ago
|
Whiteboard: [DOGFOOD]
Reporter | ||
Comment 5•25 years ago
|
||
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+
Assignee | ||
Comment 6•25 years ago
|
||
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()
Assignee | ||
Updated•25 years ago
|
Assignee: rods → hyatt
Assignee | ||
Comment 7•25 years ago
|
||
Hyatt, I heard you were working on this, and therefore this may be a duplicate.
Comment 8•25 years ago
|
||
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?
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 9•25 years ago
|
||
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.
Assignee: hyatt → rods
Status: ASSIGNED → NEW
Comment 10•25 years ago
|
||
Gimme a call tomorrow if you want a more articulate rundown.
Comment 11•25 years ago
|
||
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.
Keywords: beta1
Assignee | ||
Comment 12•25 years ago
|
||
setting milestone to M14 adding dependencies, I have a fix in my tree that needs
to be tested.
Comment 13•25 years ago
|
||
Putting on PDT+ radar for beta1.
Keywords: dogfood
Whiteboard: [DOGFOOD] → [PDT+]
Assignee | ||
Comment 14•25 years ago
|
||
Assignee | ||
Comment 15•25 years ago
|
||
Ignore the "Set" pushbuttons in the testcase. But the "hide" "show" work.
fix is in my tree
Whiteboard: [PDT+] → [PDT+]fix in my tree
Assignee | ||
Comment 16•25 years ago
|
||
Reporter | ||
Comment 17•25 years ago
|
||
*** Bug 27085 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 18•25 years ago
|
||
updated status whiteboard
Whiteboard: [PDT+]fix in my tree → [PDT+]fix in my tree, checkin is being reviewed
Assignee | ||
Comment 19•25 years ago
|
||
Fixed, it should all work now
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 21•25 years ago
|
||
Laurel - pls verify for just the mail cases. thanks.
QA Contact: lchiang → laurel
Comment 22•25 years ago
|
||
Cannot really verify until 26618, 25103 are fixed.
Whiteboard: [PDT+]fix in my tree, checkin is being reviewed → [PDT+]mail verification pending 26618 fix.
Comment 23•25 years ago
|
||
OK, now that #26618 and #25103 are fixed, I can't verify this until bug #28856
(no scrollbar in address block) is fixed.
Whiteboard: [PDT+]mail verification pending 26618 fix. → [PDT+] feb23: mail verification pending 28856 fix
Comment 24•25 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [PDT+] feb23: mail verification pending 28856 fix → [PDT+]
Comment 25•25 years ago
|
||
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•25 years ago
|
||
I'm reopening bug #18685.
I've logged my last issue as new bug #32119.
I'll close this one as verified.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 28•25 years ago
|
||
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)
You need to log in
before you can comment on or make changes to this bug.
Description
•