Bug 581 : Processing sketches don't restart after switching pages in Safari
Last modified: 2008-08-16 15:00




Status:
RESOLVED
Resolution:
FIXED -
Priority:
P2
Severity:
normal

 

Reporter:
ianli
Assigned To:
fry

Attachment Type Created Size Actions

Description:   Opened: 2007-06-15 15:12
Hi Ben-

I found a problem with my Processing applets when using Safari. The
Processing applet would stop being interactive after switching tabs.
Here's an example to demonstrate the problem.

1. Open http://ianli.com/moodjam/timeline.html (use the scrollbar at
the bottom to interact with it)
2. Create a new tab and open http://ianli.com/moodjam/searchable.html
3. Go back to the first page you opened, and notice that it's not
interactive anymore.

Notes:
* This only happens in Safari and when using tabs.
* The problem doesn't happen when I embed a PApplet in a JApplet, such
as in http://ianli.com/moodjam/stargist.html

I don't know if you're aware of this problem, but I thought to give
you a heads up.

Thanks,
Ian
Additional Comment #1 From ewjordan 2007-07-16 00:18
Just confirmed this one on my Mac - if you open up the console in Safari,
what's happening is that it's stopping the applet when you leave the page,
and it's not reinitializing it when you return (it's calling start, but
nothing restarts). In Firefox, the applet is never stopped at all upon a
tab switch, it keeps running in the background - with OpenGL applets (on OS
X, at least), this is actually a bit of an irritation because the graphics
continue to be drawn even if you've switched tabs. I'm honestly not sure
what the "correct" behavior is, and frankly, I suspect there's really no
clear answer since applets have always been shunned by the web standards
fanatics, so this difference in behavior may be with us for quite some time...

If I had to venture a guess, the reason for the tab switching problem at
hand is that PApplet.stop() sets finished to true, whereas PApplet.start()
does not set it back to false, so we're getting bounced right out of the
run() function. I see in the source for stop() the line:

finished = true; // why did i comment this out?

and I suspect that perhaps this might be the reason.

I'll check when i get the chance, but I think simply setting finished to
false in start() might do the trick (though there's also the issue of
stop() disposing the graphics context, which might cause problems in OpenGL
- this might be a bit tricker to resolve, since I don't know if it's safe
to reclaim it in start()).
Additional Comment #2 From fry 2008-08-16 14:57
k, setting finished to false in start() for 0147. please post a followup if
that doesn't fix things.