XBL reordering content

RESOLVED FIXED in mozilla1.7beta

Status

()

P1
normal
RESOLVED FIXED
15 years ago
15 years ago

People

(Reporter: neil, Assigned: bzbarsky)

Tracking

({regression})

Trunk
mozilla1.7beta
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
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.
(Reporter)

Comment 1

15 years ago
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.
(Assignee)

Comment 2

15 years ago
> 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.
(Reporter)

Comment 3

15 years ago
(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.
(Assignee)

Comment 4

15 years ago
So does removing that <label> from inside <children> make the problem go away?
(Assignee)

Comment 5

15 years ago
I checked and it doesn't looks like...
(Assignee)

Comment 6

15 years ago
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....
(Assignee)

Comment 7

15 years ago
Comment on attachment 143539 [details] [diff] [review]
Fix

jst, could you review?	This is pretty straightforward....
Attachment #143539 - Flags: superreview?(jst)
Attachment #143539 - Flags: review?(jst)
(Assignee)

Updated

15 years ago
OS: Windows 2000 → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.7beta
Comment on attachment 143539 [details] [diff] [review]
Fix

r+sr=jst
Attachment #143539 - Flags: superreview?(jst)
Attachment #143539 - Flags: superreview+
Attachment #143539 - Flags: review?(jst)
Attachment #143539 - Flags: review+
(Assignee)

Comment 9

15 years ago
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 10

15 years ago
Comment on attachment 143539 [details] [diff] [review]
Fix

a=chofmann for 1.7b
Attachment #143539 - Flags: approval1.7b? → approval1.7b+
(Assignee)

Comment 11

15 years ago
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.