490762 - activate breaks AppleScript support

Status: NEW

(Core :: Widget: Cocoa, defect)

Description

[Luis de la Rosa]

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"
    activate
    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.

Comment 1

[Luis de la Rosa]

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.

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 3

[Chris Lawson (gone)]

As such, this isn't really a Core bug, since it's specific to Firefox.

Comment 4

[Chris Lawson (gone)]

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.)

Comment 5

[Steven Michaud [:smichaud] (Retired)]

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).

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

It would be interesting to know if Thunderbird has this issue as well.

Comment 7

[Chris Lawson (gone)]

(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.

Comment 8

[Phil Ringnalda (:philor)]

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.