Closed Bug 1063625 Opened 5 years ago Closed 4 years ago
Show the "Warn me when closing multiple tabs" and "Warn me when opening multiple tabs might slow down &brand
Short Name;" checkboxes only when needed
The "closing multiple tabs" and "opening multiple tabs might slow down &brandShortName;" warnings provide options for not showing these warnings again. The main pref pane provides checkboxes for re-enable the warnings. When the warnings are enabled (default state), these checkboxes aren't of much use, clutter up the UI and potentially confuse users, so we shouldn't show them.
What about on screenshots/tutorials that will guide users to changing these prefs?
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #3) > What about on screenshots/tutorials that will guide users to changing these > prefs? Do such tutorials actually exist or is that a hypothetical question? I don't see what such a tutorial would be good for. Like I said, I don't think these checkboxes are useful by default, as the option to turn off each of these warning is part of the warning itself, which is a much better context for the user to decide to disable it.
All hypothetical, but I don't think the hiding/showing of checkboxes based on previous actions is good. If we went this route, I think that these prefs should still be findable via the in-content prefs searching and as discussed offline, you mentioned that we also need to make sure that duplicate accesskeys don't get added.
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #5) > All hypothetical, but I don't think the hiding/showing of checkboxes based > on previous actions is good. It's not ideal, but I think it's better than cluttering the UI with checkboxes that don't provide any value to most users. > If we went this route, I think that these prefs should still be findable via > the in-content prefs searching I don't think this makes sense. What would be the motivation for searching for these prefs and why should search results be different from the list of tab prefs shown? The use case for disabling these tab warnings is that you're annoyed by them, and that use case is covered by the warnings themselves providing the option not to be shown again. > and as discussed offline, you mentioned that > we also need to make sure that duplicate accesskeys don't get added. Yes, that's just something we need to keep in mind when adding new access keys. This is to some extent already the case for the showTabsInTaskbar checkbox which is only shown on Windows.
Hm, I'm definitely a fan of having less checkboxes in this area. However, dynamically showing and hiding prefs based on interactions elsewhere in the UI is an entirely new pattern, so I'm hesitant here. Stephen, what do you think of this?
Comment on attachment 8485067 [details] after.png OK, re-reading this bug a lot later, I'm not sure why I was so hesitant back then. There is one requirement however: When the user has warning turned off and turns it on in about:preferences, the checkboxes should remain in there until restart (perhaps your patch already does that, I didn't have a chance to apply and build it).
Attachment #8485067 - Flags: ui-review?(philipp) → ui-review+
Iteration: --- → 40.3 - 11 May
Points: --- → 2
Comment on attachment 8598666 [details] [diff] [review] patch v2 Review of attachment 8598666 [details] [diff] [review]: ----------------------------------------------------------------- r=me but we should get this in for windowed preferences too. I think 41 will be the release where ICP and windowed preferences will start to diverge and we can remove the old preferences (leaving a buffer in case Release uncovers issues that cause us to disable).
Attachment #8598666 - Flags: review?(jaws) → review+
Verified fixed on Windows 7 64bit, Ubuntu 13.10 32bit and Mac OSX 10.9.5 using latest Nightly 40.0a1 (buildID: 20150508030204): the "Warn me when closing multiple tabs" and "Warn me when opening multiple tabs might slow down &brandShortName" checkboxes are no longer displayed by default.
You need to log in before you can comment on or make changes to this bug.