Closed
Bug 1127514
Opened 10 years ago
Closed 9 years ago
AppleScript calls to "FireFox" are directed to "plugin-container" when Flash is activated and thus fail
Categories
(Firefox :: Shell Integration, defect, P1)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: emelin.hocker, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: regression, regressionwindow-wanted, Whiteboard: AppleScript)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150122214805
Steps to reproduce:
Compile and execute this simple AppleScript:
tell application "Firefox"
name of front window
end tell
If you have the flash-plugin activated, you get the following error:
Actual results:
==> error "plugin-container got an error: Can’t get name of window 1." number -1728 from name of window 1
Expected results:
We should get the name of the frontmost window.
Comment 1•10 years ago
|
||
I'm also experiencing this. Firefox 34 and above reports incorrect application identification to applescript when plugin container is running. Many existing applescripts are broken because of it; specifically, any script that uses a variable to hold the application name will fail.
I haven't been able to find a relevant change/bug that caused it. It's not present in Firefox 33. It started with 34, and is present in 35, 36 beta, and aurora. It happens on OS X 10.9 and 10.10 (not tested on earlier OS versions).
Additional examples: with Firefox 34+ open, and a page with Flash loaded, eg. http://www.adobe.com/software/flash/about/
example 1: enter the following into Script Editor:
tell application "Firefox"
activate
open location "http://www.example.com"
end tell
...and choose Run, Compile, or Save. The string "Firefox" gets replaced with "plugin-container". It's not possible to run or save the script with the string "Firefox" in it. Running it from within Script Editor seems to open the URL in the default browser (which may or may not be Firefox), while running it as a saved application simply fails. Quitting Firefox, or running it with no plugin active, allows you to Run, Compile, or Save normally, and the resulting script works correctly, even when Firefox is open with plugin container active. Presumably Firefox's unique application identifier is compiled into the script. Existing scripts compiled with 'tell application "Firefox"' as a literal string, will continue to work.
example 2: enter the following into Script Editor
set myBrowser to "Firefox"
tell application myBrowser
activate
open location "http://www.example.com"
end tell
...in this case you can successfully Compile and Save the script. Running it fails when plugin container is active, and succeeds when it's not. Again, running it from within Script Editor seems to open the URL in the default browser (which may or may not be Firefox), while running it as a saved application simply fails, if plugin container is active. Presumably the application identifier is determined at runtime. All existing scripts that use a variable to hold the browser application name will fail when plugin container is active.
example 3: enter the following into Script Editor and save as an application:
set myBrowser to "Firefox"
display dialog (name of application myBrowser as text)
display dialog (path to application myBrowser as text)
display dialog (id of application myBrowser as text)
...when Firefox is running with plugin container active, the results will show the name as "plugin-container" and the path as eg. MyComputer:Applications:Firefox.app:Contents:MacOS:plugin-container.app: and the bundle id as org.mozilla.plugincontainer. When plugin container is not active, the results show the name as Firefox, and the correct path, and org.mozilla.firefox bundle id.
-----------------
There are some possible work-arounds, but they have drawbacks, and require existing scripts to be re-written:
- use the bundle id, eg.:
set myBrowserID to "org.mozilla.firefox"
tell application id myBrowserID
activate
open location "http://www.example.com"
end tell
...but this is less intuitive for users to specify their browsers, and can't distinguish between multiple instances of Firefox that may be installed, eg. a release and beta version.
- use the full path:
set myBrowser to "/Applications/Firefox.app"
tell application myBrowser
activate
open location "http://www.example.com"
end tell
...this works, but again is less intuitive for users, will break if the application is moved, and requires re-writing if the name of the application is used in the script, eg.:
display dialog "Do you want to open this URL in " & myBrowser
must be changed to:
display dialog "Do you want to open this URL in " & (name of application myBrowser as text)
So, hopefully this could be reverted back to the previous behaviour in Firefox 33 and earlier. Thanks...
Status: UNCONFIRMED → NEW
Component: Untriaged → Shell Integration
Ever confirmed: true
Keywords: regression
Version: 35 Branch → Trunk
Comment 2•9 years ago
|
||
I've just started experiencing the bug as noted above. When the bug triggers I also get problems starting Firefox normally. I get the warning about Firefox not started correctly and asking me if I want to do a "refresh". I'm also locked out from saving the script at all (causes error) until I QUIT Firefox. Then I can edit and save the script again. Extremely annoying.
Updated•9 years ago
|
Keywords: regressionwindow-wanted
Comment 3•9 years ago
|
||
spohl, I'm wondering if you might have any speculations on what could have caused this regression? bsmedberg thought that bundle identifiers could be a candidate...
Flags: needinfo?(spohl.mozilla.bugs)
Comment 4•9 years ago
|
||
My best guess (and without trying for myself) is that something related to the changes for Apple's v2 signatures may have caused this (see bug 1046906 and dependents).
Flags: needinfo?(spohl.mozilla.bugs)
Comment 5•9 years ago
|
||
Paul, can try to track this down with mozregression?
Flags: needinfo?(paul.oiegas)
Comment 6•9 years ago
|
||
Hi Emelin, I was trying to reproduce this issue on latest Nightly 45.0a1 and Release 42.0 builds and could not reproduce it on my side.
I have installed Flash Player on MacOS 10.9 and while watching a YouTube video I ran the provided Apple script. The title of the tab was correctly returned.
However, I installed also Firefox Release 34.0 to 37.0 including, and while executing the same steps, I did received the same error you mentioned.
In my opinion this issue was fixed along the way. Can you please test this on latest builds and confirm that too ?
Flags: needinfo?(paul.oiegas) → needinfo?(emelin.hocker)
Hello there!
Unfortunately, executing the simple 3-lined apple-script of my initial bug report above, STILL throws the very same error on Firefox 42.0.
This bug has quite a long standing now and obviously has NOT gracefully vanished 'en passant'.
Great to see that is being taken care of, now.
All best,
Emelin
Flags: needinfo?(emelin.hocker)
Comment 8•9 years ago
|
||
Hello !
I would be glad to help you more if you can provide me a few more details. The OS you are using is still the same (OS X 10.9)? Is your Flash plugin updated to the latest version (19.0 r0) ? Did you tried to reproduce this issue with a new Firefox profile and with disabled addons (safe mode maybe)?
It would help us a lot if you can please provide a screen recording while reproducing the issue, or some screenshots. Maybe I'm doing something different than you.
Thanks,
Paul.
Flags: needinfo?(emelin.hocker)
Comment 9•9 years ago
|
||
Due to the fact that the reporter did not provided more information on my request and the fact that I cannot reproduce this on my end, I am updating this issue as Resolved - Incomplete.
If you can still reproduce this and you have more details on how to reproduce it, feel free to reopen it providing the details.
Thanks,
Paul
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(emelin.hocker)
Resolution: --- → INCOMPLETE
Reporter | ||
Comment 10•9 years ago
|
||
Indeed, after about a year, this bug has gone.
Cannot reproduce here either with FireFox 43.0.4 on OSX 10.10.5 running on two different machines. Yippee!
Resolution: INCOMPLETE → WORKSFORME
Comment 11•8 years ago
|
||
Hello,
I have noticed the same problem as described in the first comment in FirefoxDeveloperEdition 49.0a2 (2016-06-16).
Should I open a new ticket?
For reference:
tell application "FirefoxDeveloperEdition"
name of front window
end tell
produces:
error "plugin-container got an error: Can’t get name of window 1." number -1728 from name of window 1
The error does not happen in the regular version of Firefox (tested on 47.0).
You need to log in
before you can comment on or make changes to this bug.
Description
•