If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED FIXED

Status

Camino Graveyard
OS Integration
--
minor
RESOLVED FIXED
9 years ago
6 years ago

People

(Reporter: Smokey Ardisson (offline for a while; not following bugs - do not email), Assigned: Smokey Ardisson (offline for a while; not following bugs - do not email))

Tracking

Details

(Whiteboard: [camino-2.1.3][good first bug])

Attachments

(1 attachment, 1 obsolete attachment)

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).

Updated

9 years ago
Hardware: Macintosh → All
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.
Whiteboard: [good first bug]
Created attachment 606833 [details] [diff] [review]
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.
Assignee: nobody → alqahira
Status: NEW → ASSIGNED
Attachment #606833 - Flags: superreview?(stuart.morgan+bugzilla)

Comment 3

6 years ago
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.
Attachment #606833 - Flags: superreview?(stuart.morgan+bugzilla) → superreview-
(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.
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.
Created attachment 615617 [details] [diff] [review]
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
Attachment #606833 - Attachment is obsolete: true
Attachment #615617 - Flags: superreview?(stuart.morgan+bugzilla)

Comment 7

6 years ago
(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

6 years ago
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.
Attachment #615617 - Flags: superreview?(stuart.morgan+bugzilla) → superreview+
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [good first bug] → [camino-2.1.3][good first bug]
You need to log in before you can comment on or make changes to this bug.