2007-02-05 15:58:39 Chris Petersen: * SUMMARY Under TOT Webkit, RapidWeaver 's "Hello" HTML page doesn't display any DHTML effects when clicking on it's links. This does work under RapidWeaver under stock 10.4.8 webkit frameworks. * STEPS TO REPRODUCE 1. Download and install http://www.realmacsoftware.com/rapidweaver/ 2. Launch RapidWeaver 3.5.1 under stock 10.4.8 3. After main window opens in RapidWeaver , you should see a page that states "Say Hello to RapidWeaver" 4. Click on "Get Started" link and notice the DHTML transition that occurs on page 5. Quit and relaunch RapidWeaver under TOT webkit 6. Repeat Step 4. Notice the entire page content is displayed and clicking on links such as ""Get Started" are no longer functional. * RESULTS The HTML page should be displayed correctly and be functional but isn't. * REGRESSION Yes, this works in RapidWeaver under stock 10.4.8 2007-02-05 16:14:28 Chris Petersen: You can reproduce this issue under TOT (Tiger) and TOT (Leopard) with the following steps: *Enable Debug menu before completing these steps 1) Download the attached file "RapidWeaver.zip" and uncompress it. 2) Open placeholder_eng.html in TOT 3) Notice the problem as originally described Terminal shows this output: [627] file:///Users/cp/Desktop/RapidWeaver/placeholder_eng.html line 19: TypeError: Value undefined (result of expression fx.MultiFadeSize) is not an object. Cannot be used with new. While JS console displays this error: TypeError: Undefined value file:///Users/cp/Desktop/scripts/moo.fx.pack.js Line 121 Looking at the JS file in BBEdit shows , this code on that line : hide: function(el, mode){ el.fs.hide(mode); } 2007-02-05 16:18:21 Chris Petersen: This problem also happens in stock Leopard9A321 as well. <rdar://problem/4977124>
(In reply to comment #0) > 1) Download the attached file "RapidWeaver.zip" and uncompress it. I t would be nice to have it in Bugzilla, if possible.
Created attachment 13259 [details] Reduction This document produces an alert containing "header" in WebKit R19672 or "content" in Safari 419.3, which causes an unexpected node to be retrieved when using nextSibling in Webkit for RapidWeaver's "Hello" page.
Looks like the regression was introduced in r9639 <http://trac.webkit.org/projects/webkit/changeset/9639>, as HTMLParser::isInline() no longer pays attention to the actual element style, and only uses a hardcoded list of tag names. Despite this change having been hidden in a huge unrelated patch, the new behavior appears to match Firefox better, as it also doesn't seem to pay attention to the actual style - but its parser allows nested headers with only inline elements between them (for some inline elements).
Here's what the DOM looks like for the relevant snippet. Safari 2.0 DOM: BODY |-->H3 |-->A |-->H4 |-->#text |-->DIV |-->#text Firefox DOM: BODY |-->H3 |-->A |-->H4 |-->#text |-->DIV |-->#text IE 6 DOM: BODY |-->H3 |-->A |-->H4 |-->#text |-->DIV |-->#text TOT DOM: BODY |-->H3 |-->A |-->A |-->H4 |-->#text |-->DIV |-->#text
Another change you could roll out to fix this is http://trac.webkit.org/projects/webkit/changeset/7701. It looks like the rule added there was inappropriately general. Unfortunately, the check-in lacked a ChangeLog or bug number, so we don't know exactly what it was trying to fix. We'll have to do some aggressive testing to avoid causing a regression.
I was confused by trac. Here's the ChangeLog entry: "Don't allow nested headers when only inlines are in between them. Fixes a hang related to pathological nesting on magicmethodsonline.com." The page in questino was http://magicmethodsonline.com/latest.html
I found this comment in bug 3405 to explain using the list of tag names: "This patch implements the isInline method in the parser and stops using renderers to make the determination (thus eliminating any potential variance in rendering caused by deferred renderer construction)."
bug 13337 is a very similar hang due to deep nesting.
Created attachment 14026 [details] nested heading tags test & results Attached a test for nested heading tags along with results from different browsers. Behavior seems pretty randomly distributed.
I can't reproduce the hang at magicmethodsonline.com, even if I roll out r7701.
Dave mentioned that the magicmethodsonline.com depends on the content of the day, so a larger page on another day would probably still show the hang.
I've changed the spec for compatibility with IE7 -- now, headers nest (regardless of other elements involved). This should get you compatibility for this bug, but it's not clear if it'll break other things or not. Please let me know if this is a problem or not. http://html5.org/tools/web-apps-tracker?from=925&to=926
Committed revision 23728.