Closed
Bug 221288
Opened 21 years ago
Closed 21 years ago
XUL tree builder abuses tree batching
Categories
(Core :: XUL, defect)
Core
XUL
Tracking
()
RESOLVED
FIXED
People
(Reporter: neil, Assigned: janv)
Details
Attachments
(2 files)
564 bytes,
patch
|
alecf
:
superreview+
|
Details | Diff | Splinter Review |
790 bytes,
patch
|
janv
:
review+
alecf
:
superreview+
|
Details | Diff | Splinter Review |
The XUL template builder starts a batch, discards its existing content, creates new content, notifies the frame of the new content, and ends the batch. Unfortunately since the frame is not notified that the existing content was discarded it is unable to correctly update the selection. The template builder could either send the correct notification, or simply clear its selection directly, since that would have the same effect. Steps to reproduce problem: 1. Open History 2. Group by Day 3. Group by None By this time the current row will be some unrealistically large number.
Reporter | ||
Comment 1•21 years ago
|
||
Reporter | ||
Updated•21 years ago
|
Attachment #132728 -
Flags: superreview?(alecf)
Attachment #132728 -
Flags: review?(varga)
Assignee | ||
Comment 2•21 years ago
|
||
I think this would be more correct: PRInt32 count = mRows.Count(); mRows.Clear(); mConflictSet.Clear(); if (mBoxObject) { mBoxObject->BeginUpdateBatch(); mBoxObject->RowCountChanged(0, -count); }
Reporter | ||
Comment 3•21 years ago
|
||
As if it makes any difference to the tree...
Assignee | ||
Comment 4•21 years ago
|
||
Comment on attachment 132730 [details] [diff] [review] Jan's approach r=varga yes, it makes sense, since RowCountChanged() expects that rows are really cleared in this case
Attachment #132730 -
Flags: review+
Reporter | ||
Comment 5•21 years ago
|
||
Comment on attachment 132730 [details] [diff] [review] Jan's approach Actually RowCountChanged() doesn't expect anything during a batch :-P
Comment 6•21 years ago
|
||
Comment on attachment 132728 [details] [diff] [review] Proposed patch hey, if varga agrees, then I agree :) sr=alecf
Attachment #132728 -
Flags: superreview?(alecf) → superreview+
Assignee | ||
Comment 7•21 years ago
|
||
Yeah, but that should be internal to the tree widget implementation.
Reporter | ||
Comment 8•21 years ago
|
||
Comment on attachment 132730 [details] [diff] [review] Jan's approach alecf: sorry, but jan insists on doing things the hard way (I say :-P to him)
Attachment #132730 -
Flags: superreview?(alecf)
Comment 9•21 years ago
|
||
Comment on attachment 132730 [details] [diff] [review] Jan's approach heh, ok. sr=alecf
Attachment #132730 -
Flags: superreview?(alecf) → superreview+
Reporter | ||
Comment 10•21 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•21 years ago
|
Attachment #132728 -
Flags: review?(varga)
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in
before you can comment on or make changes to this bug.
Description
•