Summary: | REGRESSION: TripTik planner at aaa.com never finishes loading due to unclosed canvas tag | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Simon Pride <simon.pride> | ||||||||
Component: | DOM | Assignee: | Darin Adler <darin> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | ap, darin | ||||||||
Priority: | P1 | Keywords: | HasReduction, InRadar, Regression | ||||||||
Version: | 420+ | ||||||||||
Hardware: | Mac | ||||||||||
OS: | OS X 10.4 | ||||||||||
URL: | http://www.aaa.com | ||||||||||
Attachments: |
|
Description
Simon Pride
2007-02-16 13:57:07 PST
Confirmed as a regression. There is a "maximum call stack exceeded" error in the console. Steps to reproduce: 1. Open http://www.aaa.com 2. Enter some U.S. zip code (such as 95014) 3. Click "TripTik(R) Travel Planner" link under Maps & Directions. The "maximum call stack exceeded" error is red herring - it is caused by unreliable error logging code. The actual problem appears to be a result of an unclosed <canvas> tag: ... <canvas ID="dRouteCanvas" width=2000 height=2000 /> </DIV> Does this fail with Firefox too? I ask because I believe Firefox would also consider this an unclosed <canvas> tag. > Does this fail with Firefox too? I ask because I believe Firefox would also
consider this an unclosed <canvas> tag.
No, it works fine in the current version of Firefox (2.0.0.1 on PowerPC).
We should figure out why WebKit's rule doesn't match Firefox's. Why does it close the canvas element? Is it the /> at the end of the element? Is it the subsequent </div> or some other markup? Or what? Is it naive to ask why Safari 2.0.4 with its Tiger 10.4.8 version of WebKit (419.3?) handles it OK? (In reply to comment #6) > Is it naive to ask why Safari 2.0.4 with its Tiger 10.4.8 version of WebKit > (419.3?) handles it OK? In Tiger WebKit, <canvas> is a standalone element like <img>, and so there's no such things as an "open" canvas element. TOT WebKit has changed to match other browsers and the WhatWG draft specification, and thus you have to close the <canvas> element with a separate </canvas> in HTML documents. Firefox matches TOT WebKit in this regard, but somehow the site is still working. That's what we have to figure out. Created attachment 13358 [details] test case > We should figure out why WebKit's rule doesn't match Firefox's. Why does it > close the canvas element? Is it the /> at the end of the element? Is it the > subsequent </div> or some other markup? Or what? Looks like it's a <div> </div> pair around the canvas - the closing div alone isn't enough. I tested Firefox with other tags; title, style, iframe, noembed, noframes, noscript Only canvas had the special behavior, where the </div> closed the element. Also, I tested with multiple elements, and it only worked if the element closed was the one opened just before the canvas. I'm guessing this is a canvas-specific quirk in Firefox. A </p> works, as does </div>, but not </a>, </b>, or </form>. And the element doesn't have to be the closest enclosing one. My mistake. Closing any open element seems to work. My experiments with <a> and <b> were presumably in cases where those elements were closed already. Seems that the Gecko HTML parser classifies canvas as a "special". http://lxr.mozilla.org/seamonkey/source/parser/htmlparser/src/nsElementTable.cpp And that file contains all sorts of rules for closing. I'm still not sure how to modify our parser to have similar behavior in this case. Created attachment 13577 [details]
patch with change log and test case
Comment on attachment 13577 [details]
patch with change log and test case
This sentence is not quite right: "Changed the Document parameter to the constructor to instead of HTMLDocument".
Some comments I noticed before deciding to question the approach: 1) I'd like to see more tests for cases that should or should not close the canvas. 2) The correct spelling is "well-formed", not "wellformed" or "well formed". And, finally, <canvas> should not skip parsing its contents - it should just prevent them from rendering only. That appears to be what Firefox does. One special case to consider is a <script> inside <canvas>, Firefox appears to execute it: <canvas> <b>fallback</b> <script> alert('x'); </script> </canvas> Comment on attachment 13577 [details]
patch with change log and test case
r-
Created attachment 13611 [details]
revised patch, with change log and regression tests
Comment on attachment 13611 [details]
revised patch, with change log and regression tests
r=me
Committed revision 20170. <http://trac.webkit.org/projects/webkit/changeset/20170> |