Closed
Bug 251004
Opened 21 years ago
Closed 21 years ago
createContextualFragment doesn't work when parent is TD
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: xbiker, Unassigned)
References
()
Details
(Keywords: qawanted)
Attachments
(3 files, 2 obsolete files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
I'm experiencing a peculiar behavior with createContextualFragment when called
on ranges created for TDs. I'm trying to dynamically insert a piece of text
which has a FIELDSET with a TABLE inside it. When I try to insert this piece
inside a SPAN, it all works fine. However, if I try to do the same thing on a
TD, the resulting contextual fragment has both my FRAMESET and the TABLE
*within* it on the same level (as if they were siblings). Clicking on the "Check
- TD" button outputs:
---
Node 0 - #text
Node 1 - FRAMESET
Node 2 - TABLE
Node 3 - #text
while the "Check - SPAN" button outputs (correctly IMHO):
---
Node 0 - #text
Node 1 - FRAMESET
Node 2 - #text
Reproducible: Always
Steps to Reproduce:
This is the code I used:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head>
<script>
function checkContext(forElement) {
html = document.getElementById('blankFieldset').innerHTML;
var here = document.getElementById(forElement);
var r = here.ownerDocument.createRange();
r.setStartBefore(here);
var parsedHTML = r.createContextualFragment(html);
var s='';
for (var j=0; j < parsedHTML.childNodes.length; j++) {
s += "\nNode " + j + ": " + parsedHTML.childNodes[j].nodeName;
}
alert(s + "\n\n and it should be #node, FRAMESET, #node as TABLE is *within*
the FRAMESET");
}
</script>
</head>
<body>
<span id="blankFieldset">
<fieldset id="fieldset[0]">
<legend>Split #|0|</legend>
<table id="tblSplit" border="0">
<tbody>
<tr>
<td>Some text</td>
</tr>
</tbody>
</table>
</fieldset>
</span>
<table>
<tr>
<td id="someTD"></td>
</tr>
</table>
<br>
<span id="someSPAN"></span>
<hr><br>
<input value="Check - TD" type="button" onclick="checkContext('someTD')"/>
<input value="Check - SPAN" type="button" onclick="checkContext('someSPAN')"/>
</body></html>
Actual Results:
The alert came out with:
Node 0 - #text
Node 1 - FRAMESET
Node 2 - TABLE
Node 3 - #text
Expected Results:
It should've output the same results as for a SPAN:
Node 0 - #text
Node 1 - FRAMESET
Node 2 - #text
I've tested this one with Mozilla 1.6 and Firefox 0.9.
|
||
Comment 1•21 years ago
|
||
If you just put the HTML there directly instead of doing
createContextualFragment, what happens? That is, if you copy/paste the relevant
markup inside the span and inside the <td>?
|
Reporter | |
Comment 2•21 years ago
|
||
I'm sorry, but when you say copy/paste do you mean like in a text editor?
Cause if that's what you meant, I fail to see how is this relevant to the
particular behavior createContextualFragment is exhibiting.
If by copy/paste you meant doing something like:
---
here.innerHTML = html
---
then that would work; however in the code that follows the
createContextualFragment (not posted as I didn't think it was relevant) I need
to do something like:
here.appendChild(parsedHTML)
and I believe the parameter to appendChild needs to be an HTML node not a string.
Thanks!
|
|
||
Comment 3•21 years ago
|
||
> I'm sorry, but when you say copy/paste do you mean like in a text editor?
Yes.
> Cause if that's what you meant, I fail to see how is this relevant to the
> particular behavior createContextualFragment is exhibiting.
Because that helps us isolate whether the problem is in the content sink (which
is different between normal HTML parsing and createContextualFragment) or in the
scanner/parser (which is the same).
|
|
Reporter | |
Comment 4•21 years ago
|
||
Okay, I see what you mean.
I have copied the content of the "blankFieldset" span within both the "someTD"
and "someSPAN" and in both cases it renders it correctly (in both browsers).
The JS code (createContextualFragment) however behaves the same.
|
|
||
Comment 5•21 years ago
|
||
OK. It would be great to have a minimal testcase (as little HTML and JS as
possible) that shows the problem...
Keywords: qawanted
|
|
Reporter | |
Comment 6•21 years ago
|
||
I don't get it - it's all in there - my first post has the small HTML page I
have used....
It's the part in between:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
and, well... :)
</body></html>
I'm seeing it in here, on the bug's page:
http://bugzilla.mozilla.org/show_bug.cgi?id=251004
|
|
||
Comment 7•21 years ago
|
||
Philip, if that testcase is minimal, that's great. Minimal means that removal
of any tag or part of the script makes the bug disappear.... is that the case
for that code? If so, could you attach it to the bug as an attachment?
|
|
Reporter | |
Comment 8•21 years ago
|
||
I believe this to be the mininimal test case for this bug. It contains the
incorect behavior (with TDs) and the correct one (SPAN) using the same fragment
of HTML.
Thanks
|
|
||
Comment 9•21 years ago
|
||
The testcase you posted had a JS error in it (and was clearly never tested)
Attachment #153545 -
Attachment is obsolete: true
|
|
||
Comment 10•21 years ago
|
||
No need for fieldset. <div> works just as well.
Attachment #153547 -
Attachment is obsolete: true
|
|
||
Comment 11•21 years ago
|
||
Since you use setStartBefore(), the fragment is being created as a child of t
he <tr> and a sibling of the <td> (right before the <td>). As a result, you're
looking at the invalid markup this pure-HTML testcase has, and the parser does
some fixups on it to make it saner.
|
|
||
Comment 12•21 years ago
|
||
This calls setStart(here, 0) instead of setStartBefore(here) to position the
range the way you seem to want it positioned.
|
|
||
Comment 13•21 years ago
|
||
Marking invalid. Given where the range is positioned, createContextualFragment
is doing the best it can to produce something sane....
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
|
|
Reporter | |
Comment 14•21 years ago
|
||
I see your point. Thanks!
You need to log in
before you can comment on or make changes to this bug.
Description
•