437802 - Tooltip windows show in AppleScript's "count" while their parent tab is open

Status: RESOLVED FIXED

(Camino Graveyard :: OS Integration, defect)

Description

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

Spun off of bug 433981, which isn't very clear at all.

It turns out that we can accumulate "phantom" windows that show up in AppleScript's "count" (and other) command.

tell application "Camino"
	count every window
	
	get every window
	
	repeat with i from 1 to (count every window)
		get the name of window i
	end repeat
end tell

As I reported in bug 433981 comment 2, I ended up with a few "" windows when I get the name of every window.  Further trial and error today under guidance from Peter, and I discovered that the phantom "" windows are tooltips.  We can accumulate one phantom per tab, so long as the tab is open.  Once you close the parent tab, both it and its associated "" phantom tooltip window fall off of AppleScript's window count.

In most cases people should be counting browser windows, so this is not major bug, but for correctness, we should fix it if we figure out how (Safari does not have this bug).

Comment 1

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

We've got this nice bit of code accounting for certain odd windows already: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/camino/src/appleevents/ScriptingSupport.mm&rev=1.7&mark=168#161

Since the tooltips don't have a distinct class like autocomplete windows, Stuart suggested that we could give tooltip windows a distinctive name and filter them out that way.

Comment 2

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

Attachment: Give ToolTip windows a unique title and filter them out

Stuart, is this what you had in mind?  There's no "name" method AFICT, but we can set a title (that doesn't get displayed) and filter the tooltip windows out based on that.

Comment 3

[Stuart Morgan]

Comment on attachment 606833 [details] [diff] [review]
Give ToolTip windows a unique title and filter them out

I wonder if we should just look for
  [curWindow windowStyle] & NSBorderlessWindowMask
instead; I can't think of any borderless windows we want to treat as app windows.

Failing that, we should make a do-nothing subclass of NSWindow for the tooltips, and check for that. The title isn't workable because it means malicious web sites could cause their windows to behave strangely in Camino just by changing their title.

Comment 4

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

(In reply to Stuart Morgan from comment #3)
> Comment on attachment 606833 [details] [diff] [review]
> Give ToolTip windows a unique title and filter them out
> 
> I wonder if we should just look for
>   [curWindow windowStyle] & NSBorderlessWindowMask
> instead; I can't think of any borderless windows we want to treat as app
> windows.

Me either; I'll try give the style check a go tomorrow.

Comment 5

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

I got all confused here for a while, and in the process of righting myself, discovered this interesting tidbit:

* Load cbo/start:

curWindow: <BrowserWindow: 0x15f1ffe0>, title: Camino. Start, uniqueID: 121216
curWindow: <NSWindow: 0x15f23140>, title: Window, uniqueID: -1
curWindow: <NSWindow: 0x15f24480>, title: Window, uniqueID: -1
curWindow: <MAAttachedWindow: 0x15f2d890>, title: , uniqueID: 121212
curWindow: <MAAttachedWindow: 0x15f36650>, title: , uniqueID: 121214
curWindow: <NSWindow: 0xbedbc0>, title: , uniqueID: -1

* Now hover over Camino logo on cbo/start to invoke tooltip:

curWindow: <BrowserWindow: 0x15f1ffe0>, title: Camino. Start, uniqueID: 121216
curWindow: <NSWindow: 0x15f23140>, title: Window, uniqueID: -1
curWindow: <NSWindow: 0x15f24480>, title: Window, uniqueID: -1
curWindow: <MAAttachedWindow: 0x15f2d890>, title: , uniqueID: 121212
curWindow: <MAAttachedWindow: 0x15f36650>, title: , uniqueID: 121214
curWindow: <NSWindow: 0xbedbc0>, title: , uniqueID: 121285

That last NSWindow (0xbedbc0), which initially had a unique ID of -1 and was filtered out, suddenly gets a new unique ID after the tooltip gets shown!

Other semi-interesting window facts:

1) The About window never shows up, or it's one of those unique ID -1 windows

2) Once the Preferences window has ever been opened in a session, the window will always show up, even if it is currently closed.

Comment 6

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

Attachment: Filter out all windows with NSBorderlessWindowMask style masks

Here's the NSBorderlessWindowMask-based fix.  Note that a window can either have NSBorderlessWindowMask OR have a bitwise mask of the other constants[1], so you have to use == to check for NSBorderlessWindowMask, not &.

Also, checking for this mask conveniently will filter out the dragging-tab-image window, if the script happens to run while a tab drag is taking place, since that window also has NSBorderlessWindowMask.[2]

For the same reason, we could simplify this check and drop the isKindOfClass:[MAAttachedWindow class] check.[2]  However, I've left that explicit check in this version of the patch because I was afraid that if something ever changed the style mask inside MAAttachedWindow, or if we switched to a new window subclass for our autocomplete windows, this code could get out of sync; this way we're protected against the internal workings of MAAttachedWindow, and MXR or compile errors will protect us if changing the window subclass ourselves.

[1] http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/doc/constant_group/Window_Style_Masks

[2] http://mxr.mozilla.org/camino/search?string=NSBorderlessWindowMask&tree=camino

Comment 7

[Stuart Morgan]

(In reply to Smokey Ardisson (not following bugs - do not email) from comment #6)
> Here's the NSBorderlessWindowMask-based fix.  Note that a window can either
> have NSBorderlessWindowMask OR have a bitwise mask of the other
> constants[1], so you have to use == to check for NSBorderlessWindowMask, not
> &.

I figured we'd want to filter out all borderless windows, which is why I suggested &. The more restrictive check is fine though.

Comment 8

[Stuart Morgan]

Comment on attachment 615617 [details] [diff] [review]
Filter out all windows with NSBorderlessWindowMask style masks

!([curWindow styleMask] == NSBorderlessWindowMask) &&
should just be
[curWindow styleMask] != NSBorderlessWindowMask &&

sr=smorgan with that change.

Comment 9

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

http://hg.mozilla.org/camino/rev/ec4813b895b0 with the change in comment 8.

(In reply to comment #7)
> I figured we'd want to filter out all borderless windows, which is why I
> suggested &. The more restrictive check is fine though.

I don't understand comment 7, though; isn't == (or != in this case) filtering out all borderless windows?  You can't be borderless and also something else; you're either borderless, or non-borderless plus some bitwise mask for toolbar or other window styles.