Last Comment Bug 515734 - Provide More Entries in the Win7 Jumplist Tasks list.
: Provide More Entries in the Win7 Jumplist Tasks list.
Status: RESOLVED FIXED
:
Product: SeaMonkey
Classification: Client Software
Component: OS Integration (show other bugs)
: Trunk
: x86 Windows 7
: -- normal with 3 votes (vote)
: seamonkey2.5
Assigned To: Justin Wood (:Callek)
:
Mentors:
Depends on: 560846
Blocks: 566138 677484
  Show dependency treegraph
 
Reported: 2009-09-10 12:47 PDT by Jason Bassford
Modified: 2011-10-20 09:26 PDT (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
wontfix


Attachments
Screenshot of patch v1.0 (37.71 KB, image/png)
2011-08-01 00:15 PDT, Justin Wood (:Callek)
no flags Details
v1.0 Add the tasks. (3.29 KB, patch)
2011-08-01 00:16 PDT, Justin Wood (:Callek)
bugzilla: review+
Details | Diff | Review

Description Jason Bassford 2009-09-10 12:47:53 PDT
This is specific to SeaMonkey - where "seamonkey -browser" and "seamonkey -mail" open up, respectively, the browser component and the mail component of the suite.

When I drag these shortcuts to the Windows 7 taskbar, they do not get grouped into the same overall SeaMonkey icon.  Rather, I will get two different icons - one for the browser, one for mail.  This seems reasonable, until I actually go to launch them.  Regardless of which order I launch them in, the now running windows become grouped under the first launched icon.  So, for example, if I launch a browser session then a mail session, the taskbar shows "grouped" icons for the browser.  (Similarly, "grouped" icons for mail if I launch that one  first.)  Which means that I need to click on the browser icon to get to my running mail session, or vice-versa.

It doesn't seem right that it should treat them separately when pinned to the
taskbar - but together (and just latching on to which one was first launched) when actually launched.  Either everything should be grouped together, or the different functions should be treated as individual applications.

I am seeing this in the latest SeaMonkey trunk builds (2.1a1pre off of latest-comm-central-trunk).
Comment 1 Jason Bassford 2009-09-10 14:18:10 PDT
This may or may not have some dependency on bug 505925 - I'm not sure.
Comment 2 Robert Kaiser (not working on stability any more) 2009-09-10 15:43:54 PDT
It depends on the whole Win7 taskbar support in any case, which is bug 473045 as you know. CCing Frank, who is the guy who has done most of our Windows integration work so far - note that this will surely not be done for 2.0, but it could be interesting for the next release.
Comment 3 Jason Bassford 2009-10-23 13:34:03 PDT
Now that Windows nightly trunk builds are back again, and I'm using a 10/23 build, I've had a chance to test the state of things since bug 473045 was fixed.

It's worse.  Post bug 473045:

1. I have an icon for the browser.
2. I have a 2nd icon for mail.

When I open either the browser or mail - Windows now creates a 3rd icon for me.  Completely ignoring either of the existing icons.  This is almost an "anti-jumplist" - at least before things behaved somewhat like other Windows 7 apps are supposed to (aside from the fact that the browser and mail icons stayed separate rather than merging together).  Now, it's just totally confused.

Is it possible that bug 473045 is working properly for Firefox - but completely messing up SeaMonkey?
Comment 4 Jason Bassford 2009-10-25 06:32:54 PDT
Actually, let me redefine this bug a little bit.  Even though previously it didn't know to group "seamonkey -browser" and "seamonkey -mail" into a single icon, at least when you started running them they would group to whichever icon you used first.
Comment 5 Jason Bassford 2009-11-04 05:06:54 PST
FWIW, if I remove the command line switches altogether (forget about -browser and -mail) Windows 7 still creates a new icon when I click on my existing one, rather than grouping.  So it's now impossible to have a single icon no matter what I do.
Comment 6 Jason Bassford 2009-11-13 05:02:16 PST
Strange.  As of an 11/12 trunk build, the behaviour has gone back to what was originally reported.
Comment 7 Jason Bassford 2009-11-13 05:21:53 PST
Argh.  I'd been using a branch build without being a aware of it.  A 11/13 *trunk* build (2.1apre) is still just as broken.  I won't spam this bug any more, though, by changing things around again.
Comment 8 Jason Bassford 2010-02-01 20:00:45 PST
I've discovered at least a partial workaround to the new icon appearing problem.  Rather than pin the start menu item, or desktop icon, for SeaMonkey to the task bar, actually launch the program (when nothing is pinned) and then pin that.  Once done, no new icon will be created, and it will always group to the same place.

This doesn't address how to have a single icon with jump list entries for Browser, Mail, etc., but it at least prevents Windows from creating a new icon on the task bar.
Comment 9 Jim Mathies [:jimm] 2010-04-20 15:49:42 PDT
How do seamonkey apps differentiate themselves during a build/settings?  In the taskbar code we create a default taskbar registration id thus:

#ifndef MOZ_TASKBAR_ID
#define MOZ_COMPANY Mozilla
#define MOZTBID1(x) L#x
#define MOZTBID2(a,b,c) MOZTBID1(a##.##b##.##c)
#define MOZTBID(a,b,c) MOZTBID2(a,b,c)
#define MOZ_TASKBAR_ID MOZTBID(MOZ_COMPANY, MOZ_BUILD_APP, MOZILLA_VERSION_U)
#endif

I'm working on some improvements where this can also be set through the application.ini file and potentially by users through prefs. I'm curious if the ini file fix could be used to solve the seamonkey app problem.
Comment 10 Robert Kaiser (not working on stability any more) 2010-04-21 05:22:25 PDT
(In reply to comment #9)
> How do seamonkey apps differentiate themselves during a build/settings?

They're just different windows of the same application, actually.

The SeaMonkey application has commandline arguments to start up specific windows/components, which are used to have a special "SeaMonkey Mail" start menu entry, bring up a compose window for the OS mailto handler, etc.
Comment 11 Jim Mathies [:jimm] 2010-04-21 07:38:02 PDT
(In reply to comment #10)
> (In reply to comment #9)
> > How do seamonkey apps differentiate themselves during a build/settings?
> 
> They're just different windows of the same application, actually.
> 
> The SeaMonkey application has commandline arguments to start up specific
> windows/components, which are used to have a special "SeaMonkey Mail" start
> menu entry, bring up a compose window for the OS mailto handler, etc.

Ok, that's going to require additions to the taskbar apis. You can set this per top level window as well. We should file off a new bug or morph this one into it.
Comment 12 Robert Kaiser (not working on stability any more) 2010-04-21 08:42:01 PDT
(In reply to comment #11)
> Ok, that's going to require additions to the taskbar apis. You can set this per
> top level window as well. We should file off a new bug or morph this one into
> it.

Thanks for that info and for filing that bug! :)
Comment 13 Robert Kaiser (not working on stability any more) 2010-05-15 06:18:06 PDT
As jimm has laid good platform-side ground work for this in bug 560846, I think we should move this to wanted state for 2.1 at least.

Do we have someone with at least some dev skills around and a Win7 installation who can try to write this up and test it a bit?
Comment 14 Justin Wood (:Callek) 2010-09-07 20:06:26 PDT
Jason, any chance you'd want to help with this bug, I'm willing to help handhold a bit based on above stuff, but I'm on XP here, so I cannot test at all.

Certainly wanted+ though
Comment 15 Jason Bassford 2010-09-08 05:15:29 PDT
Sure, I have no problem testing - just tell me what I need to do.
Comment 16 Philip Chee 2011-05-09 03:11:54 PDT
Jason, now that Bug 581526 is fixed do you still see the problem with SeaMonkey 2.1?
Comment 17 Jason Bassford 2011-05-09 06:27:52 PDT
> do you still see the problem

Yes and no.  I'm currently using a 5/4 build, which should have the patch checked in.  While the original behaviour I described isn't *exactly* the case any more, I'm still not certain if things are correct.

As of now, when I pin "seamonkey -browser" and "seamonkey -mail" to the task bar, I get two separate icons - they are not grouped together.  When I execute the mail icon, it gets "executed" under the browser icon.  (Rather than previously where it was just the first executed one under which everything was grouped.)  So, if I look at the browser icon, I now see two instances - one the browser itself, the other mail.

While this is better, I still don't think that things are as they should be.  I shouldn't be able to pin "seamonkey -mail" to the task bar and have it show up as a separate icon.  When I pin "mail" it should "disappear" and I should see a jumplist entry for running mail appear in the first, original, browser icon that I'd pinned.  That doesn't happen.
Comment 18 Robert Kaiser (not working on stability any more) 2011-05-09 06:50:18 PDT
Bug 581526 added basic support for the jumplist, but support for the individual components based on the bug 560846 work (which this bug is about) is still missing. Help wanted!
Comment 19 Jim Mathies [:jimm] 2011-05-09 07:12:19 PDT
Note exe registration will change through bug 577867, we wont be using the app.ini data anymore, instead we'll use a hash of the full exe path. This won't effect the work here though, sm still needs to register each of it's windows to get them to split up right. (I will also update the sm installer in bug 577867 since those changes will impact the installer work done in bug 581526.)

The work we need to do here should be pretty minor, at some point after window creation (in windows widget maybe or up in the ui js?.. where ever it's convenient to detect the app that's running) detect which app is running (mail vs. browser) and register it through the taskbar window reg. api.
Comment 20 Philip Chee 2011-05-10 11:21:27 PDT
Just to make sure Bug 560846 Comment 4 doesn't get lost:

> Some simple example code that works in the ede javascript console:
> 
> var wm = Cc["@mozilla.org/appshell/window-mediator;1"].getService(Ci.nsIWindowMediator);
> var win = wm.getMostRecentWindow("navigator:browser");
> var taskbar = Cc["@mozilla.org/windows-taskbar;1"].getService(Ci.nsIWinTaskbar);
> 
> // Split this window out into it's own stack
> taskbar.setGroupIdForWindow(win, "myId");
> 
> // Restore this window to the bottom of the default stack
> taskbar.setDefaultGroupIdForWindow(win);
Comment 21 dkbatson 2011-07-11 03:33:40 PDT
(In reply to comment #17)

> As of now, when I pin "seamonkey -browser" and "seamonkey -mail" to the task
> bar, I get two separate icons - they are not grouped together.  When I
> execute the mail icon, it gets "executed" under the browser icon.  (Rather
> than previously where it was just the first executed one under which
> everything was grouped.)  So, if I look at the browser icon, I now see two
> instances - one the browser itself, the other mail.
> 
> While this is better, I still don't think that things are as they should be.
> I shouldn't be able to pin "seamonkey -mail" to the task bar and have it
> show up as a separate icon.  When I pin "mail" it should "disappear" and I
> should see a jumplist entry for running mail appear in the first, original,
> browser icon that I'd pinned.  That doesn't happen.

This is my experience in Windows 7 using SeaMonkey 2.1 and 2.2.  This didn't used to be the case with previous versions of SeaMonkey.  When I open SeaMonkey Mail from the taskbar icon, I want SeaMonkey Mail to remain associated with that icon.  If I later choose to open the browser, clicking on the browser icon on the taskbar just brings the mail window to focus instead of opening the browser.  However if SeaMonkey Mail is not open, clicking on the browser icon will open the browser as it should.

The mail icon never remains highlighted after opening SeaMonkey Mail from it.  It is highlighted for a few seconds, then only the browser icon is highlighted.
Comment 22 Justin Wood (:Callek) 2011-08-01 00:10:48 PDT
I *think* what I am planning to do is the only way Windows + Gecko currently supports this.

I'm just going to add jumplist tasks for opening mail, etc. (the default app action can still be set in normal prefs, and would be the preferred way for using the icon in the taskbar)
Comment 23 Justin Wood (:Callek) 2011-08-01 00:15:08 PDT
Created attachment 549725 [details]
Screenshot of patch v1.0
Comment 24 Justin Wood (:Callek) 2011-08-01 00:16:33 PDT
Created attachment 549726 [details] [diff] [review]
v1.0 Add the tasks.

This should do it.
Comment 25 Jens Hatlak (:InvisibleSmiley) 2011-08-01 01:40:20 PDT
Comment on attachment 549726 [details] [diff] [review]
v1.0 Add the tasks.

>+++ b/suite/locales/en-US/chrome/browser/taskbar.properties
>@@ -2,6 +2,14 @@ taskbar.tasks.newTab.label=Open new tab
> taskbar.tasks.newTab.description=Open a new browser tab.
> taskbar.tasks.newWindow.label=Open new window
> taskbar.tasks.newWindow.description=Open a new browser window.
>+taskbar.tasks.mailWindow.label=Open Mail & Newsgroups
>+taskbar.tasks.mailWindow.description=Open Mail & Newsgroups window.
>+taskbar.tasks.composeMessage.label=Write new message
>+taskbar.tasks.composeMessage.description=Write a new message.
>+taskbar.tasks.openAddressBook.label=Open address book
>+taskbar.tasks.openAddressBook.description=Open your address book.
>+taskbar.tasks.openEditor.label=Open new Composer page
>+taskbar.tasks.openEditor.description=Open a new composer page.

Drive-by: I think Address Book (in .label) should be capitalized; alternatively apply title case to everything.
Comment 26 neil@parkwaycc.co.uk 2011-08-01 02:18:28 PDT
Comment on attachment 549726 [details] [diff] [review]
v1.0 Add the tasks.

I don't have W7 but I'll mark r+ if someone who does marks f+.

>+taskbar.tasks.mailWindow.label=Open Mail & Newsgroups
>+taskbar.tasks.mailWindow.description=Open Mail & Newsgroups window.
Should say "Open the" or "Open a" (depending on whether reuses the window or not)

>+taskbar.tasks.composeMessage.label=Write new message
>+taskbar.tasks.composeMessage.description=Write a new message.
Thunderbird renamed it to Write, but we still call it Compose.

>+    iconIndex:        0, // SeaMonkey app icon
Do we need a followup to get our various icons into the .exe or is there a way to set the icon from $BIN/chrome/icons/default/*.ico?
Comment 27 Robert Kaiser (not working on stability any more) 2011-08-01 04:41:11 PDT
(In reply to comment #22)
> I *think* what I am planning to do is the only way Windows + Gecko currently
> supports this.

Toolkit and Win7 do support having different windows of the same application have different IDs and report as separate things to the Win7 task bar, if you were questioning that. The toolkit support for this was build especially for us in bug 560846.
Comment 28 Justin Wood (:Callek) 2011-08-01 16:11:16 PDT
(In reply to comment #26)
> Comment on attachment 549726 [details] [diff] [review] [diff] [details] [review]
> v1.0 Add the tasks.
> 
> I don't have W7 but I'll mark r+ if someone who does marks f+.

I do have win7, and tested it, if that counts ;-)

> >+    iconIndex:        0, // SeaMonkey app icon
> Do we need a followup to get our various icons into the .exe or is there a
> way to set the icon from $BIN/chrome/icons/default/*.ico?

There is a bug on file for Thunderbird for this, I was planning on building on what they do.

(In reply to comment #27)
> (In reply to comment #22)
> > I *think* what I am planning to do is the only way Windows + Gecko currently
> > supports this.
> 
> Toolkit and Win7 do support having different windows of the same application
> have different IDs and report as separate things to the Win7 task bar, if
> you were questioning that. The toolkit support for this was build especially
> for us in bug 560846.

OOO I was not aware of that Gecko bug. The question then, is "do we want that way"? and if so we'll then have to split these task choices up too.

In the end, this patch is a short-term-fix even if we do want that.
Comment 29 Robert Kaiser (not working on stability any more) 2011-08-02 05:15:22 PDT
(In reply to comment #28)
> OOO I was not aware of that Gecko bug. The question then, is "do we want
> that way"? and if so we'll then have to split these task choices up too.

Any step is good - we should just keep in mind (and an open bug somewhere) to actually go and use that functionality as well, esp. as they built it due to our wish.
Comment 30 Frank Wein [:mcsmurf] 2011-08-03 14:12:18 PDT
Comment on attachment 549726 [details] [diff] [review]
v1.0 Add the tasks.

Capitalize the Address Book and adjust "Open a new composer page." so that Composer is capitalized. Rest is fine.
Comment 31 Justin Wood (:Callek) 2011-08-10 00:33:14 PDT
http://hg.mozilla.org/comm-central/rev/3b67c67a2ab0

Filed Bug 677484 for the other work this bug was about.
Comment 32 Philip Chee 2011-08-22 08:36:58 PDT
Comment on attachment 549725 [details]
Screenshot of patch v1.0

Cancelling stale ui-review request.

Note You need to log in before you can comment on or make changes to this bug.