Bug 9357 – Rendering snafu in production Safari when viewing Bugzilla bugs

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[David Kilzer (:ddkilzer)]

Steps to Reproduce:

1. Open Safari.
2. Navigate to webkit-unassigned archives.
3. Command-click on mail message.
4. Click on the Bugzilla bug URL near the top of the bug mail.

Expected Results:

The page renders normally.

Actual Results:

The page renders incorrectly (see screenshot that I'll attach in a bit).

Regression:

This occurred in the production release of Safari 2.0.3 (417.9.3) on Mac OS X 10.4.6 (8I127/PowerPC).

Notes:

This is NOT always reproducible.  This is only the second time I've seen this happen.  This bug is probably VERY timing-dependent.

[David Kilzer (:ddkilzer)]

Created attachment 8769 [details]
Screenshot of rendering issue

[David Kilzer (:ddkilzer)]

Here is the bug I was looking at:

http://bugzilla.opendarwin.org/show_bug.cgi?id=9342

After further testing, reloading the same page over and over will recreate the bug approximately 1 in 10 times.

[David Kilzer (:ddkilzer)]

Created attachment 8770 [details]
Source of bugzilla page with rendering issues

[David Kilzer (:ddkilzer)]

After further testing, this probably only happens if there are TWO copies of Safari running.  The second copy of Safari (which was a locally-built WebKit r14767 plus Attachment 8721 [details] on Bug 9217) was started after test failures from run-webkit-tests.

Even then, the bug shows up much less than 1 in 10 times.

[David Kilzer (:ddkilzer)]

This could be a duplicate of Bug 9356.

[David Kilzer (:ddkilzer)]

(In reply to comment #4)
> After further testing, this probably only happens if there are TWO copies of
> Safari running.  The second copy of Safari (which was a locally-built WebKit
> r14767 plus Attachment 8721 [details] [edit] on Bug 9217) was started after test failures from
> run-webkit-tests.

Belay that order.  This bug does NOT require a second copy of Safari running.  I just saw it again without a second Safari running.

Based on the screenshot, I don't think this bug belongs in the Layout and Rendering component. It looks like the loader, tokenizer or parser screwed up (script contents ended up outside a script element).

[David Kilzer (:ddkilzer)]

Created attachment 8791 [details]
Source of DOM when page renders incorrectly (via "Show DOM Tree")

This is the source of the DOM via the HTML element using the old "Show DOM Tree" menu item from the Debug menu.

There is simply a chunk of the page missing between these two lines in the file:

      <P id="banner-name">
reply&lt;' + '/a&gt;]');

[David Kilzer (:ddkilzer)]

New Steps to Reproduce (works 1 in 5 times):

1. Open this exact bug:  http://bugzilla.opendarwin.org/show_bug.cgi?id=9342
2. Command-Shift-Click on the linked "9342" after "Bug#:" to open up a new tab and change focus to it.
3. Repeat Step 2 for each "good" rendered page until you hit a "bad" one.

[David Kilzer (:ddkilzer)]

(In reply to comment #9)
> New Steps to Reproduce (works 1 in 5 times):
> 
> 1. Open this exact bug:  http://bugzilla.opendarwin.org/show_bug.cgi?id=9342
> 2. Command-Shift-Click on the linked "9342" after "Bug#:" to open up a new tab
> and change focus to it.
> 3. Repeat Step 2 for each "good" rendered page until you hit a "bad" one.

Of course, as soon as I say this, it stops reproducing.

I was rebuilding WebKit and checking out a new copy of WebKit from SVN at the same time (CPU was pegged at 100%).  Try doing the above steps with the CPU pegged (compile WebKit or be creative).

[David Kilzer (:ddkilzer)]

<rdar://problem/4581377>

[David Kilzer (:ddkilzer)]

Created attachment 8795 [details]
Ethereal packet capture in libpcap format of five requests (last one renders incorrectly)

Attaching a packet trace of five HTTP requests for this URL:

http://bugzilla.opendarwin.org/show_bug.cgi?id=9342

The last request renders incorrectly per this bug.

The only thing that stands out to me is that chunked encoding is used for all of the requests, and the second chunk starts on a new TCP/IP packet in all but the last request.   (It looks like an interesting boundary condition without knowing anything else.)

I need to test this bug on a WebKit nightly (since if it's a network-layer issue, it should be reproducible) and then try to reproduce it 100% using some kind of packet-replay software or writing a daemon (in Perl?) that always sends this web page the same way (with the second chunk starting in the middle of a packet).

[David Kilzer (:ddkilzer)]

Comment on attachment 8795 [details]
Ethereal packet capture in libpcap format of five requests (last one renders incorrectly)

(In reply to comment #12)
> Created an attachment (id=8795) [edit]
> The only thing that stands out to me is that chunked encoding is used for all
> of the requests, and the second chunk starts on a new TCP/IP packet in all but
> the last request.   (It looks like an interesting boundary condition without
> knowing anything else.)

The network layer has been eliminated as the problem.  I just captured a trace where the second chunked encoding fell on a packet boundary (started in a new packet), but the page rendered incorrectly.

> I need to test this bug on a WebKit nightly (since if it's a network-layer
> issue, it should be reproducible) and then try to reproduce it 100% using some
> kind of packet-replay software or writing a daemon (in Perl?) that always sends
> this web page the same way (with the second chunk starting in the middle of a
> packet).

I could not reproduce this on a nightly, but easily reproduced it on production Safari (the same version listed in Comment #0).

The bug must lie somewhere in the parser/tokenizer, but it looks like it's been fixed in WebKit ToT.

[David Kilzer (:ddkilzer)]

(In reply to comment #13)
> I could not reproduce this on a nightly, but easily reproduced it on production
> Safari (the same version listed in Comment #0).

Another way to reproduce this problem:

1. Open this exact bug:  http://bugzilla.opendarwin.org/show_bug.cgi?id=9342
2. Command-Click on the linked "9342" after "Bug#:" as fast as possible for a few seconds to open tens of new tabs.  One or a few of them should have the rendering bug displayed.

[David Kilzer (:ddkilzer)]

(In reply to comment #10)
> I was rebuilding WebKit and checking out a new copy of WebKit from SVN at the
> same time (CPU was pegged at 100%).  Try doing the above steps with the CPU
> pegged (compile WebKit or be creative).

CPU load has nothing to do with this bug.  It will reproduce without loading the CPU.

[David Kilzer (:ddkilzer)]

A binary search of WebKit nightlies shows:

 Fixed: r14121
Broken: r14095

Looking at the changelog entries between r14095 and r14121, revision r14106 (Bug 5855) looks like it may have fixed this.

I'm marking this as RESOLVED/FIXED for WebKit ToT, but I'm guessing Apple may want to consider fixing this for the production Safari 2.0.x releases if they're not going to pull WebKit from ToT anytime soon.