Closed Bug 286513 Opened 19 years ago Closed 5 years ago

Wrong order of anonymous XBL-content in HTML pages

Categories

(Core :: XBL, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: fatbull, Unassigned)

References

Details

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217

If there is a delay during page load, XBL bindings may be attached too early. In
this case, anonymous content is created even if not all children have been
loaded. When new data arrives, it is always appended _after_ XBL-generated
content, not at the correct position.
The example PHP file contains a sleep() to simulate such random delays which are
normally caused by slow connections, busy webservers, delays when loading very
large file from cache/harddisk, etc.

Reproducible: Always

Steps to Reproduce:
1. Set up a webserver with PHP
2. upload both example files (xbltest.php and xbltest.xml)
3. load xbltest.php from that server
(I apologize for the trouble, but I currently don't have access to a reliable
server, so I cannot upload the files myself)
Actual Results:  
Output is:

aabbccXX
aaXXbbcc
aaXXbbcc
aaXXbbcc
aaXXbbcc


Expected Results:  
Output should be:

aabbccXX
aabbccXX
aabbccXX
aabbccXX
aabbccXX


This bug seems to be similar to bug 202563, but I'm not sure whether it really
is a duplicate.
Attached file example PHP script (obsolete) —
No, this is unrelated to bug 202563.  It may be related to bug 272646 and bug
261826, though.
Depends on: 272646
Attachment #177694 - Attachment is obsolete: true
That testcase shows the bug over here, but does not fire the assert that fires
in bug 261826.  Still likely to get fixed by patches to clean up the insertion
point mess, but not guaranteed...
I doubt that... <children includes="foo" /> complicates the issue.
IMHO the binding manager should only attach bindings when it's completely safe
to do so, i.e. if a binding defines no anonymous content or anonymous content
will be inserted at the beginning only, the binding may be attached immediately.
 In all other cases the manager must wait until all children have been loaded.

Also have a look at the DOM inspector. It does not display any nodes that have
been inserted after the anonymous content (e.g. the "bbb" node in your testcase).

Today I had an interesting experience with AdBlock. I opened some HTML-pages
with lots of bindings and AdBlock nearly removed everything from those pages;
only a few headlines were left. I suspect this was caused by the fact that not
all nodes have been properly stored in the DOM, so they have finally been erased.
> <children includes="foo" /> complicates the issue.

Of course.  Again, the whole mess will need to be cleaned up a bit.

> In all other cases the manager must wait until all children have been loaded.

What if children are added via DOM manipulation?  The right answer is to handle
DOM changes correctly, not to hack in initial pageload....

> Also have a look at the DOM inspector.

Yeah, the DOM inspector assumes the binding manager isn't buggy.
> What if children are added via DOM manipulation?  The right answer is to handle
> DOM changes correctly, not to hack in initial pageload....

How to solve conflicts? For example:

<content>
<children includes="foo"/>
<children includes="bar"/>
<children/>
</content>

What should happen if someone tries to insert a <foo> between two <bar>s via DOM
manipulation?
a) the binding only transforms the element's initial content only, DOM
manipulation won't be affected
b) DOM-inserted nodes will be moved according to the binding. However, this
could cause unexpected results: (node.appendChild(child)).nextSibling might not
be null
c) Let the author decide (e.g. in DOMNodeInserted)
d) ...
> What should happen if someone tries to insert a <foo> between two <bar>s via
> DOM manipulation?

It's inserted into the right insertion point (the same as it would have been if
it had been between the two <bar>s when the binding was attached).  I don't see
the problem...

> a) the binding only transforms the element's initial content only,

That would not only contradict what documentation we have, it'd break existing
bindings.

> b) DOM-inserted nodes will be moved according to the binding.

You mean their rendering objects will be put in the right place, right?  The DOM
tree is completely unaffected by XBL, always.
> The DOM tree is completely unaffected by XBL, always.

Ah, of course, you're right. My mistake.
So actually the binding manager fails to update existing bindings, correct?
Fails to update them correctly, yes.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
Reopening.  This is a real issue.
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
The testcase attached to the bug worksforme even before the fix for bug 272646.  Is the PHP version fixed too, now that that is fixed?
Assignee: xbl → nobody
QA Contact: ian → xbl

XBL is now disabled in Firefox (Bug 1583314) and is in the process of being removed from Gecko (Bug 1566221), so closing bugs requesting changes to its implementation as wontfix.

Status: NEW → RESOLVED
Closed: 19 years ago5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: