1545611 - cmd+W on any pinned tab should prompt to close that tab

Status: REOPENED

(Firefox :: Tabbed Browser, enhancement, P5)

Description

[Dietrich Ayala (:dietrich)]

68.0a1 (2019-04-17) (64-bit) Mac OS X

Use-case for cmd+w: As a user, I want to close the tab I'm on.

Actual behavior, regular tab: Tab closes

Actual behavior, pinned tab: User is sent 4 tabs to the right (in my case)

The current behavior is counter-intuitive. It deviates very far from the user's intent.

Here are different ways to handle this, sorted by alignment with the user's intent (task: close the active tab), and balanced with the fact that it is pinned:

• Prompt to close tab
• Immediately close tab
• Do nothing
• Keep tab open, and activate adjacent tab
• Activate first non-pinned tab

A prompt would match the user model. It strikes the optimal balance between respecting the user intent now (close the tab) and respecting a user intent (pin this tab) made at some prior time.

Prompts are not ideal in many cases, however in this case I believe that aligning with the user model is better than the inexplicable outcome we have now. And it's preferable over semi-destructive behavior (closing the tab immediately - which is undo-able) and frustrating/broken behavior (do nothing).

Note: I know this was implemented as a feature. Please do not close this bug solely because of that. I am filing this because I think the design conclusion behind the original decision was incorrect.

Comment 2

[Dão Gottwald [:dao]]

(In reply to Dietrich Ayala (:dietrich) from comment #0)

Note: I know this was implemented as a feature. Please do not close this bug solely because of that. I am filing this because I think the design conclusion behind the original decision was incorrect.

Well, I marked it a duplicate now simply because it was filed as such. This discussion should probably move to a newsgroup and then, if needed, we can reopen bug 1464358 or file a new one for implementing some new agreed-upon behavior.

Comment 3

[Dietrich Ayala (:dietrich)]

Ok, thanks Dão!

I've updated the bug to follow exactly the process used in bug 1420601.

• title describes the proposed solution
• small discussion occurs
• you fix it, hehe :D

The main divergence from the process in bug 1420601 is that I've outlined the model the user is operating under, and explained the rationale behind the new design.