Bug 30285 - Going to the linked URL hangs Webkit 100% of the time
Summary: Going to the linked URL hangs Webkit 100% of the time
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: Java (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.6
: P2 Critical
Assignee: Nobody
URL: http://www.nondot.org/MagicStats/stats
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2009-10-11 12:43 PDT by Sulka Haro
Modified: 2009-11-11 21:12 PST (History)
3 users (show)

See Also:


Attachments
sample of hang (46.01 KB, text/plain)
2009-10-11 13:28 PDT, Gavin Sherlock
no flags Details
Reduction (8.94 KB, text/html)
2009-10-11 20:25 PDT, Daniel Bates
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sulka Haro 2009-10-11 12:43:54 PDT
Webkit gets an infinite beachball of deal when I go to the linked page. The problem seems to be caused by Java, but I guess with the sandboxing and all, the page shouldn't be able to take down the whole browser.

As an added bonus, the page and the applet is authored by an Apple employee. ;)
Comment 1 Gavin Sherlock 2009-10-11 13:28:31 PDT
Created attachment 41003 [details]
sample of hang
Comment 2 Gavin Sherlock 2009-10-11 13:29:32 PDT
I get it too, on a stock 10.6.1 install with Safari Version 4.0.3 (6531.9), with java being:

java version "1.6.0_15"
Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219)
Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-90, mixed mode)
Comment 3 Gavin Sherlock 2009-10-11 13:32:49 PDT
Note, also hangs r49412.  Problem is likely Java than webkit, though would be nice if Java ran in a separate process like plug-ins do, so it couldn't hang the browser.
Comment 4 Daniel Bates 2009-10-11 20:25:38 PDT
Created attachment 41012 [details]
Reduction

Here is a reduction.

The issue seems to occur when their are at least two instances of an applet that references the same class file and the class file is either missing (HTTP response code 404) or cannot be accessed (HTTP response code 403). If you try to perform some kind of UI action such as scrolling the page or try to navigate to another page you will get the spinning wheel.  

Remarks:

Programmatically trying to scroll the page or performing some kind of JavaScript action (like alert(), writing to the DOM, or navigating to another page) even after a set amount of time seems to prevent the UI from locking up, which makes me think this may have something to do with locks we may be holding (and not properly releasing).
Comment 5 Daniel Bates 2009-10-11 20:39:40 PDT
Ok, the reduction does not seem to produce a hang when run on bugs.webkit.org. 

But, if you click on the reduction, wait for the Java applets to load (and error because they can't find the non-existent dummy.class) then try to navigate to another web site, say http//www.apple.com. This will produce a crash.

(In reply to comment #4)
> Created an attachment (id=41012) [details]
> Reduction
Comment 6 Daniel Bates 2009-10-11 21:12:25 PDT
Cannot reproduce crash in latest nightly (r49412), but can reproduce hang by downloading the test to my machine and running a local Apache server.

This is straight forward to do on a Mac.

1) Open System Preferences -> Sharing
2) Turn on Web sharing
3) Download the reduction file above to the folder ~/Sites, name it reduction.html
4) Open the latest nightly build of Safari (r49412) and go to http://localhost/~substitute_your_username_here/reduction.html

Follow the instructions in the reduction to reproduce the hang.

(In reply to comment #5)
> Ok, the reduction does not seem to produce a hang when run on bugs.webkit.org. 
> 
> But, if you click on the reduction, wait for the Java applets to load (and
> error because they can't find the non-existent dummy.class) then try to
> navigate to another web site, say http//www.apple.com. This will produce a
> crash.
> 
> (In reply to comment #4)
> > Created an attachment (id=41012) [details] [details]
> > Reduction
Comment 7 Daniel Bates 2009-10-11 23:39:05 PDT
Oops, assigned myself to the wrong bug.
Comment 8 Daniel Bates 2009-11-11 21:10:49 PST
<rdar://problem/7387825>
Comment 9 Daniel Bates 2009-11-11 21:12:46 PST
With Mark's help, we have determined that this is a Java bug and it has been filed in radar.