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.

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?

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

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

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

(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 :)

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.

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

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

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

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.

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.

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

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