326133 - Tabs don't exist in AppleScript

Status: VERIFIED DUPLICATE of bug 314061

(Camino Graveyard :: Tabbed Browsing, defect)

Description

[Daniel A. Shockley]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060203 Camino/1.0rc1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060203 Camino/1.0rc1

Camino's tabs are not represented in Camino's AppleScript dictionary. In this respect, Camino has replicated Safari's dysfunctional implemention of tabs. A 'browser window' does not really have a single URL - it often has multiple URLs (one for each tab). The dictionary does not reflect this. Probably the easiest way to fix this is NOT to remove the URL property from 'browser window' but rather to add 'browser tabs' as elements of 'browser window' and the 'browser tabs' have their own properties, including title, URL, etc.

Reproducible: Always

Steps to Reproduce:
1. Load multiple URLs into separate tabs in a single window in Camino.
2. In Script Editor, paste this: tell application "Camino" to get (URL of window 1)
3. Press Run.
Actual Results:  
You will get a single URL, which is incorrect. There is no way to find out the URLs of the other open tabs, which means that tabs are invisible to AppleScript.

Expected Results:  
What you should be able ot do is something like this:
tell application "Camino" to get (URL of every browser tab of window 1)

and it would return a list of URL strings.

AppleScript support is a major part of having a fully-Mac version of Firefox. OmniWeb implements tabs in such a way as to expose them to control via AppleScript. No other Mac web browser does this properly - not Safari, not Opera, not Firefox, not Netscape, not Shiira, and not iCab. It would be wonderful if Camino supported tabs completely. One major reason this kind of support is useful is to be able to write a script that frequently saves the currently-loaded set of tabs so that they are not lost in a crash. Perhaps Camino could implement the ability to automatically save the current state of the browser. This would be a wonderful feature in itself. In the meantime, supporting tabs in AppleScript would be a good thing to do.

Comment 1

[Chris Lawson (gone)]

Such a script has already been written by a guy on the MZ Forums.

This seems valid enough to me, but definitely a "future" thing. Maybe for 2.0?

cl

Comment 2

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

I'll confirm this and note that it may be covered in bug 253486. I wouldn't target it just yet, however.

Comment 3

[Stuart Morgan]

(In reply to comment #1)
> Such a script has already been written by a guy on the MZ Forums.

IIRC, the script in question is destructive, since the issue described in this bug prevents getting all the open tabs--instead it repeatedly gets the current tab and then closes it to reveal the next.

Comment 4

[Simon Fraser [no longer active]]

If we fix this, we need to not break existing scripts.

Comment 5

[Daniel A. Shockley]

(In reply to comment #4)
> If we fix this, we need to not break existing scripts.
> 

Absolutely. The best way to avoid that is to keep the current state of the window having a property 'URL' while also adding elements to the window (browser tabs?) that also have their own URL property.

On a side note: for some reason you must refer to 'URL of window 1' - the 'browser windows' are not elements of application. However, the 'window' definition does not show as having the URL property, while the browser window does. In other words:
tell application "Camino" to get (URL of window 1)
should not work, since nowhere in the dictionary does window either have or inherit the property 'URL.' However, while a browser window _does_ have the URL property, you cannot refer to browser windows. The following does not work:
tell application "Camino" to get (URL of browser window 1)

So, I don't know if that issue should be a separate bug, or whether this is indicative of a dictionary that just doesn't match the actual behavior of the application.

Comment 6

[Daniel A. Shockley]

(In reply to comment #5)
> On a side note: for some reason you must refer to 'URL of window 1' - the
> 'browser windows' are not elements of application. However, the 'window'
> definition does not show as having the URL property, while the browser window
> does. In other words:

Ah. I see that _this_ other issue is covered in Bug # 253486. I'll post some comments there about it.

The issue with non-existent tabs is briefly mentioned there, but perhaps it would make sense to separate it out (while being aware the two bugs are somewhat related).

Comment 7

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

*** This bug has been marked as a duplicate of 314061 ***