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.
Created attachment 143496 [details] 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 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.
(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...
Created attachment 143539 [details] [diff] [review] Fix 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] Fix jst, could you review? This is pretty straightforward....
OS: Windows 2000 → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.7beta
Comment on attachment 143539 [details] [diff] [review] Fix r+sr=jst
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...
Attachment #143539 - Flags: approval1.7b?
Comment on attachment 143539 [details] [diff] [review] Fix a=chofmann for 1.7b
Attachment #143539 - Flags: approval1.7b? → approval1.7b+
Checked in for 1.7b.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.