1361786 - Highlight the Firefox item in the Windows task bar as soon as possible

Status: RESOLVED WONTFIX

(Core :: Widget: Win32, enhancement)

Description

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

In Bug 1336227 we tried to show a blank window early when Firefox starts up in order to shorten the perceived time the startup takes. That has proven too difficult in the short term though.

A related measure that might get us some improvements and could be easier to implement is to show/highlight the Firefox item in the task bar sooner.

Currently, the item only gets highlighted once the window is visible, which often takes quite a bit. Especially when launching Firefox through a desktop shortcut, this feels very indirect since there is no timely feedback.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

We might be able to do this by opening up a _hidden_ window off of the main thread early during start-up. That is, assuming that there's not a better windows API for adding / highlighting the app item in the taskbar.

jimm, how feasible is this?

Comment 2

[Jim Mathies [:jimm]]

(In reply to (Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #0)
> In Bug 1336227 we tried to show a blank window early when Firefox starts up
> in order to shorten the perceived time the startup takes. That has proven
> too difficult in the short term though.
> 
> A related measure that might get us some improvements and could be easier to
> implement is to show/highlight the Firefox item in the task bar sooner.
> 
> Currently, the item only gets highlighted once the window is visible, which
> often takes quite a bit. Especially when launching Firefox through a desktop
> shortcut, this feels very indirect since there is no timely feedback.

On Win7 I see a highlight the instance I press the Firefox icon, but I have Firefox pinned. Are you interested in the icon that shows up once we create the main window in cases where the user does not have the application pinned to the task bar?

Side note: might be interesting to detect the presence of a pinned start menu shortcut and send this to telemetry.

Comment 3

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Yeah, it looks like Windows 7 behaves slightly differently here.
On Windows 10, there is no highlight until the first window gets created.

But even on Windows 7 with a pinned item in the task bar, no feedback is given when launching Firefox using a desktop shortcut or through the start menu. So I'd treat the scenario of clicking a pinned icon on Windows 7 as an exception.

Does that answer your question? If not, we can also jump on a quick call to clear things up :)

Comment 4

[Jim Mathies [:jimm]]

(In reply to (Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #3)
> Yeah, it looks like Windows 7 behaves slightly differently here.
> On Windows 10, there is no highlight until the first window gets created.
> 
> But even on Windows 7 with a pinned item in the task bar, no feedback is
> given when launching Firefox using a desktop shortcut or through the start
> menu. So I'd treat the scenario of clicking a pinned icon on Windows 7 as an
> exception.
> 
> Does that answer your question? If not, we can also jump on a quick call to
> clear things up :)

Nope, that clears it up.

(In reply to Mike Conley (:mconley) - At work week, slow to respond from comment #1)
> We might be able to do this by opening up a _hidden_ window off of the main
> thread early during start-up. That is, assuming that there's not a better
> windows API for adding / highlighting the app item in the taskbar.
> 
> jimm, how feasible is this?

First thought would be to look at some sort of temporary window that triggers the flash. We'd have to experiment, see what works.

Comment 5

[Jim Mathies [:jimm]]

(In reply to Jim Mathies [:jimm] from comment #4)
> (In reply to (Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX)
> please use needinfo from comment #3)
> > Yeah, it looks like Windows 7 behaves slightly differently here.
> > On Windows 10, there is no highlight until the first window gets created.
> > 
> > But even on Windows 7 with a pinned item in the task bar, no feedback is
> > given when launching Firefox using a desktop shortcut or through the start
> > menu. So I'd treat the scenario of clicking a pinned icon on Windows 7 as an
> > exception.
> > 
> > Does that answer your question? If not, we can also jump on a quick call to
> > clear things up :)
> 
> Nope, that clears it up.
> 
> (In reply to Mike Conley (:mconley) - At work week, slow to respond from
> comment #1)
> > We might be able to do this by opening up a _hidden_ window off of the main
> > thread early during start-up. That is, assuming that there's not a better
> > windows API for adding / highlighting the app item in the taskbar.
> > 
> > jimm, how feasible is this?
> 
> First thought would be to look at some sort of temporary window that
> triggers the flash. We'd have to experiment, see what works.

/s/Nope/Yep, it answers my question :)

Comment 6

[Florian Quèze [:florian]]

Hey Jim, as discussed today at the all-hands, it would be nice if you could do some exploration here to see if there's a taskbar API we could use for this on Windows 10, or some tricks using a hidden window.

Comment 7

[Thom Chiovoloni [:tcsc] (ex-moco)]

I took a look into this and am not sure it's possible with ideal behavior. That is, there's no dedicated API for this, and while you can simulate it with a hidden window and ITaskbarList, it ends up having an obvious swap (as well as some weird behavior before the swap, but we could probably work that out with some engineering).

I created a small program (well, modified something I had around already) to explicitly:

1. Create a hidden window.
2. Force window to appear in taskbar (via ITaskbarList::AddTab).
3. Wait some time (e.g. spin a message loop for the hidden window for about 3 seconds, or Sleep(3000)).
4. Remove hidden window and create main application window (order didn't matter for anything I did).

The behavior of this differs slightly depending on whether or not the window is pinned to the taskbar.

If it isn't pinned, then a non-focused window displays in step 2 (no flash until step 4, but the item is in the taskbar with the little underline indicating it is open). At step 4 it appears to close at the same time as another window replaces it, e.g. what we are doing is pretty obvious to anybody looking at the taskbar (although maybe this doesn't matter?)

If it is pinned, then we get the little underline and indication that the window is open, but it doesn't get highlighted until step 4.

If pumping the message loop during step 3 is a problem, things behave worse. If you don't pump it at all, the icon for the hidden window is wrong, if you pump it some but not the whole time, things are not entirely deterministic, as you might expect.

If I do this off of the main thread, there's obviously no issue pumping the window, but you still have the same issues mentioned previously, I think this is probably the case that we'd go for if we want to do this bug, but it doesn't seem entirely trivial to me (I could be wrong though, and haven't actually made an attempt).

Comment 8

[Thom Chiovoloni [:tcsc] (ex-moco)]

:jimm, :florian, I was told that I should needinfo you two to find out whether or not you think this is worth doing, given that it's probably a decent chunk of work and it might not be doable in an ideal way.

Comment 9

[Florian Quèze [:florian]]

This is mostly a UX question, so forwarding to Philipp.

Comment 10

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Well, that does depend on how decent the chunk of work is ;)
From your description of the behavior, that sounds acceptable to me.

However, the only reason that this bug exists is because we aren't able to get bug 1336227 into 57. If it ends up being a similar amount of work, it probably makes more sense to focus our efforts there.

Comment 11

[Jim Mathies [:jimm]]

If we can't get the focus changes to work/look right then I don't see a good reason to invest in this discovery. bug 1336227 would love to have an owner and could solve this through deeper changes.

Comment 12

[Robert Strong (they/them - no direct email)]

Shell integration doesn't have any taskbar code and the taskbar code is actually under Core -> Widget Win32

Comment 13

[Florian Quèze [:florian]]

Bug 1336227 is a better solution, and I think it could be done with only front-end code changes, so closing this platform bug.