Closed Bug 515734 Opened 15 years ago Closed 13 years ago

Provide More Entries in the Win7 Jumplist Tasks list.

Categories

(SeaMonkey :: OS Integration, defect)

x86
Windows 7
defect
Not set
normal

Tracking

(seamonkey2.1 wontfix)

RESOLVED FIXED
seamonkey2.5
Tracking Status
seamonkey2.1 --- wontfix

People

(Reporter: jasonb, Assigned: Callek)

References

(Blocks 2 open bugs)

Details

Attachments

(2 files)

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).
This may or may not have some dependency on bug 505925 - I'm not sure.
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.
Depends on: 473045
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?
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.
Blocks: 473045
No longer depends on: 473045
Summary: Individual SeaMonkey components are not properly handled by the Windows 7 taskbar. → SeaMonkey jumplist behaviour on Windows 7 broken by bug 473045.
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.
Strange.  As of an 11/12 trunk build, the behaviour has gone back to what was originally reported.
No longer blocks: 473045
Summary: SeaMonkey jumplist behaviour on Windows 7 broken by bug 473045. → Individual SeaMonkey components are not properly handled by the Windows 7 taskbar.
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.
Depends on: 505925, 521141
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.
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.
(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.
(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.
Depends on: 560846
No longer depends on: 505925
No longer depends on: 521141
(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! :)
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?
Blocks: 566138
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
Sure, I have no problem testing - just tell me what I need to do.
Jason, now that Bug 581526 is fixed do you still see the problem with SeaMonkey 2.1?
> 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.
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!
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.
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);
(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.
Whiteboard: [good first bug]
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)
Assignee: nobody → bugspam.Callek
Status: NEW → ASSIGNED
Attachment #549725 - Flags: ui-review?(bugzilla)
This should do it.
Attachment #549726 - Flags: review?(bugzilla)
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 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?
(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.
(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.
(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 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.
Attachment #549726 - Flags: review?(bugzilla) → review+
Blocks: 677484
Summary: Individual SeaMonkey components are not properly handled by the Windows 7 taskbar. → Provide More Entries in the Win7 Jumplist Tasks list.
http://hg.mozilla.org/comm-central/rev/3b67c67a2ab0

Filed Bug 677484 for the other work this bug was about.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [good first bug]
Target Milestone: --- → seamonkey2.5
Comment on attachment 549725 [details]
Screenshot of patch v1.0

Cancelling stale ui-review request.
Attachment #549725 - Flags: ui-review?(bugzilla)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: