Bug 25786 - Pages/images failing to load after 3-5 pages of navigation
Summary: Pages/images failing to load after 3-5 pages of navigation
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P1 Critical
Assignee: Nobody
URL: http://www.mydreammobile.com
Keywords: InRadar
: 28863 (view as bug list)
Depends on:
Reported: 2009-05-14 03:43 PDT by Colin Rotherham
Modified: 2009-10-07 11:53 PDT (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Colin Rotherham 2009-05-14 03:43:24 PDT
This is a development site an is currently a work-in-progress.

Please let me know if you cannot reproduce the bug. I've also noticed it in Safari 4 Public Beta and spotted it reported once on the Magento forums: http://www.magentocommerce.com/boards/viewthread/34925/

Reproducing the bug:
Navigate between two different pages 5+ times (as quickly as possible) with a lot of content (images, CSS, javascript) until you get an empty page.

Usually images will start breaking first and eventually Safari will simply display an empty page.

Sometimes, in Console, I will get the message "Debugger() was called".
Comment 1 Mark Rowe (bdash) 2009-05-14 04:21:47 PDT
The "Debugger() was called" message is an annoying yet harmless artifact from Flash 10, and is almost certainly unrelated to whatever problem you're seeing.
Comment 2 Colin Rotherham 2009-05-14 05:47:12 PDT
No problem, I'll remember that for next time.

I can confirm that this bug is not present in Safari 3.2.1 Mac OSX 10.5 or both Google Chrome and Google Chrome on Windows Vista.
Comment 3 Colin Rotherham 2009-05-14 05:51:48 PDT
This bug can be reproduced in Safari 4 Public Beta for Windows Vista
Comment 4 Colin Rotherham 2009-05-19 06:06:46 PDT
This also affects the latest nightly (Webkit r43841) running within Safari 3.2.1
Comment 5 Alexey Proskuryakov 2009-05-20 08:20:48 PDT
Confirmed with r43890.

In the last connection:didReceiveResponse: delegate call (for an main resource), we're getting a 304 Not Modified response, although the server properly sends 200 OK.
Comment 6 Alexey Proskuryakov 2009-05-20 08:54:23 PDT
Since the html pages are uncached, 304 means that we cannot display the result.

I think that this is not a WebKit bug.
Comment 7 Alexey Proskuryakov 2009-05-20 08:55:42 PDT
Comment 8 Colin Rotherham 2009-05-20 09:05:59 PDT
If it helps to determine if this is a Safari or WebKit bug, I've also tested the latest Chromium nightly on Mac (16482) and I can't reproduce it.
Comment 9 Alexey Proskuryakov 2009-05-20 09:15:14 PDT
Yes, Chromium uses a different network back-end.

Closing as INVALID as a non-WebKit issue per our policy. If it's later found to be a WebKit one (or something we can work around in WebKit), we can always reopen it. Thank you for reporting this problem!

To ask about the status of the investigation in the future, you can e-mail devbugs@apple.com, citing issue ID <rdar://problem/6906562>.
Comment 10 Colin Rotherham 2009-05-20 13:26:56 PDT
This bug doesn't affect Safari 3.2.1 but when I run a nightly (r43841) via this version of Safari the bug is reproducible. Doesn't this mean it is a WebKit issue?

I've filed it with Apple as problem ID 6907794.
Comment 11 Alexey Proskuryakov 2009-05-20 13:44:36 PDT
(In reply to comment #10)
> This bug doesn't affect Safari 3.2.1 but when I run a nightly (r43841) via this
> version of Safari the bug is reproducible. Doesn't this mean it is a WebKit
> issue?

It usually does, but in this case, I think that legitimate WebKit changes that improved caching behavior have uncovered an issue in the network back-end. We can't just undo the WebKit changes. I'm keeping an eye on the Radar bug to see if any workaround that we could use in the meanwhile is identified.
Comment 12 Alexey Proskuryakov 2009-05-23 01:04:01 PDT
This server sends incorrect 304 Not Modified responses. Not Modified responses must have empty bodies, but we get a 26-byte body that is a result of gzipping an empty input stream. This confuses persistent connection logic in our network back-end. Admittedly, other browsers are not confused, so it's still a bug.

You can see the server-side bug in action by monitoring the following request with tcpdump or Wireshark:

curl -i 'http://www.mydreammobile.com/js/index.php?c=auto&f=,prototype/prototype.js,prototype/validation.js,scriptaculous/builder.js,scriptaculous/effects-1.8.2.js,scriptaculous/dragdrop.js,scriptaculous/controls.js,scriptaculous/slider.js,varien/js.js,varien/form.js,varien/menu.js,mage/translate.js,mage/cookies.js,jquery/jquery-1.3.2.noConflict.min.js,phonestore.js' --header 'If-Modified-Since: Tue, 19 May 2009 15:47:39 GMT' --header "Accept-Encoding: gzip, deflate"
Comment 13 Colin Rotherham 2009-05-26 02:36:13 PDT
Thanks for the feedback.

I've temporarily disabled gzipping as a work-around for development. I can only presume Magento has a stray line break somewhere causing the extra 26 bytes.

PHP 5.3 will enforce an empty response according to this bug listing but unfortunately won't in our current version.
Comment 14 Colin Rotherham 2009-05-26 02:41:36 PDT
Specifically, it seems PHP's zlib.output_compression forces gzip compression for every response code (even 304). I've now turned this off.
Comment 15 Alexey Proskuryakov 2009-05-26 03:41:33 PDT
Thank you, that's very useful information.
Comment 16 Alexey Proskuryakov 2009-09-01 14:42:15 PDT
*** Bug 28863 has been marked as a duplicate of this bug. ***
Comment 17 kaminsky 2009-10-07 09:13:32 PDT
Why is this bug marked like "RESOLVED INVALID"?

We can reproduce it on all versions of Safari 4 (OS X 10.5, 10.6, Windows)

I had to temporary disable gzip and zlib output compression on the Apache side.

Our configuration is Apache 2.0.61 (Solaris) - mod_caucho - Java Applciation Server (Resin) - DB

We are having "blank screen" in Safari 4 if "Wait Page" is flushing very quickly.

We have 20K users on our application and we need gzip and zlib output compression to be ON.


Comment 18 Alexey Proskuryakov 2009-10-07 11:53:04 PDT
(In reply to comment #17)
> Why is this bug marked like "RESOLVED INVALID"?

That's is explained in comment 9 - this is something that needs to be fixed in Apple closed source libraries, so tracking this as a WebKit bug is useless. I encourage you to report this via <http://bugreport.apple.com> - the report will be closed as a duplicate, but additional information you will provide can help Apple's investigation (and the fact that many people are seeing this need to be communicated, as well).

> We have 20K users on our application and we need gzip and zlib output
> compression to be ON.

Look for comment 12 and below for a workaround - you don't need to disable gzip completely, you just need to stop the server from sending invalid responses. How exactly this can be done depends on your setup; certainly not every Apache server has this problem.