Closed Bug 864420 Opened 11 years ago Closed 11 years ago

Cut button in Australis menu could fall back to copy if unavailable

Categories

(Firefox :: Menus, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: akeybl, Unassigned)

References

(Blocks 1 open bug)

Details

Cut button in Australis menu could fall back to copy if unavailable. This could also be mitigated by showing the button as unavailable (doesn't seem to be the case right now).
I don't think this is something that we should do.

The "Cut" metaphor has two outcomes:
1) The selected objects are placed in the Copy buffer.
2) The selected objects are removed from the document.

When both of the above are possible, we enable the Cut button. When the text is readonly, we disable the button.

By observation, I've seen users who repeatedly use Cut as a method for removing text.

Only providing #1 but #2, would show an enabled Cut button that doesn't provide the full Cut experience. So users who depend on Cut to remove text would be confused that the Cut button was actionable but didn't actually remove the text.

This doesn't seem to be a net-win to me.
(In reply to Alex Keybl [:akeybl] from comment #0)
> Cut button in Australis menu could fall back to copy if unavailable. This
> could also be mitigated by showing the button as unavailable (doesn't seem
> to be the case right now).

The reason why it might not look unavailable to you atm, is because on OSX the disabled state of these buttons is rather unclear. This is because of bug 870865.

If you're OK with it, I'd like to RESOLVE this bug as a DUPLICATE of bug 870865 - which will be fixed soon (P2 priority == high).
The "unavailable" thing is probably bug 870865. I don't think we should do the fallback, since that's a non-standard thing.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.