Closed
Bug 286513
Opened 19 years ago
Closed 5 years ago
Wrong order of anonymous XBL-content in HTML pages
Categories
(Core :: XBL, defect)
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.
Comment 3•19 years ago
|
||
No, this is unrelated to bug 202563. It may be related to bug 272646 and bug 261826, though.
Depends on: 272646
Comment 4•19 years ago
|
||
Attachment #177694 -
Attachment is obsolete: true
Comment 5•19 years ago
|
||
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.
Comment 7•19 years ago
|
||
> <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) ...
Comment 9•19 years ago
|
||
> 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.
Reporter | ||
Comment 10•19 years ago
|
||
> 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?
Comment 11•19 years ago
|
||
Fails to update them correctly, yes.
Comment 12•19 years ago
|
||
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/
Comment 13•19 years ago
|
||
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
Comment 14•19 years ago
|
||
Reopening. This is a real issue.
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
Updated•19 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 15•15 years ago
|
||
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?
Updated•15 years ago
|
Assignee: xbl → nobody
QA Contact: ian → xbl
Comment 16•5 years ago
|
||
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 ago → 5 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•