Closed
Bug 120189
Opened 23 years ago
Closed 23 years ago
Make sure nsOutlinerContentView::AttributeChanged() won't die in a recursive loop
Categories
(Core :: XUL, defect, P3)
Tracking
()
RESOLVED
FIXED
mozilla0.9.9
People
(Reporter: janv, Assigned: bryner)
References
Details
Attachments
(1 file, 1 obsolete file)
37.17 KB,
patch
|
janv
:
review+
jag+mozilla
:
superreview+
|
Details | Diff | Splinter Review |
<bryner> Jan: um, so, i think removing mIgnoreOptionSelected will cause problems
<Jan> bryner: I thought that there are used 2 different attributes
<bryner> oh, right
<bryner> nevermind
<bryner> :)
<bryner> er
<bryner> no, i think it will cause a problem
<bryner> here's why
<bryner> if an option is selected via script, the optionSelectedPseudo attribute
gets set
<bryner> that causes us to call into the outliner selection to toggle the
selected state...
<bryner> which then calls back into the content view to update state on the
SelectElement
<bryner> which then resets the optionSelectedPseudo attribute
<bryner> and around and around we go
<Jan> bryner: I'll file a new bug on me to investigate this case, I can't test
it again with all outliners :(
<bryner> it will only affect xbl select widgets
<Jan> yeah I know
<bryner> Jan: i sort of need those to work :)
<bryner> this would be solved by moving the select element update into the xbl
event handlers like one of your patches did
<bryner> it seems like there was a problem with that, and i can't remember what
it was
<Jan> yes!
<Jan> move it, move it
so maybe we just eliminate all callback notifications in C++
by moving them to XBL
Reporter | ||
Updated•23 years ago
|
OS: Linux → All
Priority: -- → P3
Summary: Make sure nsOutlinerContentView::AttributeChanged() doesn't die in recursive loop → Make sure nsOutlinerContentView::AttributeChanged() won't die in a recursive loop
Target Milestone: --- → mozilla0.9.9
Comment 1•23 years ago
|
||
*** Bug 120190 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 2•23 years ago
|
||
Jan, can you please r= this? I moved all of the content node state setting
into the event handlers and reverted the changes to OutlinerContentView and
OutlinerSelection to do that.
Reporter | ||
Comment 4•23 years ago
|
||
Comment on attachment 65529 [details] [diff] [review]
patch
this is so cool, nice work bryner
r=varga
Attachment #65529 -
Flags: review+
Comment 5•23 years ago
|
||
Comment on attachment 65529 [details] [diff] [review]
patch
sr=jag
I like it, ship it!
Attachment #65529 -
Flags: superreview+
Assignee | ||
Comment 6•23 years ago
|
||
Comment on attachment 65529 [details] [diff] [review]
patch
Hm, this doesn't quite work because of the attribute changed notification.
Working on it.
Attachment #65529 -
Flags: needs-work+
Assignee | ||
Comment 7•23 years ago
|
||
Here's a new patch. Basically the same as the old one, but I added a notify
parameter to SetOptionsSelectedByIndex, which we set to false when we call this
from the event handler. This prevents the duplicate notification.
Attachment #65529 -
Attachment is obsolete: true
Reporter | ||
Comment 8•23 years ago
|
||
Comment on attachment 65590 [details] [diff] [review]
patch v2.0
r=varga
Attachment #65590 -
Flags: review+
Comment 9•23 years ago
|
||
Comment on attachment 65590 [details] [diff] [review]
patch v2.0
sr=jag
Attachment #65590 -
Flags: superreview+
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 10•23 years ago
|
||
checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in
before you can comment on or make changes to this bug.
Description
•