253486 - Fix inconsistent AppleScript behavior by fixing "browser window" and removing "Get URL"

Status: RESOLVED FIXED

(Camino Graveyard :: OS Integration, defect)

Description

[Sash]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040623 Camino/0.8
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040623 Camino/0.8

Applescript command sent to Camino to "get URL of window 1" results in an error
but the command "get «class curl» of window 1" works. This is inconsistent with
the syntax used by other browsers such as Safari. Please make the Applescript
dictionary consistent with Safari.


Reproducible: Always
Steps to Reproduce:
1. Compile the following AppleScript:
  tell application "Camino"
	get «class curl» of window 1
	log result
	get URL of window 1
	log result
  end tell
2. Look at the event log and the error message that is generated.


Actual Results:  
Actual Event Log from Applescript:
tell application "Camino"
	get «class curl» of window 1
		"http://bugzilla.mozilla.org/enter_bug.cgi?product=Camino&format=guided"
	(*http://bugzilla.mozilla.org/enter_bug.cgi?product=Camino&format=guided*)
	get URL of window 1
		"Camino got an error: NSCannotCreateScriptCommandError"


Expected Results:  
"get URL of window 1" should have produced the same result as "get «class curl»
of window 1"

Comment 1

[Jasper]

Confirmed using 2004102108 (v0.8+) NB on 10.3.5

Comment 2

[Mike Pinkerton (not reading bugmail)]

would be nice, but i'm not holding my breath.

Comment 3

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

Most of Camino's AppleScript dictionary doesn't work because of this bug. :-(

(The syntax of the commands *do* match Safari et al.; the commands just always
result in an error or silently fail.)

Comment 4

[Simon Fraser [no longer active]]

This is because "Get URL" is the name of a command. This is AppleScript sucking
(see http://daringfireball.net/2005/09/englishlikeness_monster).

Comment 5

[Simon Fraser [no longer active]]

This works:
tell application "Camino"
  get the URL of window 1
end tell

Invalid?

Comment 6

[Wevah (Nate Weaver)]

Or just

tell application "Camino"
    set foo to url of window 1
end tell

Comment 7

[Simon Fraser [no longer active]]

I guess we could remove "get url" from the dictionary, since "open url" does the
same thing.

Comment 8

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

get URL of window 1 errors in Safari, too, now, which is good.

"browser window", though, doesn't seem to work, and it's listed in the Camino
suite (unless I don't understand that class; "browser window" should be the
equivalent of "window," no?):

Class browser window: A browser window
Plural form:
	browser windows
Properties:
	<Inheritance>  window  [r/o]  -- All of the properties of the superclass.
	URL  Unicode text  [r/o]  -- Current URL

Removing Get URL might confuse folks who actually know what it means, but Safari
doesn't seem to seem to support it, either, if we're trying to be consistent
with it.

Otherwise, I agree, this is invalid.

Comment 9

[Samuel Sidler (old account; do not CC)]

Simon or Wevah, care to comment on this? Is this bug now INVALID?

The only thing we could do here (as Smokey mentioned) is remove "get URL". Is that something we want to do? If not, INVALID.

Comment 10

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

I still want an answer about "browser window", too :-)

Comment 11

[Simon Fraser [no longer active]]

Invalid.

Comment 12

[Simon Fraser [no longer active]]

Oh, we should fix "browser window".

Comment 13

[Simon Fraser [no longer active]]

I couldn't get "browser window" working with about an hour of hacking. Luckily "url of window 1" works OK.

Comment 14

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

Is there any point in keeping "browser window"?  I think we're the only one with that term, and as Simon noted, "url of window 1" (and other similar constructions) work.

Should we simply remove it and be done with it, or do we need it to associate the "URL" property with "window" (or is that association defined in some system scripting additon)?

Comment 15

[Simon Fraser [no longer active]]

(In reply to comment #14)
> Is there any point in keeping "browser window"?  I think we're the only one
> with that term, and as Simon noted, "url of window 1" (and other similar
> constructions) work.

Yes, because there other other windows (e.g. downloads window) which won't have a "url" property.

Comment 16

[Chris Andrichak]

For comparison:
tell application "Safari"
  tell document 1
    set the clipboard to URL as string
  end tell
end tell

Works in safari, does not work in Camino. Trying to make the URL into a string Fails during running. Getting rid of the "as string" allows it to run, but it does not seem to copy the URL.

I think the "window #" construct is fine. Having scripts that run the same in safari or Camino would be great.

Comment 17

[Simon Fraser [no longer active]]

Camino is not document based, so that's not going to work.

Ideally we would be, and perhaps expose multiple tabs per window via a one to many document to window mapping or something.

Comment 18

[Daniel A. Shockley]

(In reply to comment #7)
> I guess we could remove "get url" from the dictionary, since "open url" does
> the
> same thing.
> 

I wouldn't remove "Get URL" - that's a long-standing (while odd) command. The following handles the issue described regarding the conflict:
tell application "Camino" to get (URL of window 1)

I agree, however, that it is very odd that the 'browser window' term is orphaned. It isn't an element of anything, so what is it doing? Shouldn't 'browser windows' be elements of 'application'? The following should work, but doesn't:
tell application "Camino" to get (URL of browser window 1)

Instead you have to run what I mentioned earlier (URL of window 1), which is interesting, since there is no indication in the dictionary that 'window' has the 'URL' property.

Comment 19

[Chris Lawson (gone)]

(In reply to comment #18)

> I wouldn't remove "Get URL" - that's a long-standing (while odd) command.

See comment 4. IMO, it really needs to go, script-breakage be damned.

cl

Comment 20

[Daniel A. Shockley]

Actually, for this and for #326133, I'd highly recommend you look at OmniWeb's dictionary - they're the only ones who properly support tabs via AppleScript. They also handle a few of these other issues well, too. In fact, they use GetURL instead of 2 separate words, which is how it was handled long ago when invented by Netscape (or was it Mosaic?). Someone must have decided at some point that it "looked nicer" to make it two words, thus running headlong into the English-likeness Monster Jon Gruber has described so well.

Comment 21

[Daniel A. Shockley]

(In reply to comment #19)
> (In reply to comment #18)
> 
> > I wouldn't remove "Get URL" - that's a long-standing (while odd) command.
> 
> See comment 4. IMO, it really needs to go, script-breakage be damned.

Chris, I take it back. Upon further review, I remembered that the long-standing (and widely supported) command was 'GetURL' not 'Get URL' (two words). Perhaps Camino should move back to what was the standard for a long time, switching back to GetURL and OpenURL, rather than the relatively new 2-word forms of those commands. I just looked through some other web browser, and the 1-word form is what they use. (iCab, OmniWeb, Internet Explorer). Safari lists no support for those at all. Firefox use 1-word for OpenURL, but 2 for GetURL, which may have been a mistake, since Netscape used to use GetURL and OpenURL. It seems at some point, the Netscape team switched to the 2-word form of 'Get URL' - I'm not sure why. In 4.7, it was Get URL. By 7.1 it was 'Get URL.'

So, I guess you shouldn't worry too much about changing it, right? It's been changed before (for the worse).

By the way, if you want to look through dictionaries without needing the app, you can go to http://macscripter.net/app_dictionaries/

Comment 22

[Chris Andrichak]

(In reply to comment #17)
> Camino is not document based, so that's not going to work.
> 
> Ideally we would be, and perhaps expose multiple tabs per window via a one to
> many document to window mapping or something.
> 

looking through the safari dictionary, it would seem that many documents are mapped to a window just as you mention. That would seem the most straightforward way to abstract multiple tabs or views in one window.
Again I would really be pleased by matching dictionaries, it would make scriptwriting across multiple browsers much easier.

Comment 23

[Chris Andrichak]

(In reply to comment #22)

> looking through the safari dictionary, it would seem that many documents are
> mapped to a window just as you mention. That would seem the most
> straightforward way to abstract multiple tabs or views in one window.
> Again I would really be pleased by matching dictionaries, it would make
> scriptwriting across multiple browsers much easier.
> 

maybe I should have made my last comment in bug 314061 , but oh well, these two bugs are quite intertwined.

Comment 24

[Daniel A. Shockley]

(In reply to comment #22)
> looking through the safari dictionary, it would seem that many documents are
> mapped to a window just as you mention. That would seem the most
> straightforward way to abstract multiple tabs or views in one window.
> Again I would really be pleased by matching dictionaries, it would make
> scriptwriting across multiple browsers much easier.
> 

The dictionary shows that a document is a property (only one) of a window, not an element. So, there is only one document exposed for a window, the currently-selected tab. It may even be that is technically correct - perhaps tabs are really a sub-class of window, for example, and thus each tab of a window has its own document.

Anyway, as I mentioned before (hmm, in the related bug 314061), OmniWeb is the only web browser that actually supports tabs via AppleScript. So, if you want consistent behavior, it would be best to go with their terminology. However, they use the term 'browser' for windows that are browser windows (as opposed to downloads, etc), which would be different than the current (broken) implementation of using the term 'browser window.'

Anyway, I'd recommend you look at the only web browser that currently does this right (actually, does this at all) when you're deciding what to do.

Back when Safari was version 1.0 and people were submitting requests for Safari to get tabs I begged Apple to truly add tabs by putting them into the AppleScript dictionary. We're pushing, what, three years and as is often the case with AppleScript, Apple itself is not supporting it correctly. You can only imagine how much I'll cheer when iPhoto allows you to correct a photo's date via AppleScript, rather than clicking and typing manually. :-)

Thanks.

Comment 25

[Stuart Morgan]

What exactly is this bug about now? All the tab stuff is covered elsewhere. I'm seeing:
- Remove "Get URL"
- Support "Browser Window"

Anything else? We need to re-summarize this bug to make it less vague.

Comment 26

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

Yeah, the first part of the bug was actually the AS/Director mess you just fixed; the latter part is those two issues.

Comment 27

[Peter Jaros (:peeja)]

Taking, as part of Summer of Code: http://wiki.caminobrowser.org/Development:Summer_of_Code_2007:AppleScript

The following code now works:

tell application "Camino"
	tell browser window 1
		set the clipboard to URL as string
	end tell
end tell

I'm using "browser windows" to represent BrowserWindows in particular, while "windows" refers to all windows, including the Downloads window.  (Right now it still includes some hidden windows; that will be fixed soon.)  I'm rewriting the dictionary from scratch, so "get url" is currently gone.

However, remember that this is AppleScript, and scripts are not saved as text (typically) but as compiles AppleEvents.  The text is reconstituted from the terminology when ScriptEditor opens it.  Therefore, we are free to change the terminology as long as we don't change the event codes.  Turns out Apple's already solved the "getURL"/"get url" issue with the standard "open location", provided by a scripting addition.  I'll make sure Camino supports "open location", which is the same AppleEvent as getURL.  Scripts that (sucessfully) used "get url" will then read "open location" and not break.

Comment 28

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

"open location" was the only thing I could get to work before smorgan fixed the Director/AS bug, so I'm pretty sure we support it.

Comment 29

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

FIXED by checkin for bug 385989.