Bug 9357

Created attachment 8769 [details] Screenshot of rendering issue

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.

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

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.

This could be a duplicate of Bug 9356.

(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).

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;]');

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.

(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).

<rdar://problem/4581377>

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).

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.

(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.

(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.

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.