Closed Bug 1402890 Opened 7 years ago Closed 6 years ago

Stop supporting and remove the description annotation

Categories

(Toolkit :: Places, enhancement, P3)

Product:
Toolkit
Component:
Places
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla63
Tracking Flags:
Tracking Status
firefox-esr52 --- wontfix
firefox-esr60 --- wontfix
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 --- fixed

People

(Reporter: mak, Assigned: standard8)

References

(Blocks 1 open bug)

Details

(Keywords: dataloss, perf, Whiteboard: [fxsearch]) 

Descriptions are a minor feature of bookmarks, they are fetched from the page at the bookmarking time and can be manually edited by the user.
Their usefulness is very limited, since we don't even search on them, and they can (do) affect performance of bookmark operations.

Since now we have a description field in moz_places, used by Activity Stream, we can rely on that, if we really care to show a description anywhere in the UI. It wouldn't be user modifiable though.

Personally I think we should just remove anything that is description-related.
Let's see what UX thinks about this removal proposal.
Flags: needinfo?(bbell)
Blocks: 1276819
Priority: -- → P2
Whiteboard: [fxsearch]
Keywords: perf
I'm not against removing description. But, we should rope in a few more people to help make the final call.
Flags: needinfo?(bbell)
any suggestion who may chime in from UX?

For the coding part, I cc-ed most of the interested parts.
(In reply to Marco Bonardo [::mak] from comment #0)
> Descriptions are a minor feature of bookmarks, they are fetched from the
> page at the bookmarking time and can be manually edited by the user.

> Since now we have a description field in moz_places, used by Activity
> Stream, we can rely on that, if we really care to show a description
> anywhere in the UI. It wouldn't be user modifiable though.

Websites dictating what goes in a user's bookmark without any way to change that would be a terrible idea. Doubly so if it's secretly stored without even being viewable.
It would be nice if a configuration option was available to stop FF from auto-filling the description field. I actually clear such field manually each time and use it for storing mirror urls, notes, etc.
The scope here is to remove the description completely, you may need a different way to annotate bookmarks/pages (maybe a WebExtension)
Bryan, seeing as the mocks for the new UI don't include description, can you confirm we're ok to remove this field now? If not, how do we get the decision made?

We're probably not going to start on this for a week or two, but would be good to get this confirmed.
Flags: needinfo?(bbell)
From irc discussion about removals, we'll need to:

- Remove the various parts from the UI
- Remove the backend code that loads descriptions
- Remove the old description field from the database
--- probably a background maintenance task for now, which might not get everyone (we know the maintenance task isn't always run as we don't hit idle for long enough).
--- However, later we're planning on removal all annotations, which would cleanup the remainder.

A follow-up or maybe part of this bug would be to remove the expander on the library window details pane.
(In reply to Mark Banner (:standard8) from comment #7)
> Bryan, seeing as the mocks for the new UI don't include description, can you
> confirm we're ok to remove this field now? If not, how do we get the
> decision made?
> 
> We're probably not going to start on this for a week or two, but would be
> good to get this confirmed.

Assuming the older Description isn't used with the Awesomebar, then we're clear to remove it.
Flags: needinfo?(bbell)
(In reply to Mark Banner (:standard8) (afk until Tue 8th) from comment #8)
> From irc discussion about removals, we'll need to:
> ...
> --- However, later we're planning on removal all annotations, which would cleanup the remainder.
> ...

So you're planning to remove ALL annotations from Places?  Bookmarks will essentially become a title, URI, and tags?  If someone wanted these features, they would have to create a WebExtension with a backing store and a separate UI?
very likely yes.
Bookmarks will have tags too, maybe in the future some kind of previews, but it will likely not be freeform annotations.
Blocks: 1460577
Wouldn’t it be enough to stop filling the description field with data from the web page? That way people could still save notes associated with exactly that URL or copy short texts from the page to have a local copy in case the page is not available in the future. It seems like most people who know about the description field manually clear it because they don’t want the text from the web page.

Also, some people already have saved important notes in the description. By removing this field you are causing data loss.
(In reply to Martin F. from comment #12)
> Wouldn’t it be enough to stop filling the description field with data from
> the web page? That way people could still save notes associated with exactly
> that URL or copy short texts from the page to have a local copy in case the
> page is not available in the future. It seems like most people who know
> about the description field manually clear it because they don’t want the
> text from the web page.

No, for starters this wouldn't remove the duplication of descriptions in the database that we now currently have. Additionally, the description field is not primary UI, and is only really exposed via the library window (not by default) or sidebar (if you actually enter properties of a bookmark). Those things mean it isn't really primary UI, and we believe there are only a few users using it. It would likely be better to move this type of functionality to an extension, where it could be better supported for those that need it.

There's already various "notes" type extensions available: https://addons.mozilla.org/firefox/search/?platform=mac&q=notes

> Also, some people already have saved important notes in the description. By
> removing this field you are causing data loss.

Unfortunately, we can't always keep supporting everything, this is field is adding complexity that we don't want to maintain in its current fashion, especially for non-primary UI.

I think the current plan is that we'll remove the UI (but still allow the field to be exported behind the scenes) for a version, and then likely the next version, we'll remove support for the field entirely & remove the data. That would give people extra time to be able to save the data.

Note by default we back up the last 15 days of bookmarks data. So there will be json backups which include the description field if the user updates and then finds it missing.
Depends on: 1463738
(In reply to Mark Banner (:standard8) from comment #13)
> (In reply to Martin F. from comment #12)
> > Also, some people already have saved important notes in the description. By
> > removing this field you are causing data loss.
> 
> Unfortunately, we can't always keep supporting everything, this is field is
> adding complexity that we don't want to maintain in its current fashion,
> especially for non-primary UI.
> 
> I think the current plan is that we'll remove the UI (but still allow the
> field to be exported behind the scenes) for a version, and then likely the
> next version, we'll remove support for the field entirely & remove the data.
> That would give people extra time to be able to save the data.
> 
> Note by default we back up the last 15 days of bookmarks data. So there will
> be json backups which include the description field if the user updates and
> then finds it missing.

This is a drastic change for a small number of users, and users may unaware of the UI being removed due to skipping versions, ESR or inactivity. The legacy data of these users may be lost if shelve for more than 15 days after the update. Maybe this should be automatically exported while cleaning and left permanently, as well as multiple copies considered for multiple handovers.
Keywords: dataloss
OS: Unspecified → All
Hardware: Unspecified → All
(In reply to YF (Yang) from comment #14)
> (In reply to Mark Banner (:standard8) from comment #13)
> This is a drastic change for a small number of users, and users may unaware
> of the UI being removed due to skipping versions, ESR or inactivity. The
> legacy data of these users may be lost if shelve for more than 15 days after
> the update.

We accept that this is a risk for some users, we're doing what we can, however we can't leave this obsolete near-duplicated data around forever, with also still supporting the older APIs needed for it.

We can probably wait two versions (i.e. until 64), but we certainly can't wait until the next ESR as that is a year away. For that we'll make sure to add a note to the ESR release note docs. That should be also mitigated by the majority of ESR users being organisational based and hence testing new versions before upgrading to them fully.

> Maybe this should be automatically exported while cleaning and
> left permanently, as well as multiple copies considered for multiple
> handovers.

Whilst this is a nice idea, most users (I'm thinking > 99%) probably wouldn't know about the file or what to do with it or that they should do something with it, and it'd be just left as unnecessary clutter.
Nonetheless, I'd argue that it's a matter of PR among the subset of users most likely to champion Firefox.

When the reading list functionality just vanished on me one day and I rushed to make a backup of reading-list.sqlite in case it got deleted later, it did not leave me with a very good impression of Mozilla. (rather than, for example, seeing that it had been migrated to a folder in the bookmarks store.)

(In fact, I'm currently working on an external utility, to be integrated via WebExtensions, to store all persistent state which I don't feel I can trust Firefox to preserve when 52 ESR drops away. This approach to retiring bookmark descriptions only leaves me feeling more justified in the view that I can't trust Mozilla with my data.)
(In reply to Stephan Sokolow from comment #16)
> (In fact, I'm currently working on an external utility, to be integrated via
> WebExtensions, to store all persistent state which I don't feel I can trust
> Firefox to preserve when 52 ESR drops away. This approach to retiring
> bookmark descriptions only leaves me feeling more justified in the view that
> I can't trust Mozilla with my data.)

Actually, I should probably clarify.

1. I'm currently running ESR and Developer Edition in parallel

2. Just recently, something internal to Firefox broke that I haven't had time to diagnose, and I think I'm going to have to flush and re-create my profile to get it working again. Yet another reason to keep all persistent state somewhere more permanent than a Firefox profile. (This profile only a couple of months old. The last time I had to re-create my legacy profile was during the switch-over from 3.x to 4.x.)
(In reply to Stephan Sokolow from comment #17)
> > I can't trust Mozilla with my data.)

FWIW, you can't trust anything regarding dataloss, that's why backup systems exist. Your hard drive could break tomorrow, or your OS may corrupt yesterday. You can't even trust your NAS unless it's enterprise grade (and still). I don't think this is a problem with Mozilla as it is not with any other company in the world.
I have nightly incremental backups going back two weeks, which are replicated across three different hard drives separate from the one the source data came from, and anything I create myself gets duplicated to at least one service like GitHub (public projects), BitBucket (private projects), or deviantArt as early as possible. I also rely as heavily as possible on RDBMSes (SQLite if nothing else) for their efforts to guarantee ACID and the chance to detect corruption during the "dump for nightly backup" phase.

With all that effort, I don't need my browser having a laissez faire attitude toward the data I entrust to it. (It's actually one reason I use Firefox over Chrome. I've had Chrome's crash recovery itself crash, and it was a pain to manually go into the saved session and transcribe all the URLs back into browser tabs.)
Thus, considered we'll give 2 full cycles and anyone using ESR should have some kind of backups (because it's a big part of the "stability" an ESR entity needs), this change is unlikely to hurt you, in practice. I sympathize with your feelings and trust towards Mozilla, but this kind of niche "features" is dragging our code and performance to a rabbit hole, we're trying to do something that will benefit all users (a more performant and modular browser), but clearly every change has a cost, there's no free meals. We'd not do this if the benefit wouldn't be tangible. The best we can do is to reduce the costs to something "manageable".
Except that I'm only using ESR because extensions like downThemAll haven't been reimplemented yet. Normally, I run pure Developer Edition.

Also, my objection isn't with the removal of niche features. My objection is in making it too easy for a distracted, overworked person, like I sometimes am, to miss that data has been deleted without my consent.
(In reply to Stephan Sokolow from comment #21)
> Also, my objection isn't with the removal of niche features. My objection is
> in making it too easy for a distracted, overworked person, like I sometimes
> am, to miss that data has been deleted without my consent.

That does make a good case for us leaving a "best effort" .txt (or whatever) file in the profile - it is extra clutter, but if it's only for people who have used the feature it sounds like a reasonable tradeoff.
(In reply to Marco Bonardo [::mak] from comment #18)
> (In reply to Stephan Sokolow from comment #17)
> > > I can't trust Mozilla with my data.)
> 
> FWIW, you can't trust anything regarding dataloss, that's why backup systems
> exist. Your hard drive could break tomorrow, or your OS may corrupt
> yesterday. You can't even trust your NAS unless it's enterprise grade (and
> still). I don't think this is a problem with Mozilla as it is not with any
> other company in the world.

(In reply to Marco Bonardo [::mak] from comment #20)
> Thus, considered we'll give 2 full cycles and anyone using ESR should have
> some kind of backups (because it's a big part of the "stability" an ESR
> entity needs), this change is unlikely to hurt you, in practice.

I fully agree everyone should have backups. However, there’s a difference between a hard drive crash, which you probably notice immediately, and a software change, which is much more subtle. Do you really expect users to check the release notes every time any piece of software is updated, which happens automatically most of the time? And even if I try to, it’s hard to do: the Firefox "What’s new" page (e. g. https://www.mozilla.org/de/firefox/59.0.1/whatsnew/?oldversion=58.0.2) does not mention any changes and has no link to release notes, it is just an advertisement for Firefox Sync.

There is a reason I use local bookmarks and not some cloud service which could disappear anytime: the expectation my data will be there as long as I keep my system safe. This includes:
- backups which I can use in case my hardware breaks or I do something stupid, both are quite obvious and I can recover immediately
- software updates! But while using old software, especially browsers and operating systems, is usually considered dangerous, actually updating would lead to guaranteed dataloss if the description field is removed without making a copy somewhere.

Even with a backup, there is only a limited amount I can go back in time, so with cyclic backups the data could be overwritten before I notice it was removed from Firefox. I think a few years ago the description field was shown when the star in the address bar was clicked. Today it’s not shown there. I thought this change happened because I had a (now incompatible) extension which made the description field available there, but possibly it was a change in Firefox itself. However, the description field is still accessible using the bookmark manager. Therefore I’m desensitized to such UI changes, believing the data will still be stored somewhere.

The only reason this change is "unlikely to hurt me in practice" is because of the unlikely fact I stumbled upon this and related bug reports, therefore I’m in the lucky position to notice this change in advance.

(In reply to Mark Hammond [:markh] from comment #22)
> (In reply to Stephan Sokolow from comment #21)
> > Also, my objection isn't with the removal of niche features. My objection is
> > in making it too easy for a distracted, overworked person, like I sometimes
> > am, to miss that data has been deleted without my consent.
> 
> That does make a good case for us leaving a "best effort" .txt (or whatever)
> file in the profile - it is extra clutter, but if it's only for people who
> have used the feature it sounds like a reasonable tradeoff.

Long story short: While I’m not happy with the removal, I think a regular bookmarks.html (same format as when using the export function in the bookmarks manager) would be easy to handle both by Mozilla (the code is mostly already included) and by users (if they already have some kind of parser for it, they can use that; otherwise they can access the file with any browser). As for clutter: I don’t know what exactly the "refresh" function in Firefox does (does it completely wipe the profile? I’m too scared to try it), but maybe this could also remove the file.
(In reply to Mark Hammond [:markh] from comment #22)
> That does make a good case for us leaving a "best effort" .txt (or whatever)
> file in the profile - it is extra clutter, but if it's only for people who
> have used the feature it sounds like a reasonable tradeoff.

There's no way to detect who used the feature and who didn't, since we don't have anything tracking whether the original description from the page has been edited.
I still think our plan is solid enough, for the previously expressed reasons.
(In reply to Martin F. from comment #23)
> Do you really expect users to
> check the release notes every time any piece of software is updated, which
> happens automatically most of the time?

I expect ESR users to do that more likely than any other channel, yes, because it's part of what ESR is, those users don't want surprises and they'll check what changed in advance.

> Even with a backup, there is only a limited amount I can go back in time, so
> with cyclic backups the data could be overwritten before I notice it was
> removed from Firefox.

That's why we plan to wait 2 releases, that is 3 months. A user that makes use of description will likely notice the change in a 3 months timeframe. And after those 3 months, we still have more than 15 days of bookmark backups, that move us closer to 3 and a half months.

> I think a few years ago the description field was
> shown when the star in the address bar was clicked.

I don't think so, as far as i remember. It was likely an add-on.

> Long story short: While I’m not happy with the removal, I think a regular
> bookmarks.html (same format as when using the export function in the
> bookmarks manager) would be easy to handle both by Mozilla (the code is
> mostly already included) and by users

What about privacy? We'd store a file in the profile with all of your bookmarks, for the majority of users it would stay there forever, and you may wan to get  rid of some of those bookmarks, but you don't know that file exists. We should not sacrifice privacy for any reason.
(In reply to Marco Bonardo [::mak] from comment #25)
> I expect ESR users to do that more likely than any other channel, yes,
> because it's part of what ESR is, those users don't want surprises and
> they'll check what changed in advance.

Again, I'm only running ESR in parallel with my usual Developer Edition profile because some of my extensions haven't been migrated over yet.

My concerns are for users on ANY channel.

> That's why we plan to wait 2 releases, that is 3 months. A user that makes
> use of description will likely notice the change in a 3 months timeframe.
> And after those 3 months, we still have more than 15 days of bookmark
> backups, that move us closer to 3 and a half months.

I assume there's some kind of UX policy that rules out presenting users with a doorhanger notification that warns of the coming change and offers a highly visible button to save a bookmarks backup?

(Perhaps appearing on each Firefox start until one of the choices is clicked, rather than it being dismissed by clicking outside it.)

> What about privacy? We'd store a file in the profile with all of your
> bookmarks, for the majority of users it would stay there forever, and you
> may wan to get  rid of some of those bookmarks, but you don't know that file
> exists. We should not sacrifice privacy for any reason.

In the interest of fairness, that's not strictly accurate. It would be entirely possible to store only the description field and some kind of foreign key reference in the separate file, and only for fields which actually have a description.

Still not ideal for privacy, but not "all of your bookmarks".
(In reply to Stephan Sokolow from comment #26)
> I assume there's some kind of UX policy that rules out presenting users with
> a doorhanger notification that warns of the coming change and offers a
> highly visible button to save a bookmarks backup?

The problem is that 99% of the users don't care about this change, do you think we should annoy everyone with requests that may not matter to them?
If we'd have a way to detect usage of the feature we could do that.
Though, maybe we could add something in 62 to detect usage (an onchange listener on the description field), so that in 64 we'd have a way to detect usage and act accordingly (maybe store a file on the desktop only for users who touched a description field)
It would still be an interesting amount of work, but it may not be terrible.
Mark, what do you think?

> In the interest of fairness, that's not strictly accurate. It would be
> entirely possible to store only the description field and some kind of
> foreign key reference in the separate file, and only for fields which
> actually have a description.

it would be pointless for the average user not being able to easily connect a description to a url. And it's still possible to connect a default description to a page. and the description may contain codes/passwords, whatever else. This is not a safe option.
Flags: needinfo?(standard8)
(In reply to Stephan Sokolow from comment #26)
> I assume there's some kind of UX policy that rules out presenting users with
> a doorhanger notification that warns of the coming change and offers a
> highly visible button to save a bookmarks backup?

What you're proposing here is a jarring user experience for the majority of users, who will be confused because they don't know what bookmark descriptions are and certainly don't know how to use them.

Their only effective use case has been to collect free-form notes that belong with the bookmark, but in a way that is hard to look up, review, change and search through. In other words; to make the description field effectively useful to a broader audience would require significant engineering effort and more significant product, user and UX research.
There are more effective ways we can improve the current state of bookmarks management and we'll be spending our limited resources there instead.

(In reply to Marco Bonardo [::mak] from comment #27)
> Though, maybe we could add something in 62 to detect usage (an onchange
> listener on the description field), so that in 64 we'd have a way to detect
> usage and act accordingly (maybe store a file on the desktop only for users
> who touched a description field)
> It would still be an interesting amount of work, but it may not be terrible.
> Mark, what do you think?

Although this does sound very reasonable - even though it won't work users who don't edit a description within 12 weeks, I'd prefer not to spend more time on this.
Is there a something we can do with regard to backups? If not, than that's unfortunate but ultimately a result of the more than a decade old design of not also implementing a 'user_edited' flag or using timestamp annotations or even transaction-driven database record versioning.
(In reply to Mike de Boer [:mikedeboer] from comment #28)
> Is there a something we can do with regard to backups? If not, than that's
> unfortunate but ultimately a result of the more than a decade old design of
> not also implementing a 'user_edited' flag or using timestamp annotations or
> even transaction-driven database record versioning.

The only thing we could do is further increase the number of days we keep backups for, from the current 15 unique backups to something more. The price there would be a few additional MBs in the profile folder for all the users.
Marco, Mike and myself have had a conversation today and we've decided that although this data is causing databases to be larger than necessary, we're not going to remove the description data until sometime after we've finished migrating/removing the rest of the bookmark annotations APIs.

Once the bookmark annotations APIs have been replaced/removed (bug 1460577), we'll re-assess exactly when is appropriate to clean up the description and any other remaining annotations (bug 1467131).

At the moment, we're unlikely to complete the API work within the next couple of releases, so there will be a longer time than the previously mentioned two releases.

Please note, although the UI has been removed in 62, the description data can still be exported via JSON or HTML via the bookmark backup/export mechanisms.
Flags: needinfo?(standard8)
Priority: P2 → P3
I see the benefit of removing the description field.
Can you add a user editable notes field?
I feel that having a place to add notes to each bookmark would be a great feature many people will like.
I erased the description and put in notes in all my bookmarks & I am sad to see that I will be losing easy access to those notes.
It would be even better if you where able to incorporate a way for people to check a box to move the description to a notes field manually. If many people put notes in the description field this transition step would make a lot of people happy.
(In reply to Jeremy from comment #31)
> Can you add a user editable notes field?

No, but WebExtensions can do even better, like rich notes, freeform notes, collections and so on.
We just feel like this feature is not something that benefits most of our users, and it's not getting the attention it would deserve (We don't have resources planned to work on it any time soon). As such, it's not being considered anymore part of the core features for bookmarks.
I think that "Notes" would be the same "Descriptions", just with different name :)
(In reply to Jerry Krinock from comment #33)
> I think that "Notes" would be the same "Descriptions", just with different
> name :)

The distinction is that "description" has historically been auto-populated from site metadata without the user having to do anything.
Hi!
Please add an option in (about:config) to stop Firefox from auto-filling the Description Field. In other words an option to disable that field. Every time I add a bookmark I have to clean it. I think it affects the synchronization of bookmarks between multiple devices. That field is useless to me.
Regards
That wouldn't help, we must remove annotations for architecture and performance problems that can't be solved otherwise. WebExtensions can easily replace the functionality.
Depends on: 1467996
I'm on the Pocket team, and I urge you *not* to modify moz_places. 

We're currently developing a privacy preserving personalization extension that uses the description field. We use the data get a better understanding of what topics someone is interested in. Removing this field would negatively impact us greatly. If this field is removed from moz_places, we would have replicate this data in another place, defeating whatever benefit would be gained by removing this field in first place. More importantly, we wouldn't be able to activate our system at launch, but would instead have to essentially run it dark until enough data was collected. This would just slow us down, with no real benefit to anyone, as we would be duplicating this currently existing functionality.

The fact that description is autopopulated from the website is what makes it valuable to us. Its presence indicates the most interesting sites from a content perspective, and it's our only way to gain insight into the contents of those pages absent scraping the page at fetch time. While it's true that someone could backfill this data, as a practical manner we can't have the browser background fetch 25,000 URLs, three-fourths of which aren't actually interesting. (My investigation shows that only about 25% of URLs in moz_places have the description field populated.)

If you need more information about what we're doing, please reach out. I'm on moz slack and email.

Thanks.
Flags: needinfo?(mak77)
Hi Jonathan,

(In reply to jonathan koren from comment #37)
> I'm on the Pocket team, and I urge you *not* to modify moz_places. 

We are not removing the description field in moz_places, this is the newer one that activity stream uses & introduced a while ago.

The one that is planned to be removed is the description annotation that lives in the moz_items_anno table and is an annotation on the bookmarks in moz_bookmarks.
Flags: needinfo?(mak77)
needinfo just for ACK.
Flags: needinfo?(jkoren)
(In reply to Marco Bonardo [::mak] from comment #39)
> needinfo just for ACK.

Thanks for the clarification. We don't use moz_bookmarks. If there's any planned changes to moz_places, please reach out.

Thanks.
Flags: needinfo?(jkoren)
The description UI and most of the back-end handling of the description annotation have been removed in the bugs that this depends on. Therefore calling this fixed.

The description annotations still remain in the database and can still be exported (via json backup or html export), and will be removed at some stage in the future by bug 1467131).

Hence closing this out as fixed.
Assignee: nobody → standard8
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
@olejorgenb, I think that such a Web Extension would indeed not integrate with the *Show All Bookmarks*, *Library* window.  Instead, it would replicate it, and then add more features.  Users of such an extension would never open Firefox' built-in bookmark UI.
I am thankful that the bookmark description data wasn't totally deleted when you removed the entry box.
I was able to export it all to html.

I fear if this proceeds as planned and the data is deleted then many thousands of people are going to lose their notes forever. 

I regret that i have to search the exported html to find my notes now instead of being able to right click the bookmark like i have done for years and years. Removing this functionality is not a good thing for firefox or its users IMHO.
This removal was absolutely necessary for the future of Firefox, it was not done just looking at telemetry numbers as someone thinks, but because it was a huge roadblock towards removal of main-thread IO (hanging UI), and we were sure to not have resources to develop a proper notes functionality as part of bookmarks.

Add-ons and experiments are already providing good and actually maintained alternatives. I'm sure now that we opened this opportunity more will come.
A few alternatives to keep notes:
https://testpilot.firefox.com/experiments/notes/
https://addons.mozilla.org/it/firefox/search/?q=notes
ehr, sorry I linked the italian version of amo, this link is better: https://addons.mozilla.org/firefox/search/?q=notes
To provide some numbers: I have exported my bookmarks to HTML (to save the contents of the description fields). It takes almost 16 MB and contains 8127 links. I can’t remember performance issues related to bookmarks (maybe ~15 years ago). The browser takes a short while to start, but I think it’s due to the 1277 tabs. Hardware is a 7 year old i5-2500K (no overclocking).

Of course software gets faster if you remove features, but what for? Removing access to the stored data makes it seem unreliable. Even worse than a broken hard drive, because you can restore a backup, but one should not use outdated browsers for security reasons.

Extensions are not reliable as they can break on any browser update and often times that’s it — no maintenance by the extension developer, no usable replacement. I thought by using built-in functions my data would be safe.

What’s next? Removing the bookmarks entirely because one could also use some online service? It would free developer resources and make the browser even faster. Hopefully transferring thousands of bookmarks doesn’t take much time and the service won’t shut down.

As a developer (not related to Mozilla) I don’t see why providing another text field besides title and URL would need so many developer resources. Copy, paste, rename, done?
As olejorgenb in Comment 42 I disagree with this deletion of the description field. I use it often and it is as important for me than the Bookmarks themself.

@Marco in Comment 46: Among many for me useless Notes Add-Ons, I found the Add-on "Webpage SideNotes" (https://github.com/nabendu82/WebpageSideNotes) which could partly replace the description field, but missing sync, as I see it.
The Test Pilot Notes is different thing than the description field, by the way.
To replace the description field, an Add-on should provide:
- Note per Website
- Sync through FF-Sync
- (would be great) Export of description field to the Add-On
I don't find any Add-On doing that yet, but my hope is high, that till the final deletion of the description field in FF-ESR version, there would be an appropriate replacement.
(In reply to Martin F. from comment #48)
> Of course software gets faster if you remove features, but what for?

I think you misunderstand the nature of the problem, I can assure you we do understand it, after 10 years of maintenance of this specific code.
This is not about removing the description field, it's about removing the whole architecture behind it, that was misdesigned and exists just to cover this feature that can be easily (and better) be reimplemented in an add-on, or in Firefox itself, but with a better architecture.
And yes, this architectural choice can cause multi-second (or even multi minutes) hangs in the UI, plus slowing down EVERY bookmark operation, and when you have users with 80 THOUSANDS bookmarks, you can probably understand what it means.

> I thought by using built-in functions my data would be safe.

Your data is safe, you can still export it.

(In reply to franc from comment #49)
> @Marco in Comment 46: Among many for me useless Notes Add-Ons, I found the
> Add-on "Webpage SideNotes" (https://github.com/nabendu82/WebpageSideNotes)
> which could partly replace the description field, but missing sync, as I see
> it.

There is also a new add-on https://addons.mozilla.org/en-US/firefox/addon/bookmark-notes/ that also supports Sync, iiuc. More will probably come.
In reply to @Marco Bonardo in Comment #50:
Thanks, it is a start and now I am quite sure, that soon enough there will be appropriate replacement for it.
I will use the preFF62 versions (e.g. ESR) till it is good.
Thanks.
(In reply to Marco Bonardo [::mak] from comment #50)

> Your data is safe, you can still export it.

How can the descriptions in the bookmarks toolbar be exported? They are gone, very surprisingly for me. Also, I can't find a way of accessing the information at all now. I do understand that the architecture had to be changed, but do you seriously expect users (even if there a only a few who used this feature) to search the web for hours to get their data back?
(In reply to Lars Raeder from comment #52)
> How can the descriptions in the bookmarks toolbar be exported?

It was detailed in the "changed" section of release notes: https://www.mozilla.org/firefox/62.0/releasenotes/#changed - there are two types of export options available. Direct links:

https://support.mozilla.org/kb/export-firefox-bookmarks-to-backup-or-transfer
https://support.mozilla.org/kb/restore-bookmarks-from-backup-or-move-them#w_backup-and-restore
(In reply to Mark Banner (:standard8) from comment #53)
> (In reply to Lars Raeder from comment #52)
> > How can the descriptions in the bookmarks toolbar be exported?
> 
> It was detailed in the "changed" section of release notes:
> https://www.mozilla.org/firefox/62.0/releasenotes/#changed - there are two
> types of export options available. Direct links:
> 
> https://support.mozilla.org/kb/export-firefox-bookmarks-to-backup-or-transfer
> https://support.mozilla.org/kb/restore-bookmarks-from-backup-or-move-
> them#w_backup-and-restore

I've found those links, of course, and tried to export my bookmarks toolbar. I got my general bookmarks exported, but the content of the bookmarks toolbar is ignored by both the bookmarks library and its export function.
I think that when an address is dragged to the bookmarks toolbar, it is not a proper bookmark at all.
My descriptions in the toolbar are still inaccessible or even lost.
The toolbar is normal bookmarks. The bookmarks on the toolbar will likely be in a different section of the file to the rest of the bookmarks, as it is effectively a different folder. If you're still having issues, please try this:

* Go to Help -> Troubleshooting Information
* Scroll down the page to find the "Places Database" section (it is near the bottom).
* Click the "Verify Integrity" button, this may take a few seconds to run. 
* Restart Firefox.

If a fresh export still doesn't show them, please file a new bug.
(In reply to Mark Banner (:standard8) from comment #55)
> The toolbar is normal bookmarks. The bookmarks on the toolbar will likely be
> in a different section of the file to the rest of the bookmarks, as it is
> effectively a different folder.

I was mistaken. The bookmarks in the bookmarks toolbar are not generally treated differently. But bookmarks without titles are. In my bookmarks toolbar, I have deleted all titles, because the icons are enough to identify the bookmarks and I needed space for many bookmarks.
All bookmarks are included in the JSON export, but I can't import that into the new notes addon.
The HTML export, on the other hand, ignores all bookmarks that don't have a title!
I am going to copy the descriptions manually from the JSON export.
(In reply to Lars Raeder from comment #56)
> The HTML export, on the other hand, ignores all bookmarks that don't have a
> title!

They don't appear at all? Strange, they should really appear with just url but without a title. If so, it sounds like a bug that should be filed, the html export must contain all the bookmarks, regardless of their title.
(In reply to Marco Bonardo [::mak] from comment #57)
> They don't appear at all? Strange, they should really appear with just url
> but without a title.

No, they are not rendered in Firefox, because the A element has no content. The URL is not used as a fallback.
They are, however, in the export. I should have tried to import the file although it appeared almost empty in the browser.
The import has now succeeded.
Sorry for my false assumptions.
You need to log in before you can comment on or make changes to this bug.