319843 - XULRunner windows are grouped in the Taskbar

Status: RESOLVED FIXED

(Toolkit Graveyard :: XULRunner, defect)

Description

[Marvin Paul]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: 

When the Taskbar becomes too cluttered, Windows XP groups similar windows together. If there are enough XULRunner apps running, they will all be grouped together even if they are different XUL applications. Of course, this only happens if the user has "Group similar taskbar buttons" enabled.

Reproducible: Always

Steps to Reproduce:
1. Make sure taskbar grouping is enabled (Right-click the Taskbar > Properties > Check "Group similar taskbar buttons")
2. Open a lot of applications to make sure that the taskbar is full
3. Open 2 or 3 different XUL applications by using XULRunner

Actual Results:  
The XUL applications are all grouped together under a button named "xulrunner".

Expected Results:  
The different XUL applications should not be grouped.

Windows aren't grouped by using the icon. I opened MyBrowser (from Darin Fisher) and XULMine (which uses a different icon) and they were still grouped.

Comment 1

[James Ross]

I assume here you have one XULRunner install and multiple apps? The grouping is based on the executable that owns the window, is in, its full path is used and it is not based on process instances (or just filenames).

The only way to stop the grouping is to use separate executables for each app. Of course, this is not really desirable, but I would point out that (assuming it will start ok) a temporary copy of xulrunner.exe could be made for each app, since it is the path+filename that matters, not just the name (or some signature, etc.). See http://support.microsoft.com/kb/283132

If you wanted to go the full distance and make the icon correct as well, you'd need to name the copied exe uniquely to the app and place a registry key at:
  HKEY_CLASSES_ROOT\Applications\xulrunner-someappname.exe
And put the value TaskbarGroupIcon in it, setting the data to point to the icon (using the standard "filename,iconindex" format). Fun!

Comment 2

[Benjamin Smedberg]

Yes, and since that's the common use-case for XULRunner, we're going to need to find a solution. Does anyone know how Windows knows which binary the window belongs to (could we forge it?)

Comment 3

[James Ross]

Although I have not yet had the chance to work out exactly how Windows is clustering, or collapsing, the items, but there are a couple of possible ways it could be getting the information it needs:

A. GetWindowModuleFileName (returns a full path from an HWND)
B. 1. GetWindowThreadProcessId (returns a PID and TID from an HWND),
   2. OpenProcess (returns a process handle from a PID if permission allows),
   3. GetModuleFileNameEx (returns the full path to the process executable).

Neither of these can be forged AFAIK, and I asuspect the first is really just a wrapper anyway. Explorer only successfuly groups apps run under the same user as itself, too.

Comment 4

[Chris Cook]

Another symptom of the problem is that the app shows in the task manager as "xulrunner.exe" even if it was started with a renamed xulrunner-stub.exe. When using a shared xulrunner this would make it difficult to determine which app is which in the task manager if they all show as xulrunner.exe.

This is almost certainly why they are grouped on the taskbar.

Comment 5

[James Ross]

Chris, it's pretty obvious why they all appear as xulrunner.exe - they all ARE! The stub program does nothing more than find an installed xulrunner.exe and launch it. Also, they are grouped because the entire filepath is the same, not just because the exe name is, as I said in comment 1.

Comment 6

[Darin Fisher]

Perhaps we should consider changing the "xulrunner stub" executable from launching the selected to xulrunner.exe to loading the selected xul.dll.  I'm not sure how workable this solution is for other platforms, namely OSX, but it would surely work on Windows and Linux.  Doing this would also help with the problem of personal firewall software identifying the running application by its executable name.

Comment 7

[Benjamin Smedberg]

If nothing else can be found, we could export "main" or a main-like function from the "xulrunner.exe" binary and call that (since windows executables are PEs just like DLLs can, and can be dynamically loaded in the same way with exported symbols). This would require some hackery in XRE_GetBinaryPath since the result of GetModuleFileName would change.

Comment 8

[James Ross]

Mm, that basically removes xulrunner.exe from the picture entirely if the 'stub' actually is the real thing rather than a launcher.

The only option I can think of right now (that keeps it as a stub launcher) would be for once the stub has found xulrunner.exe, for it to make a copy (in the xulrunner.exe folder) with the app name (if it doesn't already exist), add the registry key for the group icon, and then launch the copy of xulrunner.exe.

While that would probably be enough to effectively group by app-name and get the right group icon, it obviously leaves things lying around, and I can't think of a particularily sane way to clean them up.

Comment 9

[Darin Fisher]

> The only option I can think of right now (that keeps it as a stub launcher)
> would be for once the stub has found xulrunner.exe, for it to make a copy (in
> the xulrunner.exe folder) with the app name (if it doesn't already exist), add
> the registry key for the group icon, and then launch the copy of xulrunner.exe.

Interesting suggestion, but I think we should consider the xulrunner installation directory readonly since it may be installed that way (c:\program files\... may be readonly).

Comment 10

[James Ross]

Yeah, this is true, and bsmedberg's idea of loading it into the stub's memory space seems much better (though is more likely to confuse existing code).

Comment 11

[Dave Townsend [:mossop]]

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

Comment 12

[Benjamin Smedberg]

Attachment: Run XRE_main directly from the stub, rev. 1

Comment 13

[Darin Fisher]

Comment on attachment 233902 [details] [diff] [review]
Run XRE_main directly from the stub, rev. 1

>Index: toolkit/xre/nsAppRunner.h

>+void SetAllocatedString(const char *&str, const char *newvalue);
>+void SetAllocatedString(const char *&str, const nsACString &newvalue);

These should be documented.  It's not very clear from their signature
how they should be used or even what they do.


r=darin

Comment 14

[Benjamin Smedberg]

Fixed on trunk... I had to make a supplementary checkin to properly disable the min/maxversion checks in XRE_main when it is called with the older revision of nsXREAppData.