Closed Bug 729446 Opened 12 years ago Closed 7 years ago

Firefox release doesn't quit when plugin loaded and asked to quit via AppleScript

Categories

(Firefox :: Shell Integration, defect)

Product:
Firefox
Component:
Shell Integration
Version:
10 Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: vishvesh.com, Unassigned)

References

Details

Attachments

(2 files)

Script file to test the issue
792 bytes, text/plain
Details
Debugging patch (*not* a fix)
461 bytes, patch
Details | Diff | Splinter Review 
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Build ID: 20120215223356

Steps to reproduce:

1. Launch a page, which launches a plug-in
2. Run the following command in Apple script editor: tell application "Finder" to quit application id "org.mozilla.firefox" (Attached the script file)

I used the following plug-in to test the issue
https://bugzilla.mozilla.org/attachment.cgi?id=540370

This issue is seen on Firefox 10.0.2.


Actual results:

Plug-in quits.


Expected results:

Firefox and the plug-in should have quit.
OS: Windows 7 → Mac OS X
Issue is seen on Snow Leopard(10.6.8) but not on Lion(10.7).
Benjamin, this is a blocker for our automation systems.  Workarounds are pretty ugly.  I just wanted to get it on your radar as something that we'd really appreciate a fix for.
This is MacOS 10.6-only? This appears to be an applescript error that we have no control over; the bundle ID of the plugin-container process is org.mozilla.plugincontainer and so applescript appears to have a bug...
Component: Untriaged → Shell Integration
In testing for bug 689764, I found that the following AppleScript worked just fine with the then current Firefox nightly on OS X 10.6.8, after I loaded my DebugEventsPlugin from bug 441880.

tell application id "org.mozilla.nightly"
    quit
end tell

The AppleScript attached to this bug is in binary format, so I can't tell exactly what it is.

Furthermore, and very interestingly, the failure here resembles the failure I reported in bug 689764 comment #10, testing with a patched/hacked nightly whose plugin-container binary had its bundle id changed from "org.mozilla.plugincontainer" to "org.mozilla.nightly".
I wouldn't be surprised if this bug is a side effect of the patch for bug 694039, which landed after I did the tests for bug 689764.

Bug 694039 probably can't just be backed out, and even altering it will be tricky.

But before I make this bug block bug 694039, I need to confirm this bug report.
I just tested with today's mozilla-central nightly, after loading my DebugEventsPlugin from bug 441880.  I couldn't reproduce it.

I used the AppleScript from comment #4, running it in the AppleScript Editor.  I tested on OS X 10.6.8, fully updated.
Jeromie:

What Flash plugins can this bug be reproduced with?  What versions of Firefox did you test with?  Did you, like Vishvesh, find that the bug only happens on OS X 10.6.8?
> What Flash plugins

What Adobe plugins
I can't reproduce this with the current version of Flash (testing in today's mozilla-central nightly on OS X 10.6.8).  Here are the links I tested with:

http://mirrors.creativecommons.org/
I passed this on on behalf of our automation team.  I'll ask them to chime in with testing details.
(In reply to Steven Michaud from comment #4)
> In testing for bug 689764, I found that the following AppleScript worked
> just fine with the then current Firefox nightly on OS X 10.6.8, after I
> loaded my DebugEventsPlugin from bug 441880.
> 
> tell application id "org.mozilla.nightly"
>     quit
> end tell
> 
> The AppleScript attached to this bug is in binary format, so I can't tell
> exactly what it is.
> 
> Furthermore, and very interestingly, the failure here resembles the failure
> I reported in bug 689764 comment #10, testing with a patched/hacked nightly
> whose plugin-container binary had its bundle id changed from
> "org.mozilla.plugincontainer" to "org.mozilla.nightly".

I am sorry, If I missed out on something. You can download the script by right clicking the attachment and selecting "save link as"
I just re-read comment #0, and now realize that it does contain the full text of an AppleScript:

tell application "Finder" to quit application id "org.mozilla.firefox"

Interestingly, when I run *this* in the AppleScript editor, I see the bug as reported -- the plugin-container process running my DebugEventsPlugin gets killed, but Firefox keeps running.

I think this must be a bug in Apple's AppleScript implementation on OS X 10.6.8, perhaps triggered by our patch for bug 694039.

It has a very easy workaround -- just reformat the script a bit to make it match my script from comment #4.

Since this only happens on OS X 10.6.8 and has an easy workaround, I'm tempted to mark this WONTFIX.  What do you think, Benjamin?
Spoke too soon, but I still think this is WONTFIX:

These AppleScripts trigger the bug (though only in non-release builds):

tell application "Finder" to quit application id "org.mozilla.firefox"
Spoke too soon again, and submitted the previous comment before it was finished.

This bug doesn't happen with non-release builds, with correct AppleScripts -- ones that correctly refer to a non-release build's bundle id (which hasn't been org.mozilla.firefox for a long time).

But it *does* happen with release builds, whose bundle id is (and long has been) org.mozilla.firefox.

It doesn't matter whose syntax you use for the AppleScript, mine or Vishvesh's.

I'm still tempted to mark this WONTFIX (since it only effects SnowLeopard).  But let me at least check if the patch for bug 694039 is involved.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Bug 693049 is definitely involved here.  In my next comment I'll post a debugging patch that disables a small part of that patch, and fixes this bug.

My patch is almost certainly not an acceptable fix.  And finding one will probably be a lot of work.  So we should seriously consider marking this bug WONTFIX.
Blocks: 694039
Summary: Firefox doesn't quit when asked to quit via AppleScript → Firefox release doesn't quit when plugin loaded and asked to quit via AppleScript
This patch "fixes" the problem in current trunk code, but it's almost certainly not an acceptable fix.

To see this bug in a current nightly:

1) Edit its Contents/Info.plist file to change its CFBundleIdentifier from "org.mozilla.nightly" to "org.mozilla.firefox".
2) Run the hacked build.
3) Load a plugin (e.g. one from http://mirrors.creativecommons.org/).
4) Paste one of the following scripts into AppleScript Editor and run it:

tell application id "org.mozilla.firefox"
    quit
end tell

tell application "Finder" to quit application id "org.mozilla.firefox"

On OS X 10.6.8, the plugin-container process will quit -- not the Firefox host process as should be.

In a few hours (or tomorrow morning) I'll post a tryserver build made with my patch, with which the previous STR doesn't cause the bug.
> 3) Load a plugin (e.g. one from http://mirrors.creativecommons.org/).

Actually this is wrong.  The STR does work (you see the bug) with my DebugEventsPlugin from bug 441880.  So it's possible this bug only happens with plugins that use the CoreGraphics drawing model (as my plugin does).

Flash and Silverlight and most other major plugins use one of the CoreAnimation drawing models.
We really need to hear from the Adobe people which of their plugins is effected by this bug.
We're running into this on the Flash Player team.
We are seeing the bug intermittently in our testing. But, when the bug does occur, these are the steps to reproduce it:

Install the current public Flash Player - http://get.adobe.com/flashplayer/
Clear everything in the Firefox cache. Restart
Load some Flash content - http://www.adobe.com/products/creativesuite.html?promoid=JOLIS
Note the Firefox and plugin processes in Activity monitor.
Run the osascript to quit org.mozilla.firefox

Notes: Clearing the cache seems to be the critical piece for us to get it to fail. Rerunning without clearing the cache does not trigger the bug
Try as I might, I can reproduce this bug in a Firefox release with any Flash plugin, using either of the following two AppleScripts:

tell application id "org.mozilla.firefox"
    quit
end tell

tell application "Finder" to quit application id "org.mozilla.firefox"

Clearing the Firefox network cache and restarting doesn't help (and I can't see how that could make any difference).

Neither does rebuilding the Launch Services database, using the following command:

   /System/Library/Frameworks/CoreServices.framework/Frameworks/
      LaunchServices.framework/Support/lsregister -kill -r
      -domain local -domain system -domain user
Here's a build of Firefox 19 hacked with my patch from comment #16.  Please test with it.

http://people.mozilla.com/~stmichaud/bmo/firefox-19.0-729446-debug.dmg

> Run the osascript

What's this?
> Run the osascript

>>What's this?

Sorry, command line way to run an applescript:
osascript -e 'tell application "Finder" to quit application id "org.mozilla.firefox"'
(Following up comment #21)

> Try as I might, I can reproduce ...

Of course this should be *can't* reproduce ...
I tried the osascript -e command with Vishvesh's AppleScript.  It makes no difference to my results.
I was able to get somewhat consistent failures by clearing the cache and rebooting the computer, then running a YouTube video:
http://www.youtube.com/watch?v=9RQ74cAZT1M as a shortcut on the desktop (first content in the browser)

then osascript -e 'tell application "Firefox" to quit' This is what we use in our automation. I'm assuming it's functionally equivalent to the other methods.

I have a software demo movie of the failure, but the file is too big for an attachment here.
I would not assume that 'application "Firefox"' is equivalent to 'application id "org.mozilla.firefox"'. Please try with org.mozilla.firefox.

But also, are you seeing this on 10.6-only, or also on 10.7/10.8?
If you haven't changed the name of Firefox.app to something else, 'tell application "Firefox" to quit' should work just as well as 'tell application id "org.mozilla.firefox" to quit'.

I can't reproduce this bug with either when a Flash plugin is loaded.

I *can* reproduce with my DebugEventsPlugin from bug 441880.

Please test with my build from comment #22, to see if it makes any difference to you.

And also tell us if you only see this bug on 10.6.
Yes, 10.6 only. More on the others requests later
I'm unable to get the failure so far with the special build. I was able to get the failure with the release build using either application "Firefox" or application id "org.mozilla.firefox" I have screen demos of both.
We can't do what my debugging patch from comment #16 does (which partially backs out the patch for bug 693049) -- at least so far as I know.  And we are (or should be) reluctant to spend lots of time trying to fix a bug that only happens on OS X 10.6.8 and effects a very small number of users.

So here's a suggestion:

How about we create an about:config setting that optionally allows the behavior of my patch from comment #16?  Of course the default for this setting would be "off" (we'd default to current behavior).  And turning it "on" is likely to have bad side effects.  But having this setting might be convenient for some of our users.

What do people think?
Hi Steven, an about:config setting would work for me. Thank you for your attention to this issue.
What do you think, bsmedberg?
Flags: needinfo?(benjamin)
I have no opinion.
Flags: needinfo?(benjamin)
Not a shell integration bug and no activity in years so resolving -> incomplete
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: