Closed
Bug 533905
Opened 16 years ago
Closed 6 years ago
FF3.6: XBL doesn't apply bindings early enough on replaceChild call
Categories
(Core :: XBL, defect)
Tracking
()
RESOLVED
INVALID
mozilla1.9.2
People
(Reporter: WeirdAl, Unassigned)
Details
(Keywords: regression, testcase)
Attachments
(1 file)
1.74 KB,
patch
|
Details | Diff | Splinter Review |
I'm attaching a testcase which passes with FF3.5, but fails with FF3.6. The reset method of a XUL textbox does not apply until too late.
Reporter | ||
Updated•16 years ago
|
Flags: blocking1.9.2?
Keywords: regression,
testcase
Reporter | ||
Updated•16 years ago
|
Target Milestone: --- → mozilla1.9.2
Reporter | ||
Updated•16 years ago
|
Attachment #416868 -
Attachment is patch: true
Attachment #416868 -
Attachment mime type: application/octet-stream → text/plain
![]() |
||
Comment 1•16 years ago
|
||
This is sort of a known issue. The issue is that the removal of the <box>'s child textnode (which isn't particularly valid to start with and so forces frametree fixups) destroys the <box>'s frame. This part we didn't do in 3.5; instead we just had broken layout... The other part of the issue is that the frame gets recreated asynchronously. So when you insert the new node, it doesn't get frames constructed at that point, and so doesn't get bindings attached.
You can reproduce this in various other ways; most simply dynamically changing an attribute of a node in such a way that it should get a binding attached won't do so synchronously (in 3.5 or 3.6). Or you could use various other situations that force frame reconstructs like {ib} splits and whatnot...
Given the mess that is XBL1 binding attachment, there's really no good solution for this on the layout side without causing serious performance penalties for web content. On the script side, you can force all binding attachment to be up to date by flushing style reresolves (either getting some computed style property from some node, or asking for any layout-dependent DOM property; the latter will also flush layout, of course). I agree that the situation sucks; that's why we need XBL2.
I certainly wouldn't block 1.9.2 on this, though.
![]() |
||
Comment 2•16 years ago
|
||
Note in particular the JS console warning this testcase triggers:
Warning: XUL box for box element contained an inline #text child, forcing all its children to be wrapped in a block.
Source File: http://localhost:8888/tests/content/xbl/test/test_replaceChild.xul
Line: 0
blocking- based on comment 1
Flags: blocking1.9.2? → blocking1.9.2-
Reporter | ||
Comment 4•6 years ago
|
||
XBL is dead. It has ceased to be.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•