Closed
Bug 10469
Opened 25 years ago
Closed 25 years ago
[DOGFOOD] Inserting into RDF_Sequences messes up
Categories
(Core Graveyard :: RDF, defect, P1)
Core Graveyard
RDF
Tracking
(Not tracked)
VERIFIED
FIXED
M12
People
(Reporter: mozilla, Assigned: waterson)
References
Details
(Whiteboard: [PDT+])
Attachments
(3 files)
(deleted),
text/xul
|
Details | |
(deleted),
text/xul
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
Chris, since you mentioned that you would look at this, here's a bug for it.
:^)
To test, open up the bookmarks window, select a node, and then bring up a
context menu and choose "Insert Separator" for example. All types of bad things
will happen... random nodes will disappear, etc. If you quit apprunner, re-run
it, and re-open the bookmarks window, you'll see a separator right after the
node you had selected previously though.
David was thinking that RDF_NextVal was getting messed up perhaps, confusing the
content model builders in terms of how many children there really are.
We need all this to work right before we start playing around with drag&drop.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M10
Reporter | ||
Updated•25 years ago
|
Priority: P3 → P1
Reporter | ||
Comment 1•25 years ago
|
||
Upping the priority on this as drag&drop is getting closer. <Yikes!>
Assignee | ||
Comment 2•25 years ago
|
||
Adding bug 13815 as a dependency. We need tree control to properly handle
ContentInserted notification before we can work on this...
Assignee | ||
Updated•25 years ago
|
Summary: Inserting into RDF_Sequences messes up → [DOGFOOD] Inserting into RDF_Sequences messes up
Assignee | ||
Updated•25 years ago
|
Target Milestone: M11 → M12
Assignee | ||
Comment 4•25 years ago
|
||
to m12
Assignee | ||
Comment 5•25 years ago
|
||
Assignee | ||
Comment 6•25 years ago
|
||
attached test case. to reproduce, load XUL file; you'll see
123
Click "Insert"
expected result: 4123
actual result: 3214
Whee!
Assignee | ||
Comment 7•25 years ago
|
||
Assignee | ||
Comment 8•25 years ago
|
||
Assignee | ||
Comment 9•25 years ago
|
||
rjc: wanna try this patch on for size?
I removed the aNaturalOrderPos parameter from CreateWidgetItem(), and instead
have it compute that parameter if aProperty is an ordinal property. (Otherwise
it will just use -1, which means "append it").
The BuildContentFromTemplate() routine now looks at the aNaturalOrderPos
parameter for content other than tree items, so will do insertion and removal
of content nodes at the correct location.
Note that this patch screws up the personal toolbar :-/. (Because it now
inserts the template-generated elements -before- the 'hard coded' elements.
Eerily, the bookmarks menu is unaffected.)
Take a look and let me know what you think of the fix; maybe there is a better
way to do this...
Reporter | ||
Comment 10•25 years ago
|
||
I'm going to have to look at the proposed fix in more detail tomorrow. (Sorry,
not feeling good enough to think right now.)
One thing to consider: we're soon going to be able to have sorts imposed on
anything, not just trees. (I'm starting to code up that functionality.)
I think that the calculation of the natural order position hint should perhaps
be moved out of the generic builder directly into the XULSortService. (Actually,
some older code might already be in there, don't recall)
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 11•25 years ago
|
||
fix checked in
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 12•25 years ago
|
||
Checked with todays build [11-29-09], with win-95.
Actually with testcase provided, after clicking Insert button, nothing
happens. But I tried to play around with bookmarks as reported explained,
and it looks working fine. Hence Marking verified.
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•