Currently Being ModeratedJul 23, 2011 7:20 AM (in response to Jonathan Pool)
It has nothing to do with Safari or Webprocess or Little Snitch. It is the webcontent itself that makes Safari immediately go to 100% CPU, and you have to (force) quit Safari and not go there anymore!
Currently Being ModeratedJul 23, 2011 8:10 AM (in response to LexSchellings)
What you really have to do is use another browser. Amaya and Opera also choke on this page. But Camino, Chrome, Firefox, iCab, OmniWeb, SeaMonkey, and Sunrise all display it and make its controls available rapidly.
So I don't understand why it has nothing to do with Safari. Safari up to 5.0 also had no difficulty with this page.
Safari with the latest nightly build of WebKit is still bad.
Currently Being ModeratedJul 28, 2011 7:13 AM (in response to Jonathan Pool)
Safari 5.1 and “WebProcess”: PROBLEM SOLVED
The culprit is “Little Snitch”
I am running OS 10.6.8 (Lion-ready). Yesterday, I installed the Safari updater from 5.0.5 to 5.1 . . . and am experiencing repeated and annoying pop-up windows for "WebProcessing."
I found the culprit to be the third-party utility "Little Snitch" — which monitors outgoing internet connections. (http://www.obdev.at/products/littlesnitch/index.html).
I solved the problem by upgrading (FREE) Little Snitch v2.0.x to v2.4 (for Snow Leopard and Lion).
Currently Being ModeratedJul 28, 2011 8:26 AM (in response to David_Purnell)
PROBLEM NOT SOLVED
This solution is not a solution to the problem. It may solve a different problem, but not the one about which this discussion is being conducted.
If you report that http://panlex.org/u loads within 10 seconds and you can then start tabbing through the submission buttons and scrolling down the page as long as you have Little Snitch installed, then we'll have surprising information relevant to the problem. Is that in fact the case?
Currently Being ModeratedJul 28, 2011 8:58 AM (in response to Jonathan Pool)
Sorry Jonathan. I thought the problem I'd encountered and solved might be related to what you're experiencing.
I just tried http://panlex.org/u in Safari (5.1). The page loads, but then hangs up. I can't scroll or tab through the table.
Then, I opened the same URL in Firefox (5.0.1), and it worked fine. I was able to scroll down the page.
Currently Being ModeratedJul 28, 2011 9:02 AM (in response to David_Purnell)
Thanks for testing, David. Yes, I get the same result as you. See above, where I list several browsers that load this page OK.
If you just let the window sit there, I think you'll find that after 1-2 minutes the page will be fully loaded by Safari 5.1 and you can tab and scroll.
Currently Being ModeratedAug 12, 2011 10:17 PM (in response to Jonathan Pool)
I think this is related to a webkit bug with large tables and border-collapse:collapse that I saw in Chrome a while back. Here's the bug I filed with Google. http://code.google.com/p/chromium/issues/detail?id=68215
Here's an interesting thing I'm seeing on http://panlex.org/u I'm seeing the slowness, same as you, but using the Developer tools, if I turn off the border-collapse:collapse CSS rule the page becomes seemingly normal again. You can even re-enable the border-collapse rule and the page remains fast.
I think this may be a bug with webkit that's now shared in Chrome and Safari.
Currently Being ModeratedAug 13, 2011 2:40 AM (in response to Jonathan Pool)
There is a bug report for this in the webkit bug tracker. If you register and add a comment to it, it may help it to get resolved.
Here's another example which exhibits the bug:
Currently Being ModeratedAug 13, 2011 7:35 AM (in response to chad von nau)
Thanks for helping diagnose this.
However, my testing indicates that this is not a bug with border-collapse: collapse. Here is why:
If I change the value of border-collapse to "separate" and add "border-spacing: 0", the bug remains. To try this, request http://www.panlex.org/cgi-bin/plxu28-bug2.cgi .
If I leave the value of border-collapse unchanged but change the button elements in the cells to plain text, the bug disappears. To try this, request http://www.panlex.org/cgi-bin/plxu28-bug1.cgi .
On the basis of this testing, it would seem to me that the bug is dependent on the button elements and independent of the border-collapse CSS attribute.
This doesn't explain, however, why you have found border-collapse: collapse producing slow results with other large tables and it doesn't do so with my table in http://www.panlex.org/cgi-bin/plxu28-bug1.cgi . It also doesn't explain why you saw the bug disappear when you changed border-collapse on my page but I didn't see it disappear.
Any further diagnostic help would be welcome.