An issue in both Safari 3.0.4 and WebKit nightly on Mac OS X 10.4.11, Intel MacBook Pro. I can reproduce the issue in WebKit-based OmniWeb-5.6-v613 (2007-10-24, revision 93354). I can *not* reproduce the issue in Camino 1.5.3 or Firefox 2.0.0.9. I'll attach screen shots to demonstrate.
Whilst I can *not* reproduce in Camino or Firefox, on 2007-09-21 I *did* reproduce the issue in old unsupported Internet Explorer 5.2.3. Internal reference [sussex.ac.uk #17351].
Created attachment 17459 [details] proper rendering 01 in Camino 2007102517 (1.5.3)
Created attachment 17460 [details] proper rendering 02 in Camino 2007102517 (1.5.3)
Created attachment 17461 [details] proper rendering 03 in Camino 2007102517 (1.5.3)
Created attachment 17462 [details] unpredictable rendering 01 in WebKit nightly r27953
Created attachment 17463 [details] unpredictable rendering 02 in WebKit nightly r27953
Created attachment 17464 [details] unpredictable rendering 03 in WebKit nightly r27953
Created attachment 17465 [details] unpredictable rendering 04 in WebKit nightly r27953
This looks like an issue loading (or not loading) stylesheets. Graham, are there errors in the Activity WIndow (select "Activity" from the "Window" menu, or hit Cmd-Opt-A) related to stylesheet URLs when this happens?
Confirmed with a local debug build of WebKit r27971 with Safari 3.0.4 (523.12) on Mac OS X 10.4.11 (8S165). This is strange behavior...it's like FOUC without the "FO", or maybe it's PUC (Partially Unstyled Content). http://webkit.org/blog/66/the-fouc-problem/
Safari 2.0.4 with original WebKit on Mac OS X 10.4.11 (8S165) has similar issues--it sometimes renders the page without having all of the stylesheet information (although it seems to show the wrong font more times than not changing bullet lists into tabs). This is not a regression.
Looks like a server-side problem. I noticed that the size of one of the stylesheets is different between the correct and broken rendering. I saved both versions and here are the differences: --- ploneStyles5860_big.css 2007-11-23 09:15:28.000000000 -0800 +++ ploneStyles5860_small.css 2007-11-23 09:15:18.000000000 -0800 @@ -454,7 +454,7 @@ } /* */ .LSRes { -font-family: "Lucida Grande", Verdana, Lucida, Helvetica, Arial, sans-serif; +font-family:
My comment got truncated for some reason. Re-sending. Looks like a server-side problem. I noticed that the size of one of the stylesheets is different between the correct and broken rendering. I saved both versions and here are the differences: [will post the differences separately since Bugzilla can't handle them] It looks like the server fails to make certain substitutions in some cases. Using curl I couldn't get the "broken" version of the stylesheet, so it may be the case that the server sends it (sometimes) only to Safari.
Created attachment 17466 [details] Stylesheet diff
(In reply to comment #13) > My comment got truncated for some reason. Re-sending. > > Looks like a server-side problem. I noticed that the size of one of the > stylesheets is different between the correct and broken rendering. I saved both > versions and here are the differences: > > [will post the differences separately since Bugzilla can't handle them] Are there high-bit characters in the diff?!
(In reply to comment #15) > (In reply to comment #13) > > My comment got truncated for some reason. Re-sending. > Are there high-bit characters in the diff?! Actually, there appear to be null characters (^@) before and after the numbers after font-face rules in the file. This can only be seen by doing the following: 1. Load the test URL. (Make sure it renders incorrectly.) 2. Open the Activity Window. 3. Double-click on the ploneStyles5860.css URL. 4. Select all (Cmd-A). 5. Copy (Cmd-C). 6. In a terminal window: cat > ploneStyles5860.css 7. Paste (Cmd-V). 8. End cat command: Ctrl-D 9. View source file using less in Terminal: less ploneStyles5860.css
(In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #13) > > > My comment got truncated for some reason. Re-sending. > > Are there high-bit characters in the diff?! > Actually, there appear to be null characters (^@) before and after the numbers > after font-face rules in the file. There are also null characters around the "bad" url() rules. I have confirmed that the null characters are present in the TCP packets before they get to WebKit. Another interesting thing I noticed is that the ploneStyles5860.css stylesheet is requested on a keep-alive (kept-alive?) connection after the main URL is requested. Assuming some "badness" is happening on the server-side (like some variables not being reset properly), this may explain why command-line curl doesn't reproduce the issue.
This is definitely a server-side concurrency issue. Using the Apache HTTP server benchmarking tool ("ab"), you can see that the server sends different content when concurrent connections are used. (For whatever reason, Safari seems to trigger this behavior much more frequently than Camino or Firefox.) First, let's run ab with verbosity level 4 (-v 4), with keep-alives on (-k) and with 8 requests (-n 8), which are run sequentially (or with a concurrency of zero). All Content-Length headers should return 73438: $ ab -v 4 -k -n 8 http://www.nltg.brighton.ac.uk:8080/share/dmd/portal_css/Plone%20Default/ploneStyles5860.css | grep '^Content-Length' Content-Length: 73438 Content-Length: 73438 Content-Length: 73438 Content-Length: 73438 Content-Length: 73438 Content-Length: 73438 Content-Length: 73438 Content-Length: 73438 Now let's run the same command, but change the concurrency to 4 (-c 4) so that four http requests are made at once for the same URL (although this is only done twice since we asked for 8 requests total): $ ab -v 4 -k -n 8 -c 4 http://www.nltg.brighton.ac.uk:8080/share/dmd/portal_css/Plone%20Default/ploneStyles5860.css | grep '^Content-Length' Content-Length: 73251 Content-Length: 73360 Content-Length: 73288 Content-Length: 73487 Content-Length: 73489 Content-Length: 73487 Content-Length: 73426 Content-Length: 73251 Looks like there is a concurrency issue when serving ploneStyles5860.css to multiple requests. :( It's interesting that some requests are less than 73438, while others are more than the expected value. Marking this as an evangelism bug since the server-side needs to be fixed. Graham, please mark this bug as RESOLVED/FIXED when you've got the server-side issue resolved. Thanks!
Wow, I'm impressed by the speed and focus of your responses! Many thanks. I'll draw the server administrator's attention to the notes here, let's see what can be done ...
(In reply to comment #9) > Graham, are there errors in the Activity WIndow (select "Activity" from the > "Window" menu, or hit Cmd-Opt-A) related to stylesheet URLs when this happens? Spot on. For reference only, here's a note that I took in September: http://pastebin.ca/705739
The reported site is off line. So I think we should close the bug.
Also, http://www2.nltg.brighton.ac.uk:8080/share/dmd/ (a redirect from bug URL with port removed) looks fine.
Thanks. I'll draw the attention of the Plone server administrator to the resolution. In any case AFAIK an upgrade to the Plone installation may occur.