Closed Bug 237002 Opened 20 years ago Closed 20 years ago

XBL reordering content


(Core :: XBL, defect, P1)






(Reporter: neil, Assigned: bzbarsky)


(Keywords: regression)


(2 files)

editor.js has some code to insert nodes as children of a <statusbarpanel> which
has an xbl definition of <content><children><label/></children></content>.
However the nodes don't display in the position where they were inserted. DomI
in XBL mode agrees neither with DomI in DOM mode (which does show that the DOM
is correct) nor with the box objects (which agree with the actual display).
Box objects: <toolbarbutton><label><toolbarbutton>
DomI  (XBL): <label><toolbarbutton><toolbarbutton>
DomI  (DOM): <toolbarbutton><toolbarbutton><label>
cvs up -j1.117 -j1.116 nsBindingManager.cpp resolved the issue.
Attached file Basket case
"Insert" is the code path editor.js uses, it prepends new nodes to the
toolbar's first child, which should then appear to be in descending order, but
just to be sure, I added the "Add" button which prepends the new node to the
toolbar's last child, so this should generate the buttons in ascending numeric
order... instead it manages to seriously confuse Mozilla.
> which has an xbl definition of <content><children><label/></children></content>

Whoa.  How's that supposed to work, exactly?  I was under the impression that
you just wanted to use <children /> at the place where you wanted the kids, no?
 What does it mean to have <children> enclosing anonymous content??

See which claims that
<children> is EMPTY.  So does  Is that not
the case anymore, Ian?  If it IS the case, I would like to change the content
sink to enforce this.  I know our code certainly assumes that insertion points
are atomic in all sorts of places; I'm surprised this never bit anyone before.
(In reply to comment #2)
>What does it mean to have <children> enclosing anonymous content??
It provides default content, if there are no children when the binding is
attached. Unfortunately it isn't (in Mozilla) dynamically updated, otherwise it
would be a neat solution to those empty bookmark folder menus.
So does removing that <label> from inside <children> make the problem go away?
I checked and it doesn't looks like...
Attached patch FixSplinter Review
So the problem is that insertion at index 0 was putting the node in the wrong
place in the insertion point....
Comment on attachment 143539 [details] [diff] [review]

jst, could you review?	This is pretty straightforward....
Attachment #143539 - Flags: superreview?(jst)
Attachment #143539 - Flags: review?(jst)
OS: Windows 2000 → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.7beta
Comment on attachment 143539 [details] [diff] [review]

Attachment #143539 - Flags: superreview?(jst)
Attachment #143539 - Flags: superreview+
Attachment #143539 - Flags: review?(jst)
Attachment #143539 - Flags: review+
Comment on attachment 143539 [details] [diff] [review]

Could this please be approved for 1.7b?  It fixes a regression in ordering of
content dynamically inserted as the first child of a node with an XBL binding
attached to it...
Attachment #143539 - Flags: approval1.7b?
Comment on attachment 143539 [details] [diff] [review]

a=chofmann for 1.7b
Attachment #143539 - Flags: approval1.7b? → approval1.7b+
Checked in for 1.7b.
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.