119091 - Apple Script "get the front window" returns the wrong window

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Andrew Thompson]

From Elliotte Rusty Harold:

"    Furthermore, it still has some annoying problems
>with AppleScript that prevent me from using it as my
>default browser. In particular, it cannot tell which
>window is in front. get the front window returns the
>first window opened, not the window that is currently
>in front."

Comment 1

[Andrew Thompson]

A session in the debugger reveals this ends up in
void AEWindowClass::GetDataFromObject(const AEDesc *token, AEDesc *desiredTypes, 
AEDesc *data)

in the case
case pName:		// Synonym for pTitle
case pTitle:
GetCleanedWindowName(window, windowTitle, 255);
err = AECreateDesc(typeChar, windowTitle, strlen(windowTitle), data);
break;

I suspect we don't understand the "frontmost" part and are just running this on 
the first window that comes to hand.

Comment 2

[Simon Fraser [no longer active]]

It probably gets the oldest window. nsIWindowMediator used to be z-order 
impaired, but I think that is improved more recently.

Comment 3

[Andrew Thompson]

*** Bug 138768 has been marked as a duplicate of this bug. ***

Comment 4

[Jean-Pierre Melkonian]

Bug 138768 is marked as duplicate of this. I am not sure that it is correct.
I said that "busy of  front window" gives an apple script error.
But "busy of window 1",  "busy of window 2" etc... give also an error. So is it 
really a front window problem ?
I can say now that the error is -1700, Data could not be coerced

Comment 5

[Jean-Pierre Melkonian]

See also bug 158386. Any relation ?

Comment 6

[Andrew Thompson]

bug 138768 doesn't mention "the busy of the front window". Are you sure you have 
the right number. That one is definately a dupe.

As for bug 158386 - well, as the bug says, setting the bounds of *any* window 
fails, so its not specifically this bug that's causing it.

However if you wanted to run

"set the bounds of the front window to X"

obviously this bug would need to be fixed also. But since bug 158386 is really 
about the fact that you can't set the bounds of *any* window, not just the front 
one, I'm not marking this as a blocker.

I did confirm that bug for you though, for what its worth...

Comment 7

[Jean-Pierre Melkonian]

Sorry it was bug 158388, for busy. It it not yet marked as a duplicate of this,
it make only  reference to this one. I sent two applescript bugs yesterday, and
my copy and paste were wrong

I ll continue my comments on the good forms report

For this one i have tested: name of front window
it returns the first opened window, not the front window
but...
name of window 1 do the same

In an error message for a apple script containing  "front window"
i got a message about "window 1"
I suspect that "front window" is directely translated by applescript to window 1

Comment 8

[Andrew Thompson]

Further notes:

get the front window's name -- fails
get the back window's name -- fails, but usually returns the "other" window to
the previous case in the 2 window case
get the first window's name -- suceeds
get the second window's name -- succeeds, assuming > 1 window open.

I think we might be getting lost somewhere around here:
AEClassIterator::ItemRef AEClassIterator::ProcessFormRelativePostition(const
AEDesc* anchorToken, const AEDesc *keyData)

but this is very complex code... I'm still looking.

Comment 9

[Andrew Thompson]

But we definately don't find ourselves in
WindowPtr nsWindowUtils::GetNamedOrFrontmostWindow(TWindowKind windowKind, const
char* windowName)

though the script

get the window named "foo" 

would exercise this function

Comment 10

[Andrew Thompson]

Attachment: Fix 2 Applescript window finding functions to be aware of z-order

Cool. I found the problem. I've fixed GetWindowIndex() and
GetIndexedWindowOfKind() such that they ask the Window Mediator for an
enumeration of windows based on Z-index (rather than the default, which seems
to be creation order).

This means scripts of the form:
get the name of the front window
get the name of the back window

now work.

It also means that scripts like
get the name of the first window
or
get the index of the last window

are now sensetive to z-order rather than creation order. ie, the result of the
script changes as you re-arrange the z-order of the windows, where previously
it  wouldn't change unless you closed I window.

I tested the same scripts with the Mac OS X Finder, and that's how the Finder
behaves - indexes, ordering and things like front/back are all expressed in
terms of z-order. I think the way we've been doing it by creation order is just
plain wrong in the general case, and this patch corrects that.

Reviews please - its all of 2 lines long!

Comment 11

[Simon Fraser [no longer active]]

Comment on attachment 101356 [details] [diff] [review]
Fix 2 Applescript window finding functions to be aware of z-order

sr=sfraser.
I could have pointed you to that. For the longest time, there was no Z-order
enumerator.

Comment 12

[Andrew Thompson]

Working in 2002100403 for me, and will therefore make the 1.2 branch.

the script:

tell application "Mozilla"
	get the front window's name
end tell

returns the name of the window that's currently at the front in mozilla, rather 
than the first one created.

Comment 13

[Michael Buckland]

arun I see you nominated this.  Please advise why needed, and time to get branch
patch checked in.  Adding arun to cc list.