Closed Bug 1224635 Opened 9 years ago Closed 9 years ago

Only show global Panorama deprecation message when first somehow interacted with tab groups

Categories

(Firefox Graveyard :: Panorama, defect)

defect
Not set
normal

Tracking

(firefox44 affected, firefox45 unaffected, firefox46 unaffected)

RESOLVED WONTFIX
Tracking Status
firefox44 --- affected
firefox45 --- unaffected
firefox46 --- unaffected

People

(Reporter: Dolske, Assigned: Gijs)

References

Details

Attachments

(1 file)

I updated Nightly and got the deprecation message from bug 1221500. I think there are a couple things we should consider improving before shipping it: 1) I'm not sure it makes sense to show it immediately upon an upgrade to Firefox 44. Other things may be changing in their browser, and it's generally a bit of a sensitive time. (e.g. We might have changed something, addons might have broken, or users associate updates with random breakage not actually related to the update.) 2) The code in 1221500 just checks to see if there are any tab groups present. I was a bit surprised to see the infobar, because I thought I cleared out all my tab groups many months ago... Turn out I actually had one I forgot to clear. As noted in bug 1221050 comment 41, I'm a little concerned that there may be a significant population of users who tried Tab Groups in the past, but haven't used it recently. I think if a user hasn't actively used Tab Groups for a period of time, warning them about its removal is likely to be more confusing than helpful. How to fix? I'd propose only showing the infobar after the user has switched tab groups. This has the advantage of displaying the notification when it's most relevant to the user. This addresses both of my concerns at the same time. That does mean if a user hasn't used tab groups for ~6 weeks, they won't see any deprecation warning upon update. I think that's fine, given (1) low usage (2) it's just informational and (3) some users already won't see it anyway, because they're on ESR (aiui we can't do this on ESR 38.x because string-freeze) or they just skip updating to Firefox 44 before Firefox 45. An alternative would be to scrape through all the inactive tab groups, and extract the maximum lastAccessedTime from the tab sessionstore data. That should tell us the last time the user actually used some tab in another group, and then we could just suppress the startup infobar if that date is older than some threshold. We'll probably want to do the same thing when actually migrating tabs -- if the user hasn't used their tab groups in a long time, just silently convert them to bookmarks. [Would it be useful to get a probe into Beta ASAP, to get some data on how old the newest tab in a user's tab groups is?]
(In reply to Justin Dolske [:Dolske] from comment #0) > I'd propose only showing the infobar after the user has switched tab groups. > This has the advantage of displaying the notification when it's most > relevant to the user. This addresses both of my concerns at the same time. This doesn't really make sense to me. There is no way to switch without going into panorama, right? And we display a warning in there. Not sure what the point of showing another one outside it would be if we only do that after switching groups. It sounds more like, according to this bugreport, we should just get rid of the general warning outside tab groups. > An alternative would be to scrape through all the inactive tab groups, and > extract the maximum lastAccessedTime from the tab sessionstore data. That > should tell us the last time the user actually used some tab in another > group, and then we could just suppress the startup infobar if that date is > older than some threshold. This we could do. I'm a little worried that at this point such a change would get very little testing because ~everyone on Nightly has already gotten this warning. > We'll probably want to do the same thing when actually migrating tabs -- if > the user hasn't used their tab groups in a long time, just silently convert > them to bookmarks. Please note this in bug 1221050 if you haven't already. > [Would it be useful to get a probe into Beta ASAP, to get some data on how > old the newest tab in a user's tab groups is?] Beta is getting on already (end of next week we'll be halfway through the cycle, I think?) and so I'm not sure whether we shouldn't just implement it with a best guess (say, 1 month) for a threshold, if we think that's valuable. Somewhat orthogonally, after this whole thing has shipped, I'd quite like to do a post-mortem about what I believe is the first "dead" thing on our great or dead list. I think we need to be more deliberate about what we "make dead" and how. The effort we're spending now feels like too much.
(In reply to :Gijs Kruitbosch from comment #1) > > I'd propose only showing the infobar after the user has switched tab groups. > > This doesn't really make sense to me. There is no way to switch without > going into panorama, right? And we display a warning in there. Not sure what > the point of showing another one outside it would be if we only do that > after switching groups. Oh! I didn't realize we added one there too! So, even simpler, we could just remove the global notification bar, and maybe make the in-panorama notification more visible. (I didn't see it, but then I wasn't actually using Panorama.) > Somewhat orthogonally, after this whole thing has shipped, I'd quite like to > do a post-mortem about what I believe is the first "dead" thing on our great > or dead list. I think we need to be more deliberate about what we "make > dead" and how. The effort we're spending now feels like too much. Sure, let's talk about that.
Summary: delay/skip tab group deprecation message → delay/skip global Panorama deprecation message
Per discussion with dolske, we should show the global notification bar not on startup but when (first): - switching tab groups - moving a tab to a different group - interacting with tab groups in some other way... (?)
Summary: delay/skip global Panorama deprecation message → Only show global Panorama deprecation message when first somehow interacted with tab groups
(In reply to :Gijs Kruitbosch from comment #3) > Per discussion with dolske, we should show the global notification bar not > on startup but when (first): > - switching tab groups > - moving a tab to a different group > - interacting with tab groups in some other way... (?) So I'd see this global notification if I used the CTRL+` shortcut or if I right-clicked on a tab and used the "move to group" function?
(In reply to Verdi [:verdi] from comment #4) > (In reply to :Gijs Kruitbosch from comment #3) > > Per discussion with dolske, we should show the global notification bar not > > on startup but when (first): > > - switching tab groups > > - moving a tab to a different group > > - interacting with tab groups in some other way... (?) > > So I'd see this global notification if I used the CTRL+` shortcut or if I > right-clicked on a tab and used the "move to group" function? Once, yes. I'd probably want to key off the actual group switch rather than the shortcut because otherwise we'll miss things done via third-party UIs like tab-groups-helper. Right now we always show it on startup if you have groups, which is problematic if you don't actually use those groups. Are there other panorama-related interactions we should be covering here?
Flags: needinfo?(mverdi)
(In reply to :Gijs Kruitbosch from comment #5) > > Once, yes. I'd probably want to key off the actual group switch rather than > the shortcut because otherwise we'll miss things done via third-party UIs > like tab-groups-helper. Cool. I just wanted to clarify that someone would see this warning without going into the tab groups window. Nice that it will work if you're using something like Tab Groups Helper. > > Are there other panorama-related interactions we should be covering here? Nothing that I can think of.
Flags: needinfo?(mverdi)
This is a patch against beta.
Attachment #8699432 - Flags: review?(dolske)
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Per https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.planning/jDiniugtwgU I think this is now effectively WONTFIX. Dolske, does that sound reasonable or do you think we need to push for this?
Flags: needinfo?(dolske)
Yeah, it makes me sad that we did that right after the long holiday break, but I can't really defend this patch as a super critical change. :/
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(dolske)
Resolution: --- → WONTFIX
Attachment #8699432 - Flags: review?(dolske) → feedback+
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: