Open Bug 490762 Opened 14 years ago Updated 5 months ago

activate breaks AppleScript support


(Core :: Widget: Cocoa, defect)





(Reporter: bugzilla, Unassigned)


User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/528.16 (KHTML, like Gecko) Version/4.0 Safari/528.16
Build Identifier: 3.0.10

Elliotte Rusty Harold found this.  Basically, sending "activate" via AppleScript seems to break the AppleScript support for Firefox 3.0 and 3.5.

The workaround is to not call "activate" if you don't need to.  In the example script, you don't really need to call "activate" to get the URL and Title from Firefox.

Reproducible: Always

Steps to Reproduce:
Example script:
tell application "Firefox"
    set Link to get «class curl» of window 1 as text
    set theTitle to «class pTit» of window 1 as text
    {Link, theTitle}
end tell

After you run this (speciifcally the activate call) further calls to the
regular script

tell application "Firefox"
    set Link to get «class curl» of window 1 as text
    set theTitle to «class pTit» of window 1 as text
    {Link, theTitle}
end tell

(no activate) also break.
Actual Results:  
The script fails.

Expected Results:  
The script should finish successfully.
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
Component: General → Widget: Cocoa
QA Contact: general → cocoa
No longer blocks: 427448
I don't think this blocks 427448, but it is related to it.  427448 can proceed because it is fixing some functionality that broke which is critical to third party applications.  We can work on fixing this separately.
No longer blocks: 427448
We encountered a loosely-related bug in Camino a while ago, bug 415510.

In your case, this is because you have an empty scripting dictionary.  Within the Cocoa context, "activate" (and possibly certain other commands, were you to have anything in your scripting dictionary) takes you out of the built-in (AppKit?) AE context and into that of your own app.  Since you don't have any window classes in your own dictionary, AppleScript fails when it encounters them inside your context/outside the AppKit context.  (I've also confirmed this in SeaMonkey, which does have a working, if pitiful, dictionary but is also missing any window classes.)

Basically, the fact that any AppleScript support ever worked at all in Firefox is just a huge fluke.  

I haven't checked to see if removing the 'aete' resource entirely (and thus having *no* dictionary rather than an empty one) allows you to avoid this problem; it might, or it might make all scripting fail.
As such, this isn't really a Core bug, since it's specific to Firefox.
Blocks: 427448
Component: Widget: Cocoa → General
Product: Core → Firefox
QA Contact: cocoa → general
Hardware: x86 → All
Component: General → Widget: Cocoa
Product: Firefox → Core
QA Contact: general → cocoa
Steven or Luis, can you please explain to me why this is a Core bug when it deals with an application-specific problem? (I.e., Seamonkey does not have this bug, nor does Camino. It's specific to Firefox.)
Frankly, I just dumped it into Cocoa Widgets for further investigation.

And (with the possible exception of Camino) the code that supports AppleScript is, I think, cross-browser (though it's of course Mac-specific).
It would be interesting to know if Thunderbird has this issue as well.
(In reply to comment #5)
> Frankly, I just dumped it into Cocoa Widgets for further investigation.

After I moved it to Firefox because the lack of an AppleScript dictionary is, by definition, a per-app problem. See comment 2.
Closer to, but not quite, toolkit build config, isn't it? Every toolkit app (that's building with MOZ_WIDGET_TOOLKIT == mac or cocoa) unconditionally builds everything in xpfe/bootstrap/appleevents, including mozilla.sdef which unconditionally gives every app an empty SeaMonkey suite and browser-related Spyglass and Get URL suites.
No longer blocks: 427448
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.