Hacker News Reader

Comment by nathcd | Hacker News Reader

> Removed the description field for bookmarks. Users who have stored descriptions using the field may wish to export these descriptions as html or json files, as they will be removed in a future release.

Does anyone know if there's an explanation for this somewhere? Between removing live bookmarks (a simple feed reader) and this, it seems like they're paring down user-facing features.

I don't think these are the features being referred to when people complain about "browser bloat", Mozilla. I expect Chrome to push me to use remote services, but I don't want that from Mozilla. I know it's a trope to complain about Firefox becoming a Chrome clone, but it feels truer every release.

View on HN

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

Here is a sub-bug that discusses issues with synchronous APIs.

https://bugzilla.mozilla.org/show_bug.cgi?id=1467996

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.

I've read somewhere that Firefox telemetry showed that hardly anyone used the bookmark descriptions.

In that case, understandable they chose to remove them.

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 (and I don't see any mention of how widely used it is, from telemetry or otherwise).

> 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.

Can you explain how exactly the description field for bookmarks was a relevant feature for a significant share of power users?

> 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.

> 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.

> It basically means: worth tailoring to, given precious UI space and limited developer resources.

How much precious developer time is required maintain a user-facing text field on an entity with only a handful of other fields? Certainly not enough to properly justify a feature regression with user-data loss.

> Do you think 50% of power users used this feature? How about 10%? 5%? 1%?

IMHO, you're thinking about power users incorrectly. Power users aren't as cookie-cutter as regular users, so you shouldn't expect them all to use an identical set of features. For instance, say you have 100 power user features. It wouldn't surprise me if none of those features passed 1% usage, but 90% of power users use at least one of them. Get rid of them all due to "low usage according to telemetry" and you've just created regressions for 90% of your power users.

How is that supposed to be sustainable?

Are you saying it's unsustainable to maintain an application suitable for power users?

It'll definitely take more effort than maintaining a restrictive, dumbed-down app; but it's certainly not impossible and I think the benefit is worth it.

I'm saying that it's unsustainable to maintain a hundreds of features for the benefit of different slices of 1% use.

> I'm saying that it's unsustainable to maintain a hundreds of features for the benefit of different slices of 1% use.

There isn't one kind of "power user," especially for something like a web browser. If you want to support power users, you probably will need to support hundreds of specialized features, many of which won't be used my everyone. If you don't do that, then I think it's very unlikely that you support power users [1]. Apps with feature-sets like this exist, so I think it's wrong to make a blanket statement that it's unsustainable.

I'm not saying it's always sustainable either: if you're a two man team at a small company, you probably can't manage to support much more than the core user group. However, Mozilla's big and I think they need to offer something unique compared to Chrome and Safari.

[1] As opposed to developers or extension-writers. My definition of power user excludes people who extensively modify the software themselves.

> Mozilla's big and I think they need to offer something unique compared to Chrome and Safari

Mozilla is tiny compared to the size of the Chrome team.

> How much precious developer time is required maintain a user-facing text field on an entity with only a handful of other fields?

The description removal blocked improvements to bookmarking that will actually affect a significant share of users:

https://bugzilla.mozilla.org/showdependencytree.cgi?maxdepth...

> Exactly. There is no point to compete with Google for "browser for Uncle Joe"

Yes there is.

For Firefox to be useful, websites need to work in it. That means web developers need to test in it. And that means that the demographics that they target need to have enough Firefox users to justify testing it. That means there needs to be a sizable portion of Firefox users in every major demographic.

Otherwise it'll be right back to where we were with IE6, except unlike back then, Google Chrome isn't abandonware that just happens to ship with Windows.

> 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?

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.

>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.

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).

It's not a mess, it's just a case of "not used by me, so remove it". Instead of improving the feature they let it rot away, like so many others, and then ignore that people still used it. Really sad.

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.

"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.

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.

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.)

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.

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.]

> 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.

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.

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.

That's really bad. Deleting user data is one of the most loud ways to declare that "we're bad at software development!" I guess I should consider trying Ungoogled Chromium or maybe Pale Moon. I worry the former will be a menace to build because I don't have lots of RAM and CPU. Edit: I don't use the feature but still...

They are not deleting already existing data, they removed the user-facing features and the collection of new data.

No, they said they intend to remove the data entirely in the future and that you should back it up yourself if you want to keep it.

They will remove the data in a future release. I.e. if you don't read the entire release notes for all the software you use, there's a chance that your data will be removed inadvertently, if you happen to use the feature.

Firefox has problems with data loss. I have lost my open tabs on multiple occasions in scenarios where it's totally possible to recover the entire data (just using atomic writes). Recently, I mistakenly opened FF 52 instead of FF 61 (Debian has 52), and all my bookmarks were deleted. Luckily I had a backup of the user profile so that I survived that. I like FF, but I cannot trust it with my data one bit. And now it's no more only mistakes but it's intentional, user-hostile design decisions.

They're also paring down user-facing settings. It makes no sense to, e.g., send people to about:config for disabling web service workers.

They've been actively hostile to friendly user settings for years. They constantly reduce what's exposed through the settings page, forcing users into about:config.

Forcing users to default settings actually, they would happily remove about:config if they could.

And I feel like that's the first step towards using their telemetry to decide that feature is unused and can be deprecated (because only the people who really care about something will go through with Googling to find whatever hidden setting needs to be changed to fix their browser).

And yes, I'm still salty about no longer being able to set showOneOffButtons to false :)

(I've stopped using FireFox since the new extensions model doesn't allow this misfeature to be fixed with extensions anymore)

If they remove tags supports later on, that will be the last useful feature I'm hanging on.

The bookmarking system is being downgraded to the point of uselessness, at this point I'd switch back to Chrome.

While I do tag my bookmarks I barely use that feature. Some tag cloud for my bookmkarks would be awesome though.

https://github.com/nextcloud/bookmarks

As long as Chrome is maintained by Google I'd never go back. Heck, I'd even start using IE before I'd turn to Chrome ...

Bromite [1] is promising, especially if someone begin to build it for desktop platforms.

[1] https://www.bromite.org/

What does it have over Falkon (previously, https://qupzilla.com, which supported a whole pile of platforms), or for that matter any of the chromium based browsers, which all seem to be "de-googled"?

Is the Falcon actively developed recently? By the way, Bromite is available in F-Droid, is there any plans about Falcon for Android?

> any of the chromium based browsers, which all seem to be "de-googled"

Are there many of them?

The Falkon fork was just made a few months ago although the latest release is from May, so that is fairly old in browser update land, but being just a few months old is pretty decent WRT browsers that aren't FF/Chrome. OTOH, QupZilla was one of those just a few releases a year projects anyway. So a few months between releases wasn't unusual.

https://github.com/QupZilla/qupzilla/blob/master/CHANGELOG

Looking at the Falkon repo (https://phabricator.kde.org/source/falkon/) there were commits made just a couple days ago. So, it looks like its being actively developed. There is also a fair amount of mailing list chatter.

Yes, there are a ton of chromium forked browsers: (random link with a long list of alternative browsers, almost all of them have some tie to ff or chrome) http://www.canadiancontent.net/tech/downloads/Internet-Brows...

As far as android versions, I don't know what the plans are, you could ask them. AFAIK, Qupzilla didn't support any mobile platforms, although QT does iOS & Android. I'm sure they would take a pull request <wink>

If anyone relies on bookmark descriptions, look into my Static Marks tool [0]. It goes beyond descriptions: every bookmark may include multiple notes and other bookmarks. There is no import feature yet, though (but the latest move by Mozilla makes me want to implement this soon).

[0] https://staticmarks.com/

Came here with exact same quote in clipboard, ready to grumble. Not that this is in any way an essential feature to me, but the trend is one way, and one way only: The paring down of choice and useful public features. Firefox of ten years ago was UI-wise a far superior product to the sorry quasi-Chrome of today. I no longer use it with any kind of joy or excitement because it's somehow best. I use it because everything else is even worse. No, please, spare me the recommendation: I do not use Google products. Period.

[Edit: typos]

> the trend is one way, and one way only: The paring down of choise and usefuls public features.

...and creating APIs so that extensions can handle the functionality instead.

Creating XUL, really?

You cannot create an restricted API for everything, the very point of extensions, plugins, addons is community is always bigger than your developers team, and much, much more diverse. The 'long tail' effect is what extensions community is about, not '90 per cent of users'. 90 per cent of users might need just a couple of the same extensions, the other 10 per cent of users need a thousand of different extensions.

Well, we had XUL (which was awesome), now it's gone

I need to say at least one relatively good thing about Firefox - it has extensions on Android. I don't know for how long but still.

The community still has XUL thanks to Pale Moon.

Not really. I stuck to Pale Moon for a while, but it gets untenable: Stuck with dead extensions, or ancient versions of live ones. Left behind with no support for essentials like grid-view display, which the Pale Moon maintainer seems to consider a kind of personal affront. And knowing with close to absolute certainty that you are setting yourself up with a variety of gaping, unpatched security holes.

I haven't found it to be untenable. Then again, it seems that you're worried about maintaining the bleeding edge, and I'm, well, the exact opposite of that. My mantra in terms of technology has been "If it ain't broke, stop trying to fix it" for the last, oh, 4 years or more.

XUL the platform should still live on, unless Mozilla pulled the devkit

Hmm, now to check up on xulrunner....

You can't create a UI that makes everyone happy either.

For example, extensions that use the tabs WebExtension API are significantly more varied than the removed Panorama feature.

> You can't create a UI that makes everyone happy either.

That's why every software project having a user community has theme support.

Browser themes change appearance, not functionality.

> ...and creating APIs so that extensions can handle the functionality instead.

If they were actually doing that, I'd be first in line for their defense, but they aren't. Additionally, they keep shoving in features that should be extensions.

They're definitely actively working on giving WebExtensions as much power as they can.

There's a number of new APIs in the pipeline[1] with additional experimental prototypes in various stages of progress[2].

1. https://wiki.mozilla.org/Add-ons/Projects#New_WebExtension_A...

2. https://github.com/mozilla/libdweb

Reply on news.ycombinator.com