Closed Bug 887515 Opened 11 years ago Closed 4 years ago

Replace multiple-tab-closing prompt with the ability to restore multiple tabs

Categories

(Firefox :: Menus, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 78
Tracking Status
firefox25 --- wontfix
firefox26 --- wontfix
firefox27 --- wontfix
relnote-firefox --- 78+
firefox78 --- fixed

People

(Reporter: jaws, Assigned: jaws)

References

(Depends on 1 open bug, Blocks 2 open bugs, Regressed 1 open bug)

Details

(Keywords: feature, Whiteboard: [qa-])

Attachments

(1 file, 3 obsolete files)

STR:
Open 10 tabs
Right click on one of the tabs and choose "Close Other Tabs"

Expected:
All the other tabs close
There exists a menuitem to "Undo Close Tabs"

Actual:
A prompt saying "are you sure you want to close 9 tabs"
After hitting Yes, you would have to hit "Undo Close Tab" in the context menu 9 times.
Attached patch Patch (obsolete) — Splinter Review
This patch implements the behavior that we talked about. I'll upload a separate patch later with tests.
Attachment #768457 - Flags: review?(ttaubert)
Comment on attachment 768457 [details] [diff] [review]
Patch

Still needs a little more work.
Attachment #768457 - Flags: review?(ttaubert)
Attached patch Patch v2 (obsolete) — Splinter Review
... and now with tests :)
Attachment #768457 - Attachment is obsolete: true
Attachment #768603 - Flags: review?(ttaubert)
Comment on attachment 768603 [details] [diff] [review]
Patch v2

> <!ENTITY  undoCloseTab.label                 "Undo Close Tab">
> <!ENTITY  undoCloseTab.accesskey             "U">
>+<!ENTITY  undoCloseTabs.label                "Undo Close Tabs">

This should probably have a localization note about where and when this label appears... and that undoCloseTab.accesskey is the access key regardless of which label is used.
Comment on attachment 768603 [details] [diff] [review]
Patch v2

Review of attachment 768603 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/base/content/browser.js
@@ +6287,5 @@
>  
>    var tab = null;
>    var ss = Cc["@mozilla.org/browser/sessionstore;1"].
>             getService(Ci.nsISessionStore);
> +  let numberOfTabsToUndoClose = ss.getNumberOfTabsClosedLastTime(window);

aIndex is only given when undoCloseTab() is called from browser-places.js to indicate that we want to undo-close a specific tab. Even if I call undoCloseTab(0) I don't want the last bunch restored but the first tab in the list.

if aIndex is undefined we should go ahead and restore the last bunch of tabs, otherwise only single ones. For that reason we should fix browser-places.js to use undoCloseTab(0) when "Restore all tabs" is clicked:

http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser-places.js#574

(Although the current version wouldn't actually break, it's just a couple of undoCloseTab() calls that will be ignored.)

::: browser/base/content/tabbrowser.xml
@@ +1518,3 @@
>              return true;
>  
> +          if (!Services.prefs.getBoolPref("browser.tabs.warnOnClose"))

Nit: We could include that in the condition above.

::: browser/components/sessionstore/nsISessionStore.idl
@@ +109,5 @@
> +   * Set the number of tabs that was closed during the last close-tabs
> +   * operation. This helps us keep track of batch-close operations so
> +   * we can restore multiple tabs at once.
> +   */
> +  void setNumberOfTabsClosedLastTime(in nsIDOMWindow aWindow, in unsigned long aNumber);

Maybe rather setNumberOfTabsClosedLast()?

::: browser/components/sessionstore/src/SessionStore.jsm
@@ +1472,5 @@
>    },
>  
> +  setNumberOfTabsClosedLastTime: function ssi_setNumberOfTabsClosedLastTime(aWindow, aNumber) {
> +    if (aWindow.__SSi) {
> +      this._windows[aWindow.__SSi]._numberOfTabsClosedLastTime = aNumber;

I'd rather create a new map (using WeakMaps, like DyingWindowCache) instead of introducing another "add-on attack point".

@@ +1488,5 @@
> +  /* Used to undo batch tab-close operations. Defaults to 1. */
> +  getNumberOfTabsClosedLastTime: function ssi_getNumberOfTabsClosedLastTime(aWindow) {
> +    function min(a, b) {
> +      return a < b ? a : b;
> +    }

Math.min()?

::: browser/locales/en-US/chrome/browser/browser.dtd
@@ +45,5 @@
>  <!ENTITY  bookmarkAllTabs.label              "Bookmark All Tabs…">
>  <!ENTITY  bookmarkAllTabs.accesskey          "T">
>  <!ENTITY  undoCloseTab.label                 "Undo Close Tab">
>  <!ENTITY  undoCloseTab.accesskey             "U">
> +<!ENTITY  undoCloseTabs.label                "Undo Close Tabs">

Like Dão said, a comment to help localizers would be great.
Attachment #768603 - Flags: review?(ttaubert) → feedback+
Attached patch Patch v3 (obsolete) — Splinter Review
Tim, what do you think of this? I don't particularly like the undoCloseTab() function in browser.js, but it was one of the better ways I could think of to reduce duplication.
Attachment #768603 - Attachment is obsolete: true
Attachment #772358 - Flags: review?(ttaubert)
Comment on attachment 772358 [details] [diff] [review]
Patch v3

Review of attachment 772358 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/base/content/browser.js
@@ +6294,5 @@
>    var ss = Cc["@mozilla.org/browser/sessionstore;1"].
>             getService(Ci.nsISessionStore);
> +  let numberOfTabsToUndoClose = 0;
> +  if (Number.isInteger(aIndex)) {
> +    if (ss.getClosedTabCount(window) > aIndex) {

Shouldn't we bail out if the given index is bigger or equal like we did before?

@@ +6302,5 @@
> +    numberOfTabsToUndoClose = ss.getNumberOfTabsClosedLast(window);
> +    aIndex = 0;
> +  }
> +
> +  while (numberOfTabsToUndoClose--) {

If ss.getNumberOfTabsClosedLast() returns zero or someone passes aIndex > ss.getClosedTabCount() we'd loop forever here. Maybe add "> 0"?

@@ +6310,3 @@
>      if (blankTabToRemove)
>        gBrowser.removeTab(blankTabToRemove);
> +    blankTabToRemove = null;

We could include that in the if branch.

::: browser/components/sessionstore/src/SessionStore.jsm
@@ +4685,5 @@
>      this._data.delete(window);
>    }
>  };
>  
> +let ClosedTabCache = {

I think we can find a better name for this. It's not really a cache as it doesn't cache any computed value. Is 'NumberOfTabsClosedLastPerWindow' too descriptive? I'd rather go with something like that.

@@ +4696,5 @@
> +  get: function (window) {
> +    return this._data.get(window);
> +  },
> +
> +  set: function (window, data) {

'data' should probably be 'number' as we know what value to expect here.
Attachment #772358 - Flags: review?(ttaubert) → review+
Addressed review feedback and pushed to try server,
https://tbpl.mozilla.org/?tree=Try&rev=2aa18344597f

As discussed on IRC, NumberOfTabsClosedLastPerWindow no longer has a wrapper object around the WeakMap, and is itself just a WeakMap.
https://hg.mozilla.org/integration/mozilla-inbound/rev/6d739868bd90

I had to remove the {animate:true} from RemoveAllTabsBut due to the test failures. It wasn't clear why the test was failing considering that the similar test for RemoveTabsToTheEndFrom (browser_removeTabsToTheEndFrom.js) doesn't suffer from the same issue. I filed bug 894048 to investigate this.
Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/0f3bc9d8f44e due to causing the following failures:

17:51:33    ERROR - Return code: 1
17:51:34    ERROR - Return code: 1
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Browser has one preview per tab - Got 5, expected 1
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Browser starts with one preview - Got 5, expected 1
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Browser has one preview per tab - Got 8, expected 4
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Correct number of previews after adding - Got 8, expected 4
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Preview is shown as expected
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Preview is shown as expected
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Preview is shown as expected
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Preview is shown as expected
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Browser has one preview per tab - Got 8, expected 4
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Previews are unchanged when disabling - Got 8, expected 4
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Browser has one preview per tab - Got 8, expected 4
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Previews are unchanged when re-enabling - Got 8, expected 4
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Preview is shown as expected after re-enabling
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Preview is shown as expected after re-enabling
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Preview is shown as expected after re-enabling
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Preview is shown as expected after re-enabling
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Browser has one preview per tab - Got 7, expected 3
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Expected number of previews after closing selected tab via controller - Got 7, expected 3
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Browser has one preview per tab - Got 6, expected 2
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Expected number of previews after closing unselected via browser - Got 6, expected 2
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Browser has one preview per tab - Got 5, expected 1
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Expected number of previews after closing selected tab via browser - Got 5, expected 1
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Browser has one preview per tab - Got 6, expected 2
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Got expected number of previews - Got 6, expected 2
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Browser has one preview per tab - Got 5, expected 1
18:10:22  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/modules/test/browser_taskbar_preview.js | Got expected number of previews - Got 5, expected 1
18:16:51  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/tabview/test/browser_tabview_bug624265_perwindowpb.js | leaked until shutdown [nsGlobalWindow #7083 about:blank]
18:16:51  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/tabview/test/browser_tabview_bug624265_perwindowpb.js | leaked until shutdown [nsGlobalWindow #7084 about:blank]
18:16:51  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/tabview/test/browser_tabview_bug624265_perwindowpb.js | leaked until shutdown [nsGlobalWindow #7094 chrome://browser/content/tabview.html]
18:16:51  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/tabview/test/browser_tabview_bug624265_perwindowpb.js | leaked until shutdown [nsGlobalWindow #7092 chrome://browser/content/tabview.html]
After closing bunch of about:blank or about:newtab tabs ss.getNumberOfTabsClosedLast will always return the wrong number of tabs for undo!

since _shouldSaveTabState exclude about:blank and about:newtab we need to exclude such tabs when counting closed tabs.
we need to call ss.setNumberOfTabsClosedLast with the proper number
(In reply to onemen.one from comment #12)
> After closing bunch of about:blank or about:newtab tabs
> ss.getNumberOfTabsClosedLast will always return the wrong number of tabs for
> undo!
> 
> since _shouldSaveTabState exclude about:blank and about:newtab we need to
> exclude such tabs when counting closed tabs.
> we need to call ss.setNumberOfTabsClosedLast with the proper number

Can you please file a bug for this and assign it to me?
Depends on: 895436
https://hg.mozilla.org/mozilla-central/rev/b94553178dfe
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 25
Jared,

Should we remove the `browser.tabs.warnOnCloseOtherTabs` hidden pref now? Or should we fix to keep working its pref in continues?

The latter one's merit is that we don't need any network traffic because it ask us before closing multiple tabs.
The approach of this bug need some network traffics when we undo multiple (many) tabs.
And the approach of this bug is depends on `browser.sessionstore.max_tabs_undo`. So it cannot replace the multiple-tab-closing prompt on that case: Firefox closes 100~200 tabs when user does "close other tabs" and `browser.sessionstore.max_tabs_undo` is 10 or less.
Depends on: 896291
Depends on: 896986
Depends on: 909662
Depends on: 911241
Depends on: 914258
Backed out of Firefox 25 by bug 914258.
Depends on: 931891
Backed out of Firefox 26 (and eventually 27) by bug 931891.
Keywords: feature
Assuming Target Milestone is incorrect here given status flags. 

Ioana, given this is flagged as a "feature", please make sure this gets tested and signed off.
Flags: needinfo?(ioana.budnar)
Target Milestone: Firefox 25 → Firefox 28
Keywords: verifyme
Alexandra will start working in this today and she'll try to sign the feature off before the merge to beta.
Flags: needinfo?(ioana.budnar)
QA Contact: alexandra.lucinet
This feature was backed out of trunk and all branches before reaching the Release builds. There is no need to test this.
Keywords: verifyme
Whiteboard: [qa-]
Target Milestone: Firefox 28 → ---
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Blocks: cuts-tabs
See Also: → 565771
Unassigning as I haven't been working on this and I don't want to hold people up.
Assignee: jaws → nobody
Assignee: nobody → jaws
Status: REOPENED → ASSIGNED
Attachment #772358 - Attachment is obsolete: true
Pushed by jwein@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3d607fcf4dee
Restore multiple tab closings using Undo Close Tab(s) after a multiple-tab operation. r=fluent-reviewers,flod,Gijs
Flags: needinfo?(jaws)
Pushed by jwein@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8aaca63ec5c6
Restore multiple tab closings using Undo Close Tab(s) after a multiple-tab operation. r=fluent-reviewers,flod,Gijs
Regressions: 1642084
Status: ASSIGNED → RESOLVED
Closed: 11 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 78
Regressions: 1642111

Is there a pref to move them out of the submenu? I've been using Close Other Tabs and Close Other Tabs to the Right a lot and this change annoyed me...

there was a backlash against similar change in the past. https://bugzilla.mozilla.org/show_bug.cgi?id=1480472 . what's the reasoning behind the reintroduction?

(In reply to Masataka Yakura from comment #32)

Is there a pref to move them out of the submenu? I've been using Close Other Tabs and Close Other Tabs to the Right a lot and this change annoyed me...

there was a backlash against similar change in the past. https://bugzilla.mozilla.org/show_bug.cgi?id=1480472 . what's the reasoning behind the reintroduction?

These were moved to a submenu because people were accidentally clicking them when trying to do non-destructive operations.

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #34)

(In reply to Masataka Yakura from comment #32)

Is there a pref to move them out of the submenu? I've been using Close Other Tabs and Close Other Tabs to the Right a lot and this change annoyed me...

there was a backlash against similar change in the past. https://bugzilla.mozilla.org/show_bug.cgi?id=1480472 . what's the reasoning behind the reintroduction?

These were moved to a submenu because people were accidentally clicking them when trying to do non-destructive operations.

isn't that what browser.tabs.warnOnCloseOtherTabs guards for?

I also find it very annoying that Close Other Tabs and Close Other Tabs to the Right were moved back to a submenu. This was already fixed once (https://bugzilla.mozilla.org/show_bug.cgi?id=1502083). There should be a simple way to move them out of the submenu.

I also agree that this change needs to be reverted. As Masataka Yakura said in comment #36, that is what browser.tabs.warnOnCloseOtherTabs is for. Moving them to a submenu is solving a problem that doesn't exist, and inconveniencing many other users to do so.

(In reply to Masataka Yakura from comment #36)

isn't that what browser.tabs.warnOnCloseOtherTabs guards for?

warnOnCloseOtherTabs is only used when the number of tabs being closed is greater than the SessionStore limit.

Please stop complaining, things sometimes have to change, and this change is going to help the majority of people that don't have a voice here because they are normal users and so they don't come whining to Bugzilla, what they do when they come into any insignificant problem like the one this patch solved is that they just switch to another browser instead and that is bad for Firefox as a whole.

If you don't like this change you can provide a clean patch to get things back using a preference in about:config

(In reply to monterro from comment #40)

Please stop complaining, things sometimes have to change, and this change is going to help the majority of people that don't have a voice here because they are normal users and so they don't come whining to Bugzilla, what they do when they come into any insignificant problem like the one this patch solved is that they just switch to another browser instead and that is bad for Firefox as a whole.

If you don't like this change you can provide a clean patch to get things back using a preference in about:config

This comment is not really fair. It is impossible to tell how many people will switch to another browser or how many will start using firefox because of one change or another. This is just your assumption. I think all comments and complaints should therefore be taken seriously. We are all dedicated firefox users.

Please revert "close tabs to the right" from submenu

This should not be reverted because it is fixing a super annoying problem that happens to a lot of users, the close tabs options are still there but moved to a submenu, I don't see any of you provide a justifiable explanation on why this should be reverted and why it is more important than the bug it is fixing.

I don't see any reason why a submenu is needed. All the options: 'Close Tabs to the Right', 'Close Other Tabs', 'Undo Close Tabs' and 'Close Tab' can appear on the main menu.

Can you stop fixing what doesn't needs to be fixed already?! You tried moving these 2 options to a submenu already and reverted because people didn't like it. WHY do you KEEP trying to move these options in there? "But some users accidentally close there tabs". Ooh, cry me a river if that happens. I would like to see statistics on the time lost having to open an additional submenu each time VS. an accidental close tabs IF it happens. It just doesn't make sense, is NOT productive at all for power users who have a lot of tabs open and want to kill off everything except for a few tabs on the left where they started.

AT LEAST there should be an option to choose which behavior you want. For a browser that wants to be the alternative for all these 20-in-a-dozen chromium browsers, you really are picking the wrong battles to differentiate yourself.

Stop the shenanigans, bring back the "CLOSE TABS TO THE RIGHT" to the main menu. Thank you.

(In reply to monterro from comment #40)

Please stop complaining, things sometimes have to change, and this change is going to help the majority of people that don't have a voice here because they are normal users and so they don't come whining to Bugzilla, what they do when they come into any insignificant problem like the one this patch solved is that they just switch to another browser instead and that is bad for Firefox as a whole.

If you don't like this change you can provide a clean patch to get things back using a preference in about:config

You literally have a "Firefox Developer edition" (which I use). Why would you force "normal user" features on power users? Beyond comprehension.

(In reply to monterro from comment #43)

This should not be reverted because it is fixing a super annoying problem that happens to a lot of users, the close tabs options are still there but moved to a submenu, I don't see any of you provide a justifiable explanation on why this should be reverted and why it is more important than the bug it is fixing.

What bug do you mean? I didn't even understand why we duscussed this in issue describes closing tabs promt.
You asked why it should be reverted? Very simple, because "close tabs to right" is used a lot and now we have extra step.

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #34)

(In reply to Masataka Yakura from comment #32)

Is there a pref to move them out of the submenu? I've been using Close Other Tabs and Close Other Tabs to the Right a lot and this change annoyed me...

there was a backlash against similar change in the past. https://bugzilla.mozilla.org/show_bug.cgi?id=1480472 . what's the reasoning behind the reintroduction?

These were moved to a submenu because people were accidentally clicking them when trying to do non-destructive operations.

You have special section for closing/restoring, right? If you click to this area - you know what you do.
Why just not to re-arrange items to this:

  • Restore (it's not dangerous)
  • Close tab (nothing serious)
  • Close all tabs to the right (most people move active tab to the left, and close others. So in bad scenario you missed some tabs)
  • Close all tabs (be carefull!)
    =============

In issue you talked about you asked to move close all tabs to submenu when one tab is open. Only one.

I really don't get this. I checked the right click tab context menu again and the "close tabs to the right" and "close others" are almost the only reasons why you would even right click on a tab since there are faster/easier alternatives for most of the items there. An overview:

  • Reload tab: not really that useful as you can just click the refresh icon on the main interface
  • Mute tab: not really that useful as you can just click the mute icon on a tab that has music playing
  • Pin tab: ¯_(ツ)_/¯
  • Duplicate tab: useful
  • Select all tabs : who ever does that ?
  • Bookmark tab: not really that useful as you can just click the bookmark icon on the main interface
  • Move tab: who ever does that, you can just drag the tab.
  • Send tab to Device: ¯_(ツ)_/¯
  • Undo close tab: CTRL+SHIFT+T if you even know this feature exists
  • Close tab: not really that useful as you can just click the close icon on a tab on the main interface

In summary, only Duplicate tab is really useful in that menu + the Close tabs to the right + Close other tabs.
The fact that the Close tabs to the right + Close other tabs are one of the most useful entries on the menu but are placed behind another submenu are really beyond comprehension to me. Please revert, just like was done before or provide options to set this behavior but make the grouping opt-in! Sometimes I really wonder who comes up with these "features". smh.

We will have a meeting tomorrow to discuss the feedback here and determine if we should make any changes. Thanks for your comments and feedback.

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #50)

We will have a meeting tomorrow to discuss the feedback here and determine if we should make any changes. Thanks for your comments and feedback.

Any news to share on what the outcome of the meeting was?

(In reply to mewimab306 from comment #51)

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #50)

We will have a meeting tomorrow to discuss the feedback here and determine if we should make any changes. Thanks for your comments and feedback.

Any news to share on what the outcome of the meeting was?

Thanks, we decided to keep the change and as well as create an article on support.mozilla.org that explains the rationale behind the change and the benefits that Firefox will gain from making said change.

This is the current draft of the article:
"""
In Firefox 78, the Tab context menu has been changed to add a new "Close Multiple Tabs" submenu. Inside of this submenu are options to "Close Tabs to the Right" and "Close Other Tabs".

This change was made for the following reasons:

  1. As feature are added and context menus grow, we would like to keep the size of the menu short enough to be read quickly. One of the ways we can do this is to group similar commands. By grouping the commands that close multiple tabs together, we can shorten the height of the context menu by one menuitem. It should be noted that we also do not want to remove context menuitems just for the sake of it because some context menuitems are the only accessible non-keyboard-shortcut way for keyboard-only users to access such functionality as Pin Tab, Mute Tab, Duplicate Tab, etc.
  2. Some users have reported that they accidentally clicked the "Close Tabs to the Right" and the "Close Other Tabs". While a user has the ability to restore their tabs through the "Undo Closed Tabs" menuitem, some data may have been lost as well as potential increased network usage if we are unable to restore the pages from the Firefox cache. We decided that adding a little "speed bump" before a large destructive action could benefit users. We prefer this over a modal dialog that requires users to move their mouse across the screen and thus requires more time.
  3. The "Close Multiple Tabs" submenu provides us an area to add some extra features that users have asked for over the years such as a "Close Tabs to the Left" option.

"""

Status: RESOLVED → VERIFIED

Release Note Request (optional, but appreciated)
[Why is this notable]: Adds ability to undo close multiple tabs with one click, and rearranges the tab context menu to prevent common errors
[Affects Firefox for Android]: no
[Suggested wording]: The tab context menu now allows for undoing multiple tab closings with a single click, and Close Tabs to the Right and Close Other Tabs have been moved to a submenu.
[Links (documentation, blog post, etc)]: https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/close-multiple-tabs

Restrict Comments: true

added to the draft release notes for firefox 78

See Also: → 1645457
Regressions: 1650635
Regressions: 1652641
Blocks: 1653480
You need to log in before you can comment on or make changes to this bug.