Last Comment Bug 490762 - activate breaks AppleScript support
: activate breaks AppleScript support
Status: NEW
:
Product: Core
Classification: Components
Component: Widget: Cocoa (show other bugs)
: Trunk
: All Mac OS X
: -- normal with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-29 21:17 PDT by Luis de la Rosa
Modified: 2011-04-02 02:23 PDT (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Luis de la Rosa 2009-04-29 21:17:22 PDT
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 2009-04-30 11:00:56 PDT
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) 2009-04-30 11:14:46 PDT
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) 2009-04-30 19:29:45 PDT
As such, this isn't really a Core bug, since it's specific to Firefox.
Comment 4 Chris Lawson (gone) 2009-05-01 10:33:44 PDT
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) 2009-05-01 10:50:20 PDT
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 (:dmose) 2009-05-01 11:18:17 PDT
It would be interesting to know if Thunderbird has this issue as well.
Comment 7 Chris Lawson (gone) 2009-05-01 11:34:42 PDT
(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) 2009-05-01 12:00:07 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.