Closed Bug 442385 Opened 17 years ago Closed 2 years ago

FireFox XSLT transform removes the closing tag for IFrame

Categories

(Core :: XSLT, defect)

1.9.0 Branch
x86
All
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: prem.9in, Unassigned)

References

Details

Attachments

(1 file)

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; .NET CLR 1.1.4322; MS-RTC LM 8; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 In XSL I have some thing like <iframe id="{concat($CntrlId,'_', $HelpControlCounter, '_Frame')}" frameborder="0" src="{$HelpFrameSrc}"></iframe> <div> .... div contents ... </div> when the transformation happens on FireFox; it gets rendered as <iframe id="clt001_1_Frame" frameborder="0" src="http://msn.com" /> <div> .... div contents ... </div> The closing tag </iframe> is removed and firefox puts a /> in place of it. But this breaks everything. Any thing written after the iframe is not getting displayed bcos an iframe requires a closing tag. since my page has <iframe id="clt001_1_Frame" frameborder="0" src="http://msn.com" /> <div>..... div contents ... </div> .. then my div is not getting displayed. It would have been worked fine if XSL transform would have resulted in html like this <iframe id="clt001_1_Frame" frameborder="0" src="http://msn.com"></iframe> <div>..... div contents ... </div> but since the closing end tag was replaced by a /> everything breaks. Reproducible: Always Steps to Reproduce: the details are enough to repro .. just do a xslt transform on firefox for iframe and a div following that. Actual Results: XSL tranformation in firefox removes the closing tag </iframe> and puts a /> in place of it. Expected Results: XSL tranformation in firefox should not remove the closing tag </iframe> as this is a must required tag for iframe.
Flags: in-testsuite?
Flags: in-litmus?
Flags: blocking1.9.0.1?
Flags: blocking1.8.1.15?
Flags: blocking-firefox3.1?
OS: Windows Server 2003 → All
Version: unspecified → 3.0 Branch
Component: General → XSLT
Flags: blocking-firefox3.1?
Product: Firefox → Core
QA Contact: general → xslt
Version: 3.0 Branch → 1.9.0 Branch
As reported, I think this bug should be closed WORKSFORME. Unlike IE, which serialises the transform output and then sticks it through an HTML parser, Mozilla browsers operate on a tree for XSLT. Therefore which of two equivalent XML serialisations might be used for an element is irrelevant, as can be seen from the attatched test which Firefox will render correctly, but IE will not. Unless the reporter is using the JS interfaces to transform to a text representation and then trying to parse that as HTML, can only presume his stylesheet is in error. Please provide a testcase like the attached that Mozilla fails, and IE succeeds?
I just saw the test attached by Martin .. you can see the the bug there itself I can see it is like this <iframe src="http://www.mozilla.org/"/> <p>The frame is closed.</p> and one can see that the text after Iframe is not getting displayed when page is opened on Firefox or IE.. I cannot see a text for <p>The frame is closed.</p> written after <iframe src="http://www.mozilla.org/"/> This would have been displayed only if it was rendered as <iframe src="http://www.mozilla.org/"> </iframe> <p>The frame is closed.</p> If in XSL I have "<iframe src="{$HelpFrameSrc}"></iframe> <p>The frame is closed.</p>" Then Firefox XSLTProcessor transforms it to HTML as <iframe src="http://www.mozilla.org/"/> <p>The frame is closed.</p> Due to this the text following the Iframe "The frame is closed is not getting displated". This is a bug with FireFox XSLT transform ... If I do the transform in IE it works .. IE XSLT transform will render it as <iframe src="http://www.mozilla.org/"> </iframe> <p>The frame is closed.</p> and there we are able to the text after the iframe. (In reply to comment #1) > Created an attachment (id=327269) [details] > Transform with iframe testcase > As reported, I think this bug should be closed WORKSFORME. > Unlike IE, which serialises the transform output and then sticks it through an > HTML parser, Mozilla browsers operate on a tree for XSLT. Therefore which of > two equivalent XML serialisations might be used for an element is irrelevant, > as can be seen from the attatched test which Firefox will render correctly, but > IE will not. > Unless the reporter is using the JS interfaces to transform to a text > representation and then trying to parse that as HTML, can only presume his > stylesheet is in error. > Please provide a testcase like the attached that Mozilla fails, and IE > succeeds?
1.9 bugs don't block 1.8 releases.
Flags: blocking1.8.1.15?
Prem, could you perhaps attach a testcase that shows the bug? Or perhaps give a page where the error can be seen?
Flags: wanted1.9.0.x?
Flags: blocking1.9.0.1?
Flags: blocking1.9.0.1-
Nominate for wanted when you've got a testcase / confirmation.
Flags: wanted1.9.0.x?
Erm, the XSLT engine doesn't do any serializations at all. It creates a DOM. I take it that you are somehow serializing that DOM using an XML serializer and see the <iframe ... /> instead of the <iframe ...></iframe> that you are expecting? As it happens in XML <foo></foo> and <foo/> are equivalent. You are seeing exactly the rendering as you are expecting, no? With everything after the iframe being rendered as it should, no? You say: The closing tag </iframe> is removed and firefox puts a /> in place of it. But this breaks everything. Any thing written after the iframe is not getting displayed bcos an iframe requires a closing tag. What do you mean "this breaks everything"? Can you please attach a testcase showing this. Clicking the attached testcase I see the "The frame is closed" just fine on the screen, just under the rendered mozilla.org website inside the iframe. Do you not?
Blocks: 445209
QA Whiteboard: qa-not-actionable

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --

Olli, is this still relevant?

Flags: needinfo?(smaug)

More a peterv question.

Flags: needinfo?(smaug) → needinfo?(peterv)

Marking S3 to get this old issue out of un-triaged list, though I am not sure if this is still valid.

Severity: -- → S3

Various folks said WORKSFORME. Without getting more information from the reporter, it's hard to make a real progress.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(peterv)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: