1279391 - Bookmark editor wrongly replaces "cancel" button with "remove"

Status: RESOLVED WONTFIX

(Firefox :: Bookmarks & History, enhancement)

Description

[Perry Wagle]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160604131506

Steps to reproduce:

Current tab contains URL with bookmark with 16 tags.
Hit star to open "Edit Bookmarks".
Realize that I didn't want to do this, and INSTINCTIVELY (10 years of muscle memory) hit the cancel button.


Actual results:

The bookmark and its 16 tags were irrevocably deleted, since the CANCEL button has been replace by the REMOVE_BOOKMARK button.


Expected results:

Either nothing should have happened (no button there), or cancel the transaction should have been performed by having a cancel button there.

A cancel button should never ever be replaced with its opposite, delete, even if you buy the "too cluttered" accusation for the bookmark editor window, which I don't.

By default, the bookmark editor window has been crippled by being fixed size and way too tiny (a long standing complaint).  In this state, the itty-bitty window was spuriously accused of being too cluttered, and crippled even more by having its cancel (abort all changes, ie "please don't do anything") button removed by bug 1247830.

I just now deleted yet another bookmark due to this misplacement, so am quite a bit upset.  It will take hours to recover.

Comment 1

[Perry Wagle]

Sorry if I sound too emotional.  I just screwed myself again, and I'm frustrated with the heretofore lack of much response to what is a critical issue for me.  And to the years-long-standing lack of remedy to several other issues.  I tried to explain that away above, and maybe didn't succeed.  Note that I don't take myself seriously, even with very pissed.


A couple of unclear things noticed in private messages with me:

(1) If you make a botch of things in VIM, do you undo 100 times, or do you ":q!" (ie, cancel)?  I do the latter, since its faster and less error-prone.  Same thing here.

(2) If you intend to exit without saving changes in VIM, do you ":q!" (cancel), or do you "ZZ" (save).  I do the former, since I might have made spurious changes and its faster to not redundantly save.  Same thing here.

(3) It takes hours for me to restore a day old firefox bookmarks backup.  I did this yesterday.

Comment 2

[arni2033]

- Are you asking for brinning back the "Cancel" button specifically?
- Or maybe the issue here is that "Remove" button is located exactly on the same place where old
"Cancel" button was located? (IMO fix for this would at best just change "Remove" button's location)
- Or maybe the issue here is that there's no way to cancel changes?
Or probably several said issues? I'm not sure, but knowing the current direction of development, it may make sense to file each issue separately.   v_v

I'm only asking to clarify the issue, because I myself was going to file a bug "There's no way to quickly undo changes made in bookmarks panel" - it may be different from your report.

Comment 3

[Perry Wagle]

(1) Cancel.  I have "long" sessions of editing individual bookmark tags, where I add, delete, and modify them using either the text editor box or the list box.  Sometimes I botch things, so CANCEL'ing the whole thing was exactly what I wanted.  Return to last known "pristine" state.

UNDO'ing is different, its for reversing a couple things, but not the last 100 changes.  Or was it 102?  No, it was 105!  I think.  8/

Seriously, using the edit-all-bookmarks window to UNDO is almost useless.  You can't really tell what its doing or what its done, or if its even doing anything.  It seems to depend on which subwindow it thinks you are in too.

I can see wanting to get rid of the unrolling that was necessary to CANCEL the edit-a-single-bookmark editor.  I can see being loathe to add it right back.  But I see no other clear way to get that ability.  Making it a real SQL transactional rollback would be interesting, but very hairy to get right, especially with the notifications flying back and forth about each individual change.

A maybe interesting experiment would be to NOT make the intermediate changes visible until you hit the DONE button.  My intuition says that there is something wrong with that approach, but while it won't tell me what the problem is, its usually right.  So, I thought I'd throw it out to see if I spark any ideas.


(2) Button location.  After a week or so, my muscle memory is only hitting the DELETE button 5% of the time now.  Way too close to where the CANCEL button used to be, and still too close to the DONE button, which has the opposite intent.

-

PLEASE NOTE that the individual bookmark editor is not "too clutters" if you can grow its size like I can with an extension.

Comment 4

[Perry Wagle]

Resizable edit-individual-bookmark-window is a several years old bug that would have been the one to fix here, I think.

Comment 5

[Marco Bonardo [:mak]]

(In reply to Perry Wagle from comment #3)
> Seriously, using the edit-all-bookmarks window to UNDO is almost useless. 
> You can't really tell what its doing or what its done, or if its even doing
> anything.  It seems to depend on which subwindow it thinks you are in too.

Just to clarify and avoid misunderstatements, undo is general for any bookmarks change done anywhere (in any window) and in the reverse order the changes were originally done.

Comment 6

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

While this seems to be a serious usability issue, I don't want to add a risk by planning a fix for this in Fx47. I hope platform triage will review this and plan for some mitigation.

Comment 7

[Perry Wagle]

(In reply to Marco Bonardo [::mak] from comment #5)
> (In reply to Perry Wagle from comment #3)
> > Seriously, using the edit-all-bookmarks window to UNDO is almost useless. 
> > You can't really tell what its doing or what its done, or if its even doing
> > anything.  It seems to depend on which subwindow it thinks you are in too.
> 
> Just to clarify and avoid misunderstatements, undo is general for any
> bookmarks change done anywhere (in any window) and in the reverse order the
> changes were originally done.

If, after clicking on a tag in the edit-individual-bookmark-editor and having it deleted due to its reference count dropping to zero, you check the top menu to see if undo is enabled, it is not.  This is a serious bug all by itself, tedious workarounds notwithstanding.

If you DO go to the edit-all-bookmarks-editor, then you will again find UNDO disabled!  IF you then click in the main SUBwindow, UNDO finally becomes active, and undo'ing does return the deleted tag.  I had to go look for it, since it was not at all obvious something happened.

UNDO in the individual editor would be more obvious, but still easy to get lost in for dozens of undos.

CANCEL was totally obvious as to what it did.

Comment 8

[Perry Wagle]

(In reply to Ritu Kothari (:ritu) from comment #6)
> While this seems to be a serious usability issue, I don't want to add a risk
> by planning a fix for this in Fx47. I hope platform triage will review this
> and plan for some mitigation.

While this bug puts me in severe pain, can you at least move the DELETE button for 47?

I think it was just fine where it was.  If you insist otherwise, at least putting a large-as-possible gap between it and the DONE button would likely make it harder to press by accident.

Comment 9

[Marco Bonardo [:mak]]

(In reply to Perry Wagle from comment #7)
> If, after clicking on a tag in the edit-individual-bookmark-editor and
> having it deleted due to its reference count dropping to zero, you check the
> top menu to see if undo is enabled, it is not

Which top menu? I hope not the Firefox / Edit / Undo menu. That one is only for editor changes.
The only working undo menu for bookmarks is Show All Bookmarks and then IN THE LIBRARY WINDOW Organize / undo menu. When the Library will get merged into content, then it's possible the global undo will work.

Comment 10

[Perry Wagle]

(In reply to Marco Bonardo [::mak] from comment #9)
> (In reply to Perry Wagle from comment #7)
> > If, after clicking on a tag in the edit-individual-bookmark-editor and
> > having it deleted due to its reference count dropping to zero, you check the
> > top menu to see if undo is enabled, it is not
> 
> Which top menu? I hope not the Firefox / Edit / Undo menu. That one is only
> for editor changes.

I run macOS, so there's a top bar with an Edit pulldown.  Seemed similar on ubuntu/unity.

> The only working undo menu for bookmarks is Show All Bookmarks and then IN
> THE LIBRARY WINDOW Organize / undo menu. When the Library will get merged
> into content, then it's possible the global undo will work.

Actually, UNDO works in the edit-individual-bookmark-editor if you edit the text of the tag in the box with the character string that's a list of of all the tags, but not the list box that lets you click on tags.

CANCEL was a way to undo from the edit-individual-bookmark-editor, and now its gone.  I don't think it should be removed at all, but if you are going to overrule me, this was too soon to do so: the grand unified undo doesn't work yet.

Note that I don't like the undo in the edit-all-bookmarks-editor because you can't tell what its doing, if anything.

We I undo, its often that I need to, say, undo precisely 37 of the past 100 edits.  That point used to be delimited by the edit session that could be cancelled.  Now its complete error-prone guesswork if I'm not sure where I've messed up.

Comment 11

[Justin Dolske [:Dolske]]

Discussed this with UX today.

The removal of the cancel button is explicitly desired, and it won't be coming back. So WONTFIX to that angle of this bug. Some of the outline of this thinking is already covered in bug 1247830.

We sympathize with your concern that re effectively changed a button that causes problems with muscle memory, and filed bug 1283551 for shorlander to consider if there's something better we can do there.

Comment 12

[Perry Wagle]

The cancel button was the only reasonable way to undo changes to bookmarks using the individual-bookmark-editor.  Going to the edit-all-bookmarks-editor and undo'ing simply is not a reasonable workflow or solution.

This is not about removing the cancel button per se, it about removing the ability to undo mass changes.  Please have someone remove ":q!" from your VI editor and see how you feel about it.

Fixing undo THEN removing cancel would have been the responsible path to take.

Comment 13

[Perry Wagle]

Moreover (sigh), you are polishing a bad design.

The default individual-bookmark-editor is tiny, insane in that it resizes when scrolling down the list of bookmarks, but is otherwise NOT resizable.  Of course its unpleasant in its unmodified state.  And you have made it even MORE unpleasant in your striving for form over function, especially in the modified state of resizable.

The function of transactional rollback was removed, not just a cancel button.  That function was a mass undo delimited by a very clear landmark (the beginning of the edit session).

This meme of "save continuously" is not necessarily a good one for large sessions.  Undo works well for small numbers of changes,  rollback works for large numbers.

Comment 14

[Perry Wagle]

You are removing, step by step, my ability to implement a good “Get Things Done” implementation in Firefox.

After some thought, I've come to the full realization that what I really need is an explanation of the need to get rid of *functionality* of the CANCEL button, so I can make more reasonable counter-suggestions.  You guys just go on about some great need to be rid of the button itself, but indicate no recognition of what it did.

I can't read minds or retroactively attend closed UX meetings.  What's going on here?  What's the reasoning?

Comment 15

[Perry Wagle]

I finally woke up this morning with a vision of what this bug REALLY is:

TL;DR: your new individual-bookmark-editor now saves all typos.


To maintain a personal wiki, I have a "database" of 1925 bookmarks (one per wiki page) sharing 1642 tags (with complex names) in all sorts of permutations that are constantly changing.  The goal is to view and change the tags in a way that does *not* introduce noise and errors.  The viewer/editor is the individual-bookmark-editor.  Now you've made it into a pure editor that SAVES EVERY TYPO. On average, I *view* 100-300 bookmarks a day.  I *abort* 20 edits a day, and I *save* 200 edits a day.  Yes, that's exhausting, and so I make typos (focus does NOT follow mouse, witness people typing their password into IRC).  I used to be able to bypass 99.999% of the typos by the habit of SAVE'ing *only* the *edit* sessions that should have mods, that I am confident contain no typos, and CANCEL'ing everything else.  This has worked quite well for me.  Up to now, I've discovered less than a dozen *saved* typos in 5 years.  Now, every viewing session is a SAVED editing session, and noise is rapidly accruing. 

The UPSHOT is that you have *eliminated* the ability to correctly maintain a database of 1642 tags that I've spend the past 5 years tuning, and can maintain no-where else.  Wikis need browsers, and only firefox really does tags AND supports my inherited legacy tag query extension.

I cannot now *view* a bookmark without probabilistically adding noise that accumulates.  And UNDO will not save me, since I don't always notice the typos.  I could try UNDO'ing all the typos at the end of a tag editing session, but I DON'T KNOW HOW MANY TYPO'S TO UNDO.  And even if UNDO *were* to be fixed (it's broken), it would be way too easy to over or under undo.  The *cancel* function undid the whole editing *session*, which was *the* natural boundary of new-error-introduction.

If you still don't understand, here's an analogy:  the "less" command (that I know) doesn't colorize programs.  The "vim" editor does colorize.  In *view*ing large numbers of source files, it is handy to use "vim" as a viewer if and only if you type ":q!" to exit the session, and type "ZZ" only to save changes you like.  Now in your grand new vision, you've removed ":q!" entirely and force people to type "ZZ" to exit.  Actually, you save on the fly so "kill -9" won't even save you.

If using tools for things other than their designated purpose (which even birds do) still offends you, consider needing a hammer for a nail, and having only a banana.  Freeze the banana in liquid nitrogen, and it can hammer a nail into a board.  See youtube for visual proof.  By maiming tools like the individual-bookmarks-editor in the fashion you've done is *removing* the ability to use *your* banana as *my* hammer.  Likewise chimps boxes and sticks: http://www.intropsych.com/ch08_animals/chimp_cognition.html .  Yes, it's jury-rigged baling wire and chewing gum, but it works!