Bug 25786 – Pages/images failing to load after 3-5 pages of navigation

• Component: Page Loading
• Status: RESOLVED INVALID

[Colin Rotherham]

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

[Mark Rowe (bdash)]

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.

[Colin Rotherham]

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 1.0.154.65 and Google Chrome 2.0.172.23 on Windows Vista.

[Colin Rotherham]

This bug can be reproduced in Safari 4 Public Beta for Windows Vista

[Colin Rotherham]

This also affects the latest nightly (Webkit r43841) running within Safari 3.2.1

[Alexey Proskuryakov]

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.

[Alexey Proskuryakov]

Since the html pages are uncached, 304 means that we cannot display the result.

I think that this is not a WebKit bug.

[Alexey Proskuryakov]

<rdar://problem/6906562>

[Colin Rotherham]

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.

[Alexey Proskuryakov]

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 [e-mail], citing issue ID <rdar://problem/6906562>.

[Colin Rotherham]

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.

[Alexey Proskuryakov]

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

[Alexey Proskuryakov]

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"

[Colin Rotherham]

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.
http://bugs.php.net/bug.php?id=42362

[Colin Rotherham]

Specifically, it seems PHP's zlib.output_compression forces gzip compression for every response code (even 304). I've now turned this off.

[Alexey Proskuryakov]

Thank you, that's very useful information.

[Alexey Proskuryakov]

*** Bug 28863 has been marked as a duplicate of this bug. ***

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.


Thanks,

LK

[Alexey Proskuryakov]

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