Bug 41069 - REGRESSION (HTML5 parser): A page at swlab.mt.haw-hamburg.de broken due to <tag<tag> parsing changes
Summary: REGRESSION (HTML5 parser): A page at swlab.mt.haw-hamburg.de broken due to <t...
Status: RESOLVED DUPLICATE of bug 40961
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P1 Normal
Assignee: Adam Barth
URL: http://swlab.mt.haw-hamburg.de/~s1991...
Keywords:
Depends on:
Blocks: 41115
  Show dependency treegraph
 
Reported: 2010-06-23 07:04 PDT by CorniMac
Modified: 2010-07-09 11:16 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description CorniMac 2010-06-23 07:04:04 PDT
The site contains a text-area in a form which is in a table. 
The source code of the table row with the text-area is 
<tr>
		<td>Anfrage</td>
		<td><textarea name="anfrage" cols="40" rows="10"</textarea></td>
</tr>
and doesn't cause problems with the stable version of Safari 5 nor with Gecko browsers I tested so far.
However, WebKit r61670 stops displaying to another div that should be shown (div id="menu" which is shown if you are logged in). For some reason it fills code into the textarea. This is not intended in the source code, however, the web inspector clearly shows that it's just put into there.
The code in question is everything that comes after </textarea>, causing, for example, div="menu" which is specified after </textarea> not to appear.

WebKit r61670 on Mac OS X 10.6, problem not appearing in the stable version of Safari 5.
Comment 1 Adam Barth 2010-06-23 17:41:02 PDT
<textarea name="anfrage" cols="40" rows="10"</textarea>

Yep.  The problem is the missing ">" on the textarea start tag.
Comment 2 Adam Barth 2010-06-23 17:43:05 PDT
See http://www.w3.org/Bugs/Public/show_bug.cgi?id=9985
Comment 3 CorniMac 2010-06-23 22:29:04 PDT
(In reply to comment #1)
> <textarea name="anfrage" cols="40" rows="10"</textarea>
> 
> Yep.  The problem is the missing ">" on the textarea start tag.

I see, so the parsing behaviour changed in the nightlies. Thanks! I will, of course, correct that mistake in the site - just saying because you linked that site as an example at w3.org. Should I upload the broken site elsewhere so you can use that example further?
Funny that nobody who checked the source code (including me) noticed that so that I filed a bug, though.
Comment 4 Adam Barth 2010-06-23 22:37:16 PDT
> I see, so the parsing behaviour changed in the nightlies. Thanks!

Yeah, we're implementing the HTML5 parsing algorithm.

> I will, of course, correct that mistake in the site - just saying because you linked that site as an example at w3.org. Should I upload the broken site elsewhere so you can use that example further?

That's not really necessary.  We know that problem is.  The tricky part is that the new behavior matches Internet Explorer, so your site is/was probably broken in IE.  It's unclear whether more web sites are broken with the old behavior or the new behavior.

> Funny that nobody who checked the source code (including me) noticed that so that I filed a bug, though.

Thanks for filing the bug.  It helps us get a sense for how many sites are affected by the change.  It's a tough typo to spot.  We've been pouring over these details recently, so it's something we're used to looking for this week.  :)
Comment 5 Adam Barth 2010-07-09 11:16:00 PDT
It appears that the site is fixed now.  Thanks for updating it.
Comment 6 Adam Barth 2010-07-09 11:16:35 PDT
Marking as a duplicate of Bug 40961 so we can track how often these issue occur.

*** This bug has been marked as a duplicate of bug 40961 ***