Closed
Bug 332375
Opened 19 years ago
Closed 19 years ago
Firefox 1.5 arbitrarily moves block level element outside unknown HTML element
Categories
(Core :: DOM: HTML Parser, defect)
Core
DOM: HTML Parser
Tracking
()
RESOLVED
DUPLICATE
of bug 311366
People
(Reporter: henrik.bechmann, Assigned: mrbkap)
Details
Attachments
(1 file)
|
1023 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
When Firefox 1.5 encounters a block level element inside an unknown HTML element it moves the element in the DOM to outside the unknown element:
<unknownelement><div>block level element</div></unknownelement>
becomes
<unknownelement></unknownelement><div>block level element</div>
This does not occur in IE or Opera.
It is important as I am developing an AJAX front end that (in text/html) uses unknown elements to specify page widgets. Javascript then substitues known HTML elements for the unknown ones.
I actually have a little XML grammar developing, and in the end it will work in application+xhtml, but I need it to work in text/html as well.
My (ubly) workaround is to place an unparamterized <object> element above the block level HTML element in the DOM, which shields the block level elements from being moved. So
<unknownelement><block><div>block level element</div></block></unknownelement>
stays in place.
also inline elements stay in place, like this:
<unknownelement><span>block level element</span></unknownelement>
I submit that Firefox should never change the DOM, even when it encounters this situation. I presume it is a programmer's workaround that should be solved another way.
Reproducible: Always
Steps to Reproduce:
Open the following web page in Firefox 1.5*:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:d="www.osscommons.ca/xml/adlml" xml:lang="en" lang="en">
<head>
<title>Demonstation of DOM handling bug</title>
<meta http-equiv="content-type" content="text/xml;charset=iso-8859-1" />
<script type="text/javascript">
function cleanhtml(str){
str=str.toString();
str = str.replace(/\&/g,"&");
str = str.replace(/\</g,"<");
str = str.replace(/\>/g,">");
str = str.replace(/\"/g,""");
return str;
}
function dodisplay() {
document.getElementById("htmloutput").innerHTML = cleanhtml(document.getElementById("changedDOM").innerHTML);
}
</script>
</head>
<body onload="dodisplay()">
<div id="changedDOM">
<unknownelement>
<div>This is a block element which has been moved!?!?!?</div>
</unknownelement>
<unknownelement>
<span>This is an inline element</span>
</unknownelement>
</div>
<div id="htmloutput"></div>
</body>
Actual Results:
The DOM is changed
Expected Results:
The DOM should not be changed
My actual implementation is to do somthing like this:
<d:dlobject d:dlclass="treeblock">
<div>This is a tree block</div>
<d:dlobject d:dlclass="treenode">
<d:dlobject d:dlclass="treeitem">This is a tree node</d:dlobject>
<d:dlobject d:dlclass="treenode">
<d:dlobject d:dlclass="treeitem">This is another tree node</d:dlobject>
<d:dlobject d:dlclass="treenode">
<div>This is a block of text to display</div>
</d:dlobject>
</d:dlobject>
</d:dlobject>
</d:dlobject>
I also have a <d:dlproperty> element that gets absorbed into a javascript data structure to modify presentation and behaviors.
The <d:dlproperty> elements are absorbed in javascript and removed. The <d:dlobject> elements are replaced by (possibly complex) html elements, typically div's with special class values.
As you know XHTML support is still a bit sketchy, so I want this to work in HTML as well, which it does in IE, Opera, and Firefox, except for this bug. As the market develops I will migrate it to XHTML, but this will probably take some years.
I have tested this scenario with application+xhtml in Firefox, and the problem does not occur there. Trouble is, it requires browser sniffing, an application server, and a LOT more time to display the page, all of which constitutes a serious barrier to usage.
|
Reporter | |
Comment 1•19 years ago
|
||
Sorry, that should be
<unknownelement><object><div>block level element</div></object></unknownelement>
stays in place
(In reply to comment #0)
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1)
> Gecko/20060111 Firefox/1.5.0.1
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1)
> Gecko/20060111 Firefox/1.5.0.1
>
> When Firefox 1.5 encounters a block level element inside an unknown HTML
> element it moves the element in the DOM to outside the unknown element:
>
> <unknownelement><div>block level element</div></unknownelement>
>
> becomes
>
> <unknownelement></unknownelement><div>block level element</div>
>
> This does not occur in IE or Opera.
>
> It is important as I am developing an AJAX front end that (in text/html) uses
> unknown elements to specify page widgets. Javascript then substitues known HTML
> elements for the unknown ones.
>
> I actually have a little XML grammar developing, and in the end it will work in
> application+xhtml, but I need it to work in text/html as well.
>
> My (ubly) workaround is to place an unparamterized <object> element above the
> block level HTML element in the DOM, which shields the block level elements
> from being moved. So
>
> <unknownelement><block><div>block level element</div></block></unknownelement>
>
> stays in place.
>
> also inline elements stay in place, like this:
>
> <unknownelement><span>block level element</span></unknownelement>
>
> I submit that Firefox should never change the DOM, even when it encounters this
> situation. I presume it is a programmer's workaround that should be solved
> another way.
>
> Reproducible: Always
>
> Steps to Reproduce:
> Open the following web page in Firefox 1.5*:
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:d="www.osscommons.ca/xml/adlml" xml:lang="en" lang="en">
> <head>
> <title>Demonstation of DOM handling bug</title>
> <meta http-equiv="content-type" content="text/xml;charset=iso-8859-1" />
> <script type="text/javascript">
> function cleanhtml(str){
> str=str.toString();
> str = str.replace(/\&/g,"&");
> str = str.replace(/\</g,"<");
> str = str.replace(/\>/g,">");
> str = str.replace(/\"/g,""");
> return str;
> }
> function dodisplay() {
> document.getElementById("htmloutput").innerHTML =
> cleanhtml(document.getElementById("changedDOM").innerHTML);
> }
> </script>
> </head>
> <body onload="dodisplay()">
> <div id="changedDOM">
> <unknownelement>
> <div>This is a block element which has been moved!?!?!?</div>
> </unknownelement>
> <unknownelement>
> <span>This is an inline element</span>
> </unknownelement>
> </div>
> <div id="htmloutput"></div>
> </body>
> Actual Results:
> The DOM is changed
>
> Expected Results:
> The DOM should not be changed
>
> My actual implementation is to do somthing like this:
>
> <d:dlobject d:dlclass="treeblock">
> <div>This is a tree block</div>
> <d:dlobject d:dlclass="treenode">
> <d:dlobject d:dlclass="treeitem">This is a tree node</d:dlobject>
> <d:dlobject d:dlclass="treenode">
> <d:dlobject d:dlclass="treeitem">This is another tree node</d:dlobject>
> <d:dlobject d:dlclass="treenode">
> <div>This is a block of text to display</div>
> </d:dlobject>
> </d:dlobject>
> </d:dlobject>
> </d:dlobject>
>
> I also have a <d:dlproperty> element that gets absorbed into a javascript data
> structure to modify presentation and behaviors.
>
> The <d:dlproperty> elements are absorbed in javascript and removed. The
> <d:dlobject> elements are replaced by (possibly complex) html elements,
> typically div's with special class values.
>
> As you know XHTML support is still a bit sketchy, so I want this to work in
> HTML as well, which it does in IE, Opera, and Firefox, except for this bug. As
> the market develops I will migrate it to XHTML, but this will probably take
> some years.
>
> I have tested this scenario with application+xhtml in Firefox, and the problem
> does not occur there. Trouble is, it requires browser sniffing, an application
> server, and a LOT more time to display the page, all of which constitutes a
> serious barrier to usage.
>
Related to Core bug 321877 comment 2?
|
||
Comment 3•19 years ago
|
||
For future reference, it makes for a much cleaner bug report to create the bug, and then attach your testcase, rather than putting it directly in a comment (or two).
|
|
||
Updated•19 years ago
|
Assignee: nobody → mrbkap
Component: General → HTML: Parser
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → parser
Hardware: PC → All
Version: unspecified → Trunk
|
||
Comment 4•19 years ago
|
||
*** This bug has been marked as a duplicate of 311366 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•