237002 - XBL reordering content

Status: RESOLVED FIXED

(Core :: XBL, defect, P1)

Description

[[e-mail]]

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.

Comment 1

[[e-mail]]

Attachment: 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.

Comment 2

[Boris Zbarsky [:bzbarsky]]

> 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 http://www.mozilla.org/projects/xbl/xbl.html#children which claims that
<children> is EMPTY.  So does http://www.w3.org/TR/xbl/#children.  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.

Comment 3

[[e-mail]]

(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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

So does removing that <label> from inside <children> make the problem go away?

Comment 5

[Boris Zbarsky [:bzbarsky]]

I checked and it doesn't looks like...

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix

So the problem is that insertion at index 0 was putting the node in the wrong
place in the insertion point....

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 143539 [details] [diff] [review]
Fix

jst, could you review?	This is pretty straightforward....

Comment 8

[Johnny Stenback (:jst)]

Comment on attachment 143539 [details] [diff] [review]
Fix

r+sr=jst

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 143539 [details] [diff] [review]
Fix

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...

Comment 10

[chris hofmann]

Comment on attachment 143539 [details] [diff] [review]
Fix

a=chofmann for 1.7b

Comment 11

[Boris Zbarsky [:bzbarsky]]

Checked in for 1.7b.