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: Create a wiki with 1923 pages. Bookmark each page. Tag each bookmark with 10 or so tags of various "types". Use my uncertified editbookmarkplus extension (https://github.com/wagle/edit-bookmark-plus/) to grow the size of the edit window so you can actually see the list of tags. Use my semi-certified oldtagspace extension (https://github.com/wagle/tagspace-archive or https://addons.mozilla.org/en-US/developers/addon/oldtagspace/versions/1781154 if you can see it) to query tags to make editing the wiki AND its tags tractable. (1) Edit an individual bookmark. (2) Do tag editing operations until you lose count. (3) Do something wrong, such as clicking on a tag with a reference count of one (making it disappear) or some errant typo. (4) Repeat tag editing operations until you lose count. (5) Try to undo whole tag editing session until (3) is reversed. But consider that you don't want the (2) edits without the (4) edits. You want to start over and redo the whole thing. Actual results: (1) The cancel FUNCTION was removed from that editor, so the whole editing session cannot be reliably undone. (2) The undo function is disabled in that editor, so you cannot even APPROXIMATE a cancel. You don't know how many times to undo, and its easy to over or under undo it. (3) The suggested workaround is to use a subwindow of the all-bookmarks editor to undo changes. This is not a fix. And, a universal undo is a bad idea: flipping between editors makes the "last" change often not the one you want to undo. Expected results: (1) The cancel FUNCTION did exactly what was needed. It aborted the entire editing session, and you started over fresh, like any reasonable text editor. It was removed for apparently only purely aesthetic grounds (closed meeting, no other justifications offered), without even fixing undo so that it actually works from that window. (2) The undo operation is disabled for tag list window edits. (3) The workaround all-bookmarks editor to undo is clumsy and is very error prone. The classical undo shows you the changes it makes, this one does not reliably. The classical undo is used to reverse recent changes, not whole editing sessions. It's not even clear if undo did anything, there seems to NOT be a 1-1 linkage between editing operations and undoable operations. CONCLUSION -- The cancel FUNCTION should be returned. If you are going to insist on keeping the individual bookmark editor tiny and generally unusable for significant tag editing, then sure, remove the cancel BUTTON. I can add it back with an extension if the FUNCTION is there somewhere, perhaps in a pull-down menu.
* Not only bookmark tag edits, but also all edits including changing of bookmark's name and folder
Status: UNCONFIRMED → NEW
status-firefox47: --- → affected
status-firefox48: --- → affected
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox-esr45: --- → unaffected
Ever confirmed: true
See Also: → bug 1279391
Summary: Can no longer undo bookmark tag edits → Can no longer undo bookmark edits (including tag edits)
Whiteboard: [parity-Chrome][regression from bug 1219794]
Same basic issue as bug 1279391.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
This bug is not a duplicate of 1279391, please read it more carefully: The previous bug was about removing the CANCEL button. This bug is about removing the FUNCTIONALITY of that button. The only justification given for removing CANCEL was the claim that it made the dialog window clustered. My complaint here is that the FUNCTIONALITY of CANCEL was the key thing of concern, not the existence of the CANCEL button. I will reopen this bug since it makes explicit the problem not addressed in the treatment of 1279391, where the loss of FUNCTIONALITY was never explained. That FUNCTIONALITY is essential to my workflow, not the button. I just need the functionality back, not the button. With the button, you ripped out the functionality, which looked at a glance like a substantial amount of code.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(1) You'd shut me up if you'd explain what was wrong with having the functionality of the cancel button. You've only said that the button itself clutters the tiny dialog box. (2) With your "must save all errors" regression, it took me 4 weeks (this past month) to do what would have taken me a week to do. I had projected that it would take me a year to get everything in line and completed that was necessary for my replacing the bookmarks subsystem entirely. With the new 4X dilation, that now looks like 4 years. I very well might not live that long. (3) You are eroding the features of bookmarks faster than I can replace them. The above 4X will surely dilate more in the next 1-4 years. It looks undoable. (4) All I need is the functionality of the cancel button returned (ie, all that code you removed). I can add the button back with my extension that resizes the bookmarks editor, if it can operate the code (set mark, revert to mark, or whatever the protocol is). I don't imagine that I can add this back with an extension.
As I said in comment 2, it's the same general issue. We don't need multiple bugs with long rants around an issue that we've already decided we're not reverting. I did file bug 1279391 (as noted in the other bug) since Steven wanted to think about if there's something we can tweak, but it's not clear if there's a likely fix. I'm sorry this affects your workflow(*), but we feel it's a change beneficial for most users. * - https://xkcd.com/1172/
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago → 2 years ago
Resolution: --- → DUPLICATE
You get long "rants" because the only justification for the removal of an important feature was that it "cluttered" a dialog that was reported as way too small and unresizable in 2008 (see 418864) . You don't listen, you don't explain. All I can do is retry until I'm heard. I have no clue what was discussed behind closed doors, so I have to shotgun arguments against every reason I can think of. You slashed the tires on my "wheelchair", laugh, and insult me. As for the xkcd, your only "workaround" was to undo, which doesn't work. If I had a way to add back the functionality myself, I would, and have said as much. I just spend the past month doing 1 weeks worth of work. That is 120 hours you are liable for. I was promised my tag query extension would continue to run for "a while" (months?). As of a month ago, its effective dead. That all is why I continue to protest. I require it to program, and the government agrees. My quote of the day: A man goes to a tailor to try on a new custom-made suit. The first thing he notices is that the arms are too long. "No problem," says the tailor. "Just bend them at the elbow and hold them out in front of you. See, now it's fine." "But the collar is up around my ears!" "It's nothing. Just hunch your back up a little ... no, a little more ... that's it." "But I'm stepping on my cuffs!" the man cries in desperation. "Nu, bend you knees a little to take up the slack. There you go. Look in the mirror -- the suit fits perfectly." So, twisted like a pretzel, the man lurches out onto the street. Reba and Florence see him go by. "Oh, look," says Reba, "that poor man!" "Yes," says Florence, "but what a beautiful suit." -- Arthur Naiman, "Every Goy's Guide to Common Jewish Expressions"
status-firefox48: affected → wontfix
status-firefox49: affected → wontfix
status-firefox50: affected → wontfix
Ah but this scene from Hitchhiker's Guide to the Galaxy is far more indicative of your breed of bureaucrat: https://www.youtube.com/watch?v=HNmIQX_ImgM Except you decided to take my livelihood instead of my house. Just imagine for a second that I am not exaggerating, and imagine having to beg for your life and or livelihood from such bureaucrats every 2-3 months ad infinitum.
You need to log in before you can comment on or make changes to this bug.