273543 - Link around paragraph not getting parsed always the same

Status: RESOLVED FIXED

(Core :: DOM: HTML Parser, defect)

Description

[Martijn Wargers (dead)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20041206 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20041206 Firefox/1.0+

See upcoming testcase.
Basically, it consists of this:
First:<br>
<a href="#">text<p>test</p></a>
Second:<br>
<a href="#">text<p>test</p><script></script></a>

As far as I know this should be parsed in the same manner, but currently Mozilla
doesn't do this.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Actual Results:  
"Second:" parsed different as "One:"

Expected Results:  
I think "Second:" should be parsed just like "One:"

Comment 1

[Martijn Wargers (dead)]

Attachment: Testcase

Originally I saw this bug where sometimes you got a different layout because of
this. But this page is not available anymore.

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

The problem here is that we activate RS handling for the second paragraph. I
suspect nsHTMLTokenizer::ScanDocStructure is at fault here, but I need to test
more (I don't have time right now).

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

*Sigh*. There's no easy fix for this. We flush our tokens after seeing </script>
tags (for bug 22485) and lose our chance to mark the <a> tag well formed, so we
activate RS handling on it. Changing this behavior is difficult because we have
no way of knowing if the <script> is going to do something evil (like
document.write("<b>");) and break us.

This is an unforunate case where RS handling really does show us parsing
differently than IE.

Comment 4

[Martijn Wargers (dead)]

Well, the page where I saw this bug didn't use a <script> tag, but sometimes you
still get the wrong parsing. I merely used the <script> tag as a way to 100% of
the time trigger the bug. 

Comment 5

[Timwi]

You may have been thinking of bug 286048.

Comment 6

[Daniel.S]

Marking this dependent on bug 324875, which is about the underlying problem.
Maybe the HTML5 parser can solve the issue with script elements.