1691729 - Single-clicking the Star icon saves bookmarks in an unpredictable folder (after Bug 1432604, if not showing the panel when creating bookmarks)

Status: NEW

(Firefox :: Bookmarks & History, defect, P3)

Description

[PikeUK]

This bug is in reference to the changes to bookmarking made in Bug 1432604 and was requested to be filed by Bug 1432604 Comment 41.

Places in Firefox 3 changed how bookmarking worked: single-click Star to quickly file a bookmark in a known folder (originally called "Unfiled Bookmarks" now known as "Other Bookmarks"), double-click Star to move it into a specific folder. Bug 1432604 breaks this design.

Steps to Reproduce:

1. Visit any web page.
2. Click Star icon in URL bar.
3. Open new tab or restart browser.
4. Open "Other Bookmarks" folder and try to find bookmark saved in step 2.

Actual Results:
The bookmark was not there, it had actually been saved in a "random" folder (the last folder I had explicitly saved a bookmark to a few days ago). I had to search my bookmarks to discover this, at first I thought bookmarking was just broken in the latest beta.

Expected Results:
For the past 13 years, since Firefox 3 / Places, the result of single-clicking the Star was to save a bookmark into "Other Bookmarks" (previously called "Unfiled Bookmarks" and then "Unsorted Bookmarks").

Notes:
This change regresses an explicitly designed UI feature of Places: single-click to quickly file a bookmark in a known folder (originally called "Unfiled Bookmarks" now known as "Other Bookmarks"), double-click to move it into a specific folder. Now a single click will put the bookmark in a "random" location (whichever folder I last happened to save a bookmark to). I'm using the term "random" because I don't keep track in my head of where I last saved a bookmark and I've been trained by the last 13 years of using Firefox to not need to look in the dropdown to find out which folder a bookmark was saved to since I always knew prior to this change. The end result is that Bookmarks just seem to disappear.

It was suggested in Bug 1432604 Comment 40 that this is not an issue because you just need to manually save a bookmark into "Other Bookmarks" once and then future bookmarks will also be saved there. However, this is only a solution if you never save bookmarks into any other folders. If you sometimes single-click star to save and other times use the dropdown to save to a different folder this will not work.

I believe this breaks a fundamental UI design principle, Predicatability, I can no longer predict where a Bookmark will be saved when single-clicking Star (unless I happen to remember the folder I saved my last bookmark into).

I can see two possible workarounds for the user, neither ideal:

1. Never just single-click and move on. Instead always bring up the dropdown and check where the bookmark has been saved and fix if necessary.
2. Never use the folder option in the dropdown. Instead save a bookmark to "Other Bookmarks" once and from then on only move bookmarks by dragging them in the Library and never by changing the folder in the dropdown.

Hopefully this explains the issue, please let me know if you need further information. Thanks.

Comment 1

[fireattack [:fireattack]]

Indeed, each behavior would have their upside and downside, and I get what you described as the downside for the new approach.

The old behavior's downside, on the other hand, is that if you want to save multiple bookmarks into a specific folder, you have to choose the destination every time (two click).

However, the new way require fewer clicks in most of scenarios objectively. One-clicking always saving to "other bookmarks" may save a click in rare cases but you still have to sort them later (which means many more clicks).

This is totally just my personal opinion: try to change the habit and get used the new way. I have been using Chrome (which always uses the "new" way) and Firefox side by side for years, and my experience really is that the new way (or the Chrome way) is better.

But of course, the best would be if the dev can add an option to switch between the two.

Comment 2

[:Gijs (he/him)]

The fundamental issue here is that yes, after a dozen or so years, we changed how bookmarks work a little bit, to make them more discoverable for new users (esp. if they are used to how other browsers handle bookmarks). You knew that bookmarks went into "other bookmarks" by default, and how to retrieve them from there, but most users did not understand this, and the "other bookmarks" folder was not surfaced anywhere obvious, making it undiscoverable. The telemetry data we have shows that our changes here were generally very successful: people are more frequently able to use and rely on where bookmarks are created.

I understand that this is frustrating because your long-established workflow was changed. I'm not really sure what the best solution is; as a partial workaround, you could set the pref browser.bookmarks.defaultLocation to unfiled in the user.js file in your profile (which overrides prefs.js on startup, and because it is never written to by Firefox, it would reset when you restart the browser). This would re-set this value to the "other bookmarks" folder on every startup. Then the only time it would not be the "other bookmarks" folder is after you use the dropdown or bookmarks properties dialog to move a bookmark, while Firefox is running -- as you say, if you consistently used the library or drag/drop to move bookmarks, the selected folder would not change.

As another greasy hack, in the library, you can search all bookmarks for just h, and that (AFAICT) finds any web (http/https) URI you bookmarked. You can adjust the columns and sort by "added" to retrieve bookmarks irrespective of where they were saved.

On the Firefox side, we could try to add yet another checkbox or other preference control to revert to the old behaviour where the default is fixed (though note that various entrypoints to create bookmarks also used different default locations in the past... which is messy and I think is not something we want to go back to). At this point, I don't know that doing so is justified. It adds longer-term complexity and maintenance burden for a usecase we're switching away from, which means it's not super attractive...

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1432604

Comment 4

[Patrick Wigmore]

I am affected by this bug too, although perhaps I have a slightly different angle on it.

I can describe my bookmarks as falling into two broad categories:

1. One-click bookmarks, saved in Other Bookmarks, although the name of the folder is irrelevant. I never look for these in the folder hierarchy. I just search for them using the address bar.
2. Organized bookmarks, saved into a large number of different folders, each folder having a very specific purpose. None of these folders is suitable as a default location for arbitrary bookmarks.

For me, the problem with the unpredictable folder is not that I won't be able to find my one-click bookmarks. It is that I can no longer use the one-click feature without the risk of making a mess of the numerous specific-purpose folders where I save my organized bookmarks. The presence of a bookmark in one of these folders can represent a non-trivial amount of work on my part. For example, I may have spent time researching each of the pages that are bookmarked there. If I fail to notice that a one-click bookmark has been misplaced into one of these folders, it is effectively a kind of data corruption.

As far as I can see, the most practical solution at present is to stop using the one-click feature without looking at which folder the bookmark is going into, and be prepared to change it if it is wrong. However, there is still the risk of an accidental one-click bookmark. Accidental bookmarks don't matter to me if they go into Other Bookmarks or some other collection of arbitrary bookmarks, but they matter a great deal if they go into one of my specific-purpose folders.

Initially I only discovered the new behaviour by reading about it in "What's New". It turned out I had already saved one bookmark in the wrong folder! A lucky catch. I wonder if any other people haven't noticed yet.

I can see the benefit of not having to repeatedly select the same folder if I want to save several bookmarks in the same location. But that is something I will only use occasionally. If I had to choose, I think I'd rather have the option for a fixed default location, as considered in bug #1412263.

Initially I thought the browser might remember the last folder I selected in the UI, rather than the last folder I actually saved a bookmark into. That way, I could save a bookmark into a specific folder, and then change the folder back to "Other Bookmarks", ready for the next bookmark. Would that work as a compromise, in the event of a decision against adding a new preference or additional UI?

Comment 5

[KotW]

I heartily underwrite these previous comments. The problems of this change have been outlined. I can only say that it has destroyed my decades-long bookmarks workflow. Patrick Wigmore above has the same workflow, and has gone to great lengths to describe it.

This change was telegraphed very poorly, and now that I finally realized what the browser was doing, the damage is done - there are probably tens - if not hundreds - of bookmarks of mine that have now been filed in wrong places instead of directly into Other Bookmarks. Mind you, I read each and every release note and update my browser manually due to exactly such problems with new features, so the change must not have been introduced in a very visible manner.

Previous posters have illustrated the issues with this change very well, and I have nothing else to add - except that for users with decades of practice with a specific workflow, it really doesn't hurt to add a switch to keep the old model.

I'm sure the devs just didn't realize how radical this change is: as mr. Wigmore notes, above, the only present solution is simply to stop using single-click bookmarks altogether. I have tens of thousands of bookmarks. You have to understand how frustrating this is.

Comment 6

[KotW]

I'll just add that the problem here is of underlying logic, and, as we have seen with the tabs of the forthcoming Proton UI, the consistent death of logic in computer UI logic and metaphors.

If you consider bookmarks as a filing system, this change -only- works if your archival system has a purely sequential-temporal structure of information.

While I assume most users do not use bookmarks to any meaningful degree, there are most certainly some of us who use bookmarks to file information into categories, themes, and topics.

The baseline logic of archival presented here, the idea that ALL following data being stored after archival of previous information has the same characteristics as the previous one is simply wholly inappicable to actual archival and storage of data as knowledge.

Comment 9

[wojtek]

Yeah, I also was bitten by this change. As stated in #1706120 a sort-of middle ground would be some sort of "timeout" on how long to remember last destination folder:

1. normally bookmarks would be saved in "Other bookmarks" (one click or ctrl+d)
2. while quickly bookmarking (mostly related pages in tab session) remembering last directory would be handy as quick cmd+d / cmd+w would help have all related pages in same place (I'm fairly sure it worked like that previously).

Comment 11

[Jan Doggen]

I landed here because I had reported this as a Ctrl-D bug (although it suspiciously smelled like a 'feature' once I saw what was going on) in https://bugzilla.mozilla.org/show_bug.cgi?id=1708683, which is now marked as duplicate of this issue.

To put it succinctly: the change is a TERRIBLE design decision.

• Several people now report how they found this out late/by accident/when their data were already corrupted. That is just unacceptable in any software package.
• In combination with my reported bug that saves the link without delay I can't even interrupt this default behavior (knowing that I'll have to complete the action quickly)

BTW A workaround is to press Ctrl-D twice. The first time this will put your link in an often unpredictable folder. The second time you can then correct it. That's fine for the time being but I won't put up with this. If this does not get fixed, I'll dump Firefox.

Comment 12

[Patrick Wigmore]

I don't think bug 1708683 is an exact duplicate of this bug, but it is relevant.

The problem that bug 1708683 describes is that, if you don't interact with the bookmark dialog quickly enough, the browser impatiently assumes you are not going to use it, and decides to finish the job for you, on its own terms! This means the bookmark gets automatically saved into a default (i.e. unpredictable last-used) folder, before you have a chance to check which folder it is going into or choose a different one.

I can reproduce that behaviour on my profile, but I didn't notice it before, so either it is new behaviour, or I have never triggered it before.

It seems the dialog only disappears by itself if I don't put my mouse cursor over it or otherwise interact with its widgets (e.g. tab through them).

I would say it is a separate issue from the default folder being unpredictable, but the combination of the two issues obviously exacerbates this bug (1691729) because the disappearing dialog makes it easier to set a bookmark by mistake.

Comment 13

[Jan Doggen]

Agreeing with Patrick here. I reported 1708683 and that is related but not similar; it even even has deteriorated: Ctrl-D now saves immediately

Comment 14

[Mark Banner (:standard8)]

(In reply to Jan Doggen from comment #13)

Agreeing with Patrick here. I reported 1708683 and that is related but not similar; it even even has deteriorated: Ctrl-D now saves immediately

The ctrl-D functionality initially operates as auto-save after so many seconds if the user does not interact. After a few cases like that, we assume the user does not usually intend to interact with the pop-up so Firefox doesn't open it. If you press the star button, you can check "Show editor when saving" to always have the dialog open.

The reason I marked it as a duplicate of this bug is that your bug was about the autosave location, which is precisely what this bug is about. Fixing this bug would fix that one regardless of if you're in the close-after-a-delay cycle or always open or always closed.

Comment 15

[Patrick Wigmore]

Ah, I didn't consider that the auto-save-and-close behaviour might be by design. I assumed it was an unintended consequence of some other feature. Hence: a bug in its own right; perhaps one that only shows up under certain conditions.

But I can't understand why this behaviour exists. It only happens when “Show editor when saving” is enabled, rather than when it is disabled. So, it happens to (presumably) everyone who has actively decided they want to show the editor. Which means there is actually no way to say “Always show editor when saving”. The choice is between “Never show editor when saving” and “Forever second guess whether to show editor when saving”. To me that seems broken, in a way that is distinct from the concerns about the default bookmark location.

The auto-save-and-close behaviour would, however, make perfect sense on newly-created user profiles, where the user has not yet actively decided whether or not to show the editor.

Comment 16

[gbock77]

I'll throw my 2 cents in. I am losing bookmarks all the time with this regression. I absolutely hate it. I have very deep bookmark hierarchies and sometimes I will save to a specific folder, and other times I just like to let bookmarks accumulate in the Other Bookmarks folder to sort them later. Now with this change if I just click the star icon I have NO IDEA where my bookmark went. It may end up in some deep nested bookmark folder somewhere from when I made a bookmark yesterday and left the browser window open. Can somebody please please please tell me how to disable this dreadful non-feature.

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:mak, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 19

[Łukasz]

For having made a REGRESSION of a simple function that worked differently from the very beginning, and now marking this REGRESSION as unimportant and not worth fixing, one feels like calling you the worst.
Mozilla makes a lot of absurd decisions, often on the basis of "because it's like that in Google Chrome." - it doesn't matter that something is done worse in Chrome, you copy from Chrome, remove features "because it is".
I have not seen a worse managed project than Mozilla Firefox. I have a very strong suspicion that Mozilla's management is sabotaging Mozilla.