Bug 13603 - style leaks in washingtonpost.com
Summary: style leaks in washingtonpost.com
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 523.x (Safari 3)
Hardware: Macintosh OS X 10.4
: P1 Normal
Assignee: Nobody
URL: http://www.washingtonpost.com
Keywords: HasReduction, InRadar
Depends on:
Blocks:
 
Reported: 2007-05-06 09:14 PDT by Antti Koivisto
Modified: 2007-05-14 19:04 PDT (History)
2 users (show)

See Also:


Attachments
webarchive where the problem is visible (488.45 KB, application/x-webarchive)
2007-05-06 09:15 PDT, Antti Koivisto
no flags Details
reduced test case (189 bytes, text/html)
2007-05-06 10:50 PDT, Alexey Proskuryakov
no flags Details
[WIP] First cut at a fix (14.59 KB, patch)
2007-05-12 12:42 PDT, mitz
no flags Details | Formatted Diff | Diff
[WIP] non-leaking version (14.54 KB, patch)
2007-05-13 06:03 PDT, mitz
no flags Details | Formatted Diff | Diff
[WIP] updated comments and fixed behavior for "unaffected" tags (15.45 KB, patch)
2007-05-13 13:39 PDT, mitz
no flags Details | Formatted Diff | Diff
Attachment 14539 without whitespace-only changes (6.03 KB, patch)
2007-05-13 13:40 PDT, mitz
no flags Details | Formatted Diff | Diff
Handle closing of residual style across multiple blocks (23.94 KB, patch)
2007-05-13 15:57 PDT, mitz
hyatt: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Antti Koivisto 2007-05-06 09:14:19 PDT
Open the attached webarchive, mouse over the main story links. Red underlining spreads to other stories too. The problems does not happen on this page normally but I have seen daily versions where it does occur before too, so it is not a one time thing. Works fine in ie/ffx.

Not a regression but marking P1 since it is a major site and the problem is highly visible when it happens.
Comment 1 Antti Koivisto 2007-05-06 09:15:17 PDT
Created attachment 14374 [details]
webarchive where the problem is visible
Comment 2 Alexey Proskuryakov 2007-05-06 10:50:23 PDT
Created attachment 14376 [details]
reduced test case

For this test case, html5lib produces the same tree as Firefox.
Comment 3 mitz 2007-05-06 12:10:46 PDT
Is Layout and Rendering the correct component? Is this not a duplicate of bug 12808 (or bug 12861)?
Comment 4 Alexey Proskuryakov 2007-05-06 22:18:10 PDT
...or even bug 8750?
Comment 5 Eric Seidel (no email) 2007-05-07 02:01:13 PDT
Surprised this is a P1, certainly not a regression.  I guess just that it's wpost.com
Comment 6 Antti Koivisto 2007-05-07 04:18:35 PDT
Seemed appropriate since it is wp and the problem is very ugly. Also there seems to be tons of duplicates.
Comment 7 mitz 2007-05-12 12:42:05 PDT
Created attachment 14520 [details]
[WIP] First cut at a fix

Not even tested thoroughly, this patch tries to fix the "one block" limitation of handleResidualStyleCloseTagAcrossBlocks() mentioned in bug 8750 comment #2. It appears to fix the reductions in this bug, in bug 8750, in bug 12808 and in bug 12861. Not sure that it works in some more complicated cases.
Comment 8 mitz 2007-05-13 04:07:32 PDT
Comment on attachment 14520 [details]
[WIP] First cut at a fix

This is leaking newNode. I think

+            prevMaxElem->didRefNode = false;

should say true.
Comment 9 mitz 2007-05-13 06:03:45 PDT
Created attachment 14534 [details]
[WIP] non-leaking version
Comment 10 mitz 2007-05-13 13:39:17 PDT
Created attachment 14539 [details]
[WIP] updated comments and fixed behavior for "unaffected" tags
Comment 11 mitz 2007-05-13 13:40:39 PDT
Created attachment 14540 [details]
Attachment 14539 [details] without whitespace-only changes

This is a more readable version of attachment 14539 [details].
Comment 12 mitz 2007-05-13 15:57:11 PDT
Created attachment 14541 [details]
Handle closing of residual style across multiple blocks

Code changes are the same as in attachment 14539 [details]. No test regressions.

Includes a change log and a test. The expected results in the test are identical to the results produced by html5lib-0.9. They differ from the results given by Firefox in some cases, mostly because Firefox does not insert an empty inline between two consecutive block tags, e.g. <i><div><pre>foo</i> turns into <i></i><div><pre><i>foo</i> in Firefox, but html5lib and this patch parse it as <i></i><div><i></i><pre><i>foo</i>.
Comment 13 Dave Hyatt 2007-05-13 17:15:16 PDT
I would prefer it if we could avoid the empty inlines.  As a general rule we should be shooting for the most minimal set of tags possible to ensure the correct rendering.  The empty inlines are obviously useless, so it would be good if we could detect this scenario and avoid creating them.

We can make sure that HTML5 is updated to reflect this too, since I'm sure Hixie would agree that the algorithm should not produce useless extra tag sequences.
Comment 14 Dave Hyatt 2007-05-13 17:23:37 PDT
Comment on attachment 14541 [details]
Handle closing of residual style across multiple blocks

Patch looks good, but I'd like to avoid generating inlines when it isn't necessary.
Comment 15 Dave Hyatt 2007-05-13 23:02:25 PDT
Comment on attachment 14541 [details]
Handle closing of residual style across multiple blocks

I'm going to r+ this.

We should maybe file a followup bug about stripping empty inlines whereever we think we can get away with it.
Comment 16 Antti Koivisto 2007-05-14 06:06:37 PDT
<rdar://problem/5200418>
Comment 17 mitz 2007-05-14 08:24:23 PDT
(In reply to comment #15)
> We should maybe file a followup bug about stripping empty inlines whereever we
> think we can get away with it.
 
Bug 13712.
Comment 18 Mark Rowe (bdash) 2007-05-14 19:04:27 PDT
Landed in r21472.