5 ms·

The Firefox bookmarking implementation is unnecessarily complicated and I'm guessing very few features are actually used. It's a maintenance burden, I'm not sur

by jaas 8y ago

The Firefox bookmarking implementation is unnecessarily complicated and I'm guessing very few features are actually used. It's a maintenance burden, I'm not surprised they want to slim it down. To give you an example of a maintenance burden in the bookmarking system, the bookmarking system uses a bunch of synchronous APIs. Mozilla is trying to cut down or eliminate use of those APIs, to reduce UI hangs among other reasons, and in order to do that a bunch of bookmarking code needs to be rewritten. You may have decided that you don't care about this particular kind of bloat, but all unnecessary maintenance burdens distract developers from doing work I'm sure you do care about. Here is the bug for removing descriptions: https://bugzilla.mozilla.org/show_bug.cgi?id=1402890 https://bugzilla.mozilla.org/show_bug.cgi?id=1402890 Here is a sub-bug that discusses issues with synchronous APIs. https://bugzilla.mozilla.org/show_bug.cgi?id=1467996 https://bugzilla.mozilla.org/show_bug.cgi?id=1467996

nathcd 8y ago
Thanks, I appreciate the explanation and links, and I can definitely appreciate the fact that it's a maintenance burden that's taking away from other important work. But it's still hard to swallow -- given the really, truly amazing engineering work that's been coming out of Mozilla (Rust and Servo are what I'm thinking of), and the gargantuan effort going into those -- that the APIs involved in the bookmarking system couldn't be improved. Looked at from another angle, if Mozilla can afford to put some resources into keeping Thunderbird alive, surely it can afford some resources to improve bookmarking code to avoid axing some fairly basic features.
- nikbackm 8y ago
  I've read somewhere that Firefox telemetry showed that hardly anyone used the bookmark descriptions. In that case, understandable they chose to remove them.
  - nathcd 8y ago
    That's how I expect Google to make decisions, not Mozilla. I would like to say that I trust Mozilla to appropriately weigh pros and cons and make unpopular decisions when necessary, but it seems like the entire deliberation process was a few individuals in one of the bugzilla threads that jaas linked above: https://bugzilla.mozilla.org/show_bug.cgi?id=1402890 https://bugzilla.mozilla.org/show_bug.cgi?id=1402890 (and I don't see any mention of how widely used it is, from telemetry or otherwise).
    - snaky 8y ago
      > That's how I expect Google to make decisions, not Mozilla Exactly. There is no point to compete with Google for "browser for Uncle Joe", Google won that battle. The power user browser niche is what Firefox could take instead. But no, let's chase after the leader by his rules, look at how good is Blackberry doing.
      - dao- 8y ago
        Can you explain how exactly the description field for bookmarks was a relevant feature for a significant share of power users?
        snaky 8y ago
        > a significant share I don't know what is 'a significant share' when we are talking about power users. Not to say a significant share of power users disabled telemetry completely so we can't say anything about their share using this feature.
        dao- 8y ago
        > I don't know what is 'a significant share' when we are talking about power users. It basically means: worth tailoring to, given precious UI space and limited developer resources. Of course there's no fixed share that "worth tailoring to" can be translated to universally. It's a judgement call. Do you think 50% of power users used this feature? How about 10%? 5%? 1%? I doubt this one even met the 1% bar. Would you agree that it's reasonable if not necessary to draw a line somewhere? > Not to say a significant share of power users disabled telemetry completely so we can't say anything about their share using this feature. What we can at the very least do is reason about features and why and how people would use them, and we can collect anecdotal evidence. I consider myself a power user. I have never used this feature in more than a decade, and have a hard time imagining what important thing people would do with it.
  - 394549 8y ago
    > I've read somewhere that Firefox telemetry showed that hardly anyone used the bookmark descriptions. > In that case, understandable they chose to remove them. It's not understandable. That logic leads to dumbed-down, point-and-grunt products because the "telemetry" shows most users aren't power users. Anyway, how much effort does it really take to maintain a text field on a bookmark entity?
    - Karunamon 8y ago
      I do kind of wonder how many power users are opting out of telemetry for privacy reasons... Unrelated, but dear god that bug tracker was infuriating to read. As in I had a strong desire to reach through the screen and shake a few by the shoulders asking "What the FUCK is wrong with you people?!" Concern over data loss nearly dismissed out of hand, a smug "you should have backups" response to intentionally caused data loss, and all this over what amounts to a property field on a bookmark... It's like I was reading the GNOME tracker! All this over "maintenance burden". Is the "maintenace burden" of a non-searchable field that's only visible in a single context really that high? Really? It seems like this is quickly becoming the go-to excuse to eliminate power user features in a way that those users will not see until its too late. "Developer" is already a subset of "power user", and "developer who reads the bug tracker for unwanted future surprises" is an even smaller subset.
    - unethical_ban 8y ago
      >Anyway, how much effort does it really take to maintain a text field on a bookmark entity? My thought too! Legacy extension APIs are one thing. An extra DB column / key:value pair is nothing.
      - StillBored 8y ago
        If you think about, how this simplifies anything, you will start to understand the mess that is the FF codebase (not that chrome is noticeably better, particularly if you try and build it anywhere outside of ubuntu/x86_64).
        8y ago
  - Endy 8y ago
    No, it's not understandable at all. It might be understandable to have an option to display descriptions or not, but not remove altogether. Frankly, Firefox was, for a long time, the only major privacy-respecting browser. Heck, Tor Browser is still built on FF. By only caring about "telemetry" (i.e. random information sharing without the user having the ability to audit data prior to any transmission), and not caring about providing the best and most robust privacy-focused feature set, Firefox is actively cutting off a major part of its old user base, telling them that Firefox is not the browser which they originally installed anymore. Now, if the description data was being stored in plaintext and that data was being leaked, by all means, say that outright so we know that the devs screwed up again, remove the dangerous function, leave the data to the user (that part really kills me, btw - Mozilla is trying to delete information from my PC without my explicit consent), and put it in roadmap to reimplement in a more privacy-driven way. That means, do not reveal information to any server - and I mean any - if I have a server on my network, don't let my user settings leak there. Do not rely on an external, insecure, website to do what your browser should. And all websites are insecure - I am not the only person to deal with the server from bare metal up, that means there are twice as many security risks as there are abstractions from me plugging my computer directly into that computer. If you want "telemetry", give me a button in my options menu to compile the report, in human-readable plaintext, and then, only after I approve it, ask me to send that text file through sFTP to a server I can log into with a one-time username and password, with 1024bit encryption minimum. I would be okay with sending a monthly report, after having confirmed that it does in fact contain no information whatsoever that could be used to deanonymize me. Anything more than once a month per user is extreme, and means that the devs are being overloaded with data so they don't have time to manually code.
snaky 8y ago
"The Firefox X implementation is unnecessarily complicated and I'm guessing very few features are actually used" is exactly the same attitude from Firefox developers for any X since long ago.
ploxiln 8y ago
It is true that some features can be maintenance burdens for software projects. But bookmark descriptions? Really? That's ridiculous. WebGL, or WebVR, or Pocket, maybe, those could be a burden. But BOOKMARK DESCRIPTIONS? Maybe the existing bookmarking system is crap and you need to re-implement it. You can put descriptions in the new implementation, in a few minutes - it's just another optional text field/property. Unless the goal is just to remove all bookmarking whatsoever. And instead of being honest about that, you're passive-aggressively trying to get people to stop using them first, by crippling them in various ways for obviously bogus reasons.
snaky 8y ago
The relevant comment from Bugzilla thread > 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.)
- StillBored 8y ago
  Add to that rant the fact that for a while mozjs was the choice javascript engine for various projects that wanted a JS interpreter. Then one day they decided to literally break the API, every couple weeks, and its been going on for years. The language bindings aren't even the same now, and projects like gnome end up with these rather large patch sets every few months just to keep up.
  - bzbarsky 8y ago
    mozjs was a pretty old codebase with some design decisions that made sense in the mid-90s but don't make sense now baked into the API. The API needed to change to support things like a generational garbage collector. The set of needed API changes was quite large. Now the project had two options: Make the changes incrementally or all at once. The incremental option would mean API changes with each release until all the changes got made. The all at once option would mean you'd need to do a complete rewrite of all the relevant mozjs code and all the relevant Firefox code all landing in a single release. Since the time needed for that rewrite was measured in years, that would mean maintaining a branch and dealing with all the merge conflicts from other ongoing work. In practice, it would have meant a much slower pace of web-facing JS feature development at best; more likely a complete stop to that. Given those choices, the JS team went for the incremental route. Yes, it was painful for API consumers who needed to be running against current versions. But in this case, I expect it was the right tradeoff. I should also note that V8 breaks API compat regularly, though not to the extent that SpiderMonkey had to, due to being designed 15 years later with many benefits of hindsight. [Disclosure: I work on Firefox, closely with the JS team but not on the JS team.]
olejorgenb 8y ago
> Their usefulness is very limited, since we don't even search on them How about instead making them more useful and searching the field? > they are fetched from the page at the bookmarking time That I wouldn't mind removing, but not having a proper place to add some notes about the bookmark seems silly.
- snaky 8y ago
  Searching among descriptions would be "unnecessarily complicated and I'm guessing very barely are actually used" I suppose. Oh if only there were some engine inside, like SQLite or something.
FrozenVoid 8y ago
That was really dumb "to reduce UI hangs " Instead of removing the ability for fetching site descriptions(that no one care about, and probably the core reason of "UI hangs" ), they remove the entire field(that is actually a useful feature) that could be used to add site info by the user.

by jaas 8y ago

nathcd 8y ago

Thanks, I appreciate the explanation and links, and I can definitely appreciate the fact that it's a maintenance burden that's taking away from other important work. But it's still hard to swallow -- given the really, truly amazing engineering work that's been coming out of Mozilla (Rust and Servo are what I'm thinking of), and the gargantuan effort going into those -- that the APIs involved in the bookmarking system couldn't be improved. Looked at from another angle, if Mozilla can afford to put some resources into keeping Thunderbird alive, surely it can afford some resources to improve bookmarking code to avoid axing some fairly basic features.

nikbackm 8y ago
I've read somewhere that Firefox telemetry showed that hardly anyone used the bookmark descriptions. In that case, understandable they chose to remove them.
- nathcd 8y ago
  That's how I expect Google to make decisions, not Mozilla. I would like to say that I trust Mozilla to appropriately weigh pros and cons and make unpopular decisions when necessary, but it seems like the entire deliberation process was a few individuals in one of the bugzilla threads that jaas linked above: https://bugzilla.mozilla.org/show_bug.cgi?id=1402890 https://bugzilla.mozilla.org/show_bug.cgi?id=1402890 (and I don't see any mention of how widely used it is, from telemetry or otherwise).
  - snaky 8y ago
    > That's how I expect Google to make decisions, not Mozilla Exactly. There is no point to compete with Google for "browser for Uncle Joe", Google won that battle. The power user browser niche is what Firefox could take instead. But no, let's chase after the leader by his rules, look at how good is Blackberry doing.
    - dao- 8y ago
      Can you explain how exactly the description field for bookmarks was a relevant feature for a significant share of power users?
      - snaky 8y ago
        > a significant share I don't know what is 'a significant share' when we are talking about power users. Not to say a significant share of power users disabled telemetry completely so we can't say anything about their share using this feature.
        dao- 8y ago
        > I don't know what is 'a significant share' when we are talking about power users. It basically means: worth tailoring to, given precious UI space and limited developer resources. Of course there's no fixed share that "worth tailoring to" can be translated to universally. It's a judgement call. Do you think 50% of power users used this feature? How about 10%? 5%? 1%? I doubt this one even met the 1% bar. Would you agree that it's reasonable if not necessary to draw a line somewhere? > Not to say a significant share of power users disabled telemetry completely so we can't say anything about their share using this feature. What we can at the very least do is reason about features and why and how people would use them, and we can collect anecdotal evidence. I consider myself a power user. I have never used this feature in more than a decade, and have a hard time imagining what important thing people would do with it.
- 394549 8y ago
  > I've read somewhere that Firefox telemetry showed that hardly anyone used the bookmark descriptions. > In that case, understandable they chose to remove them. It's not understandable. That logic leads to dumbed-down, point-and-grunt products because the "telemetry" shows most users aren't power users. Anyway, how much effort does it really take to maintain a text field on a bookmark entity?
  - Karunamon 8y ago
    I do kind of wonder how many power users are opting out of telemetry for privacy reasons... Unrelated, but dear god that bug tracker was infuriating to read. As in I had a strong desire to reach through the screen and shake a few by the shoulders asking "What the FUCK is wrong with you people?!" Concern over data loss nearly dismissed out of hand, a smug "you should have backups" response to intentionally caused data loss, and all this over what amounts to a property field on a bookmark... It's like I was reading the GNOME tracker! All this over "maintenance burden". Is the "maintenace burden" of a non-searchable field that's only visible in a single context really that high? Really? It seems like this is quickly becoming the go-to excuse to eliminate power user features in a way that those users will not see until its too late. "Developer" is already a subset of "power user", and "developer who reads the bug tracker for unwanted future surprises" is an even smaller subset.
  - unethical_ban 8y ago
    >Anyway, how much effort does it really take to maintain a text field on a bookmark entity? My thought too! Legacy extension APIs are one thing. An extra DB column / key:value pair is nothing.
    - StillBored 8y ago
      If you think about, how this simplifies anything, you will start to understand the mess that is the FF codebase (not that chrome is noticeably better, particularly if you try and build it anywhere outside of ubuntu/x86_64).
      - 8y ago
- Endy 8y ago
  No, it's not understandable at all. It might be understandable to have an option to display descriptions or not, but not remove altogether. Frankly, Firefox was, for a long time, the only major privacy-respecting browser. Heck, Tor Browser is still built on FF. By only caring about "telemetry" (i.e. random information sharing without the user having the ability to audit data prior to any transmission), and not caring about providing the best and most robust privacy-focused feature set, Firefox is actively cutting off a major part of its old user base, telling them that Firefox is not the browser which they originally installed anymore. Now, if the description data was being stored in plaintext and that data was being leaked, by all means, say that outright so we know that the devs screwed up again, remove the dangerous function, leave the data to the user (that part really kills me, btw - Mozilla is trying to delete information from my PC without my explicit consent), and put it in roadmap to reimplement in a more privacy-driven way. That means, do not reveal information to any server - and I mean any - if I have a server on my network, don't let my user settings leak there. Do not rely on an external, insecure, website to do what your browser should. And all websites are insecure - I am not the only person to deal with the server from bare metal up, that means there are twice as many security risks as there are abstractions from me plugging my computer directly into that computer. If you want "telemetry", give me a button in my options menu to compile the report, in human-readable plaintext, and then, only after I approve it, ask me to send that text file through sFTP to a server I can log into with a one-time username and password, with 1024bit encryption minimum. I would be okay with sending a monthly report, after having confirmed that it does in fact contain no information whatsoever that could be used to deanonymize me. Anything more than once a month per user is extreme, and means that the devs are being overloaded with data so they don't have time to manually code.

snaky 8y ago

"The Firefox X implementation is unnecessarily complicated and I'm guessing very few features are actually used" is exactly the same attitude from Firefox developers for any X since long ago.

ploxiln 8y ago

It is true that some features can be maintenance burdens for software projects. But bookmark descriptions? Really? That's ridiculous. WebGL, or WebVR, or Pocket, maybe, those could be a burden. But BOOKMARK DESCRIPTIONS? Maybe the existing bookmarking system is crap and you need to re-implement it. You can put descriptions in the new implementation, in a few minutes - it's just another optional text field/property. Unless the goal is just to remove all bookmarking whatsoever. And instead of being honest about that, you're passive-aggressively trying to get people to stop using them first, by crippling them in various ways for obviously bogus reasons.

snaky 8y ago

The relevant comment from Bugzilla thread > 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.)

StillBored 8y ago
Add to that rant the fact that for a while mozjs was the choice javascript engine for various projects that wanted a JS interpreter. Then one day they decided to literally break the API, every couple weeks, and its been going on for years. The language bindings aren't even the same now, and projects like gnome end up with these rather large patch sets every few months just to keep up.
- bzbarsky 8y ago
  mozjs was a pretty old codebase with some design decisions that made sense in the mid-90s but don't make sense now baked into the API. The API needed to change to support things like a generational garbage collector. The set of needed API changes was quite large. Now the project had two options: Make the changes incrementally or all at once. The incremental option would mean API changes with each release until all the changes got made. The all at once option would mean you'd need to do a complete rewrite of all the relevant mozjs code and all the relevant Firefox code all landing in a single release. Since the time needed for that rewrite was measured in years, that would mean maintaining a branch and dealing with all the merge conflicts from other ongoing work. In practice, it would have meant a much slower pace of web-facing JS feature development at best; more likely a complete stop to that. Given those choices, the JS team went for the incremental route. Yes, it was painful for API consumers who needed to be running against current versions. But in this case, I expect it was the right tradeoff. I should also note that V8 breaks API compat regularly, though not to the extent that SpiderMonkey had to, due to being designed 15 years later with many benefits of hindsight. [Disclosure: I work on Firefox, closely with the JS team but not on the JS team.]

olejorgenb 8y ago

> Their usefulness is very limited, since we don't even search on them How about instead making them more useful and searching the field? > they are fetched from the page at the bookmarking time That I wouldn't mind removing, but not having a proper place to add some notes about the bookmark seems silly.

snaky 8y ago
Searching among descriptions would be "unnecessarily complicated and I'm guessing very barely are actually used" I suppose. Oh if only there were some engine inside, like SQLite or something.

FrozenVoid 8y ago

That was really dumb "to reduce UI hangs " Instead of removing the ability for fetching site descriptions(that no one care about, and probably the core reason of "UI hangs" ), they remove the entire field(that is actually a useful feature) that could be used to add site info by the user.