Closed
Bug 421186
Opened 18 years ago
Closed 18 years ago
Applescript: scripts that quit Camino sometimes terminate thereafter, toolbar only
Categories
(Camino Graveyard :: OS Integration, defect)
Tracking
(Not tracked)
VERIFIED
INVALID
People
(Reporter: lthompson.22, Unassigned)
Details
Attachments
(1 file)
|
2.54 KB,
application/zip
|
Details |
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.8.1.13pre) Gecko/20080305 Camino/1.6b3pre (like Firefox/2.0.0.13pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.8.1.13pre) Gecko/20080305 Camino/1.6b3pre (like Firefox/2.0.0.13pre)
The following script, when run from the toolbar, terminates once Camino is closed, ie. the Finder never shows the alert.
tell application "Camino" to quit
tell application "Finder"
activate
display alert "script done" message "" as informational buttons {"OK"} default button 1
end tell
If the "activate" statement is removed, however, the Finder does show the alert.
When run from the Camino script menu, the Finder shows the alert whether the activate statement is included or not.
So it's not like the script is being terminated immediately after and because of the quit statement. Neither is it just "activate" that triggers termination; sometimes multiple statements get executed before termination. I noticed this with a script involving long Finder operations after Camino has been quit -- the script terminates at some point before all operations are completed, although any operation that has begun will be completed. (Which sounds like a timeout issue, but then why would the activate command trigger termination? Plus the same script runs perfectly when called from the Camino script menu.) Unfortunately I could not find a generic test-script to demonstrate this.
But the difference in how a script involving a long operation behaves when called from the menu vs. the toolbar might be repeatable. Here's an example, which I'll upload as a script:
tell application "Camino" to quit
tell application "Finder"
set x to (((path to applications folder) as string) & "iTunes.app")
set y to (path to documents folder)
duplicate file x to y with replacing
display alert "script done" message "" as informational buttons {"OK"} default button 1
end tell
If called from the menu, Camino closes immediately and the Finder does its thing as expected. If called from the toolbar, the Camino window does *not* go away immediately, the spinning beach ball usually appears while the Finder makes the copy in the background, the Finder comes to the front to show the alert, and the Camino window does not close until the alert is dismissed.
That's as much as I could figure out.
Reproducible: Always
Steps to Reproduce:
1. see above
| Reporter | ||
Comment 1•18 years ago
|
||
Comment 2•18 years ago
|
||
I'm not sure I follow. If you are running the AppleScript from within Camino (which I don't think is what the script menu does; please correct me if I'm wrong), then if you quit Camino, having the script stop running seems like expected behavior.
Comment 3•18 years ago
|
||
I realized I left this without a question: can you give some real examples of cases where having a toolbar button that continues to run code after Camino has quit would be expected/necessary behavior?
Without a compelling argument to the contrary, this would be considered correct behavior and closed accordingly.
| Reporter | ||
Comment 4•18 years ago
|
||
My only expectation here was for consistency. If the expected behavior is for Camino to discontinue execution of a toolbar script after that script tells it to quit, then it seems odd that it does continue sometimes, depending on the code. That is, I would expect a script that quits Camino and then tells another application to do some things to either not do any of those things ever, or to do all of them always. If it never did any of them, if no statements subsequent to a quit ever got executed, then it would have been obvious what was going on and what the appropriate expectations were. But the fact that sometimes subsequent statements get executed and sometimes they don't, some scripts get completed and some don't, opened the door for thinking there was an issue here.
Comment 5•18 years ago
|
||
What happens if you run a similar script from within the Script Editor application itself? I'm not sure that Camino really has much control over this.
URL: n/a
Comment 6•18 years ago
|
||
AppleScrips can't runon their own, they need to be run by an application. When you run a script in Script Editor, Script Editor is running the script. When you make a script into an application, you get an app whose only purpose is to run the script. When you run a script from the Script Menu, the Script Menu app is running the script. When you run a script from the Camino toolbar, Camino runs it. That is to say, Stuart is right in comment 2.
As to why the script continues to run after it tries to quit the ap (Camino) that's running it, I have no idea. However, I'm inclined to call this acceptable, if not completely correct, behavior. Scripts run from the toolbar probably shouldn't be quitting Camino, unless it's the last thing they do.
If this really is an issue, however, we *could* stop toolbar scripts from quitting Camino. That sounds more like a loss of potentially useful functionality to me, though.
Comment 7•18 years ago
|
||
I think we're just going to call this invalid; having undefined behavior for the portion of a script after that script attempts to terminate its own host environment seems reasonable (and as far as I can tell, a function of the implementation of the AppleScript engine, and thus not really within our control).
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
Comment 8•18 years ago
|
||
Someone might want to file a bug on this with Apple, as it seems like a bug in AppleScript that a script can continue execution after its host is terminated.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•