Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Removing features from bookmarks in Firefox

169 views
Skip to first unread message

l.m. orchard

unread,
Feb 7, 2011, 10:48:26 AM2/7/11
to
So, there are a few bugs in bugzilla to remove features from bookmarks
in Firefox. In order to maybe divert some of the discussion from the
bugs themselves to here, I'll start this thread as requested.

The bugs in question are these:

* bug 622051 - Remove support for microsummaries
* bug 622045 - Remove smart bookmarks support
* bug 622047 - Remove support for tagging bookmarks
* bug 624049 - Get rid of livemark support

I commented on most of them, but probably should have started by posting
here. I've also blogged about this:

http://decafbad.com/blog/2011/02/06/pay-phones-and-firefox-features

In a nutshell: I don't want to be a stop energy generator, but I think
some of these are important features. Okay, not microsummaries so much,
but maybe smart bookmarks and definitely tagging and livemarks. In fact,
dropping some of these will result in user data loss (eg. tags in
particular)

Again, not to make work for others, but: If we're dropping these from
core Firefox, it might help to have a transition plan for people who use
them. Could any or all of these be spun off into add-ons and possibly
adopted by motivated developers? That might be a better story than
simply getting rid of the features.

--
l.m.o...@pobox.com
http://decafbad.com
{web,mad,computer} scientist

Mike Beltzner

unread,
Feb 7, 2011, 11:06:30 AM2/7/11
to l.m. orchard, dev-apps...@lists.mozilla.org
On 2011-02-07, at 10:48 AM, l.m. orchard wrote:
> Again, not to make work for others, but: If we're dropping these from core Firefox, it might help to have a transition plan for people who use them. Could any or all of these be spun off into add-ons and possibly adopted by motivated developers? That might be a better story than simply getting rid of the features.

Hi Len,

It's difficult to see what bugs have been filed because project leaders have had discussions elsewhere and are now putting plans on record, vs. those which have been filed to begin discussions. As a project leader on Firefox who hadn't heard of any of these proposals until this email, I can tell you that we are very much dealing with the latter of those cases at this point in time.

That's not to say "these won't happen," but rather to thank you for taking those discussions here, and to your blog. The analogy to phone booths is almost right (in that it highlights the cost of maintenance and upkeep, especially when things are broken) and a good framing. I have personal opinions and instincts here unfounded on data (microsummaries flopped despite my love for them, smart bookmarks should either be invested in or left to add-ons, tagging should stay and continue to be developed, we should either invest or divest from RSS) but first, I'd love to hear from the person who filed the bug about the rationale. Removing features is often virtuous, but we should - as you say - understand why we're doing it.

Let's all please try to keep this discussion focused on the costs and benefits, and look for real (not anecdotal) data where possible to support claims. Unfounded claims are welcome (indeed, that's how a lot of our product has been designed - by instinct) but please call those out when you're making them (as I did, above)

cheers,
mike

Shawn Wilsher

unread,
Feb 7, 2011, 12:40:39 PM2/7/11
to dev-apps...@lists.mozilla.org
On 2/7/2011 8:06 AM, Mike Beltzner wrote:
> Let's all please try to keep this discussion focused on the costs and benefits, and look for real (not anecdotal) data where possible to support claims. Unfounded claims are welcome (indeed, that's how a lot of our product has been designed - by instinct) but please call those out when you're making them (as I did, above)
While I can't speak for the costs to Sync, I can speak about the costs
for the Places team. All four of these features do a bunch of
synchronous disk I/O, which is something we are trying to move away
from. I can see it easily taking one to two months of work for one
person to rewrite each feature to be asynchronous, but we'd have to
create those asynchronous APIs first (probably two to three months worth
of work). Some of this work is parallelizable, but we are still looking
at six to eleven months of an engineer's time (and these estimates
aren't any good since I haven't done much work investigating
specifically what needs to be done; my gut tells me I'm probably missing
some important details and it will take longer).

Given that we only have two people (Marco and myself) really working on
Places code for anything other than random bug fixes, both of which have
responsibilities outside of Places code, this is an awful lot of
engineering resources to spend on updating this code. There are
certainly other performance improvements we need to make in Places code
too, which will compete for engineering resources.

With all that said, the Places team hasn't really discussed this yet
ourselves. This bug was filed by a member of the Sync team because
there was a cost of supporting these features with Sync. I'll let
Phillip comment on that.

Hope this helps!

Cheers,

Shawn

P.S. Before anybody asks, yes, we have to convert all these features to
use asynchronous APIs.

Marco Bonardo

unread,
Feb 7, 2011, 1:10:39 PM2/7/11
to
Il 07/02/2011 17:06, Mike Beltzner ha scritto:
> It's difficult to see what bugs have been filed because project leaders have had discussions elsewhere and are now putting plans on record, vs. those which have been filed to begin discussions.

Most of those bugs have not been filed after leaders discussions I
think, but it's still good to discuss the point of features removal if
there is a good rationale to do so.

Microsummaries bug is probably the most "near" to what was discussed,
the point about their removal is that Microsummaries as a standard,
really never took off. The cost to retain them is high in the sense that
the code is not that much maintained (low prio), the benefit is small
(percentage of websites and users using them) and it's a really big pile
of code (actually the biggest js component we have in Places, reaching
70KB).
If we're not going to remove the support we need at least to put their
code on a diet and only support a minimal feature (just read and save
them from pages).

Tags, livemarks and queries have different issues, where the
implementation is costly because:
- the database schema is hard to change (downgrade compatibility) and
causes complicate code
- the backend API is all sync and a perf killer
- rewrite features on top of changing APIs is time consuming
I don't feel like we should drop these features, a "reset" of their
implementation is probably needed though.
I think that, if those features are going to slow down or complicate the
process of modernizing (async) the underlying API and schema, it's even
possible we could ask to kill them for a release and reimplement them
better on the new API.
I such a case we should be prepared to the noise around those decisions
though, removing stuff promising to reintroduce it in future, is not
that different from just removing it from the user's point of view, he
won't have that feature for months.

Marco

Mike Shaver

unread,
Feb 7, 2011, 1:25:06 PM2/7/11
to Marco Bonardo, dev-apps...@lists.mozilla.org
On Mon, Feb 7, 2011 at 10:10 AM, Marco Bonardo <ma...@supereva.it> wrote:
> - the database schema is hard to change (downgrade compatibility) and causes
> complicate code

I think we should consider walking away from downgrade compatibility, tbh.

Mike

Philipp von Weitershausen

unread,
Feb 7, 2011, 2:08:20 PM2/7/11
to
I realize I should've come to this list first. I was mostly trying to
avoid having this discussion during the Firefox 4 end-game, so I
merely filed a few bugs. I would definitely have brought this up post
Firefox 4, but alas, people actually watch Bugzilla :)

These bugs were a classic case of rage-file while I was walking
through our bookmark sync code. It is brittle and probably buggy. It
will need a rewrite, if not for this then for the async I/O Shawn has
already mentioned. Shawn and I spent several man-months making history
sync do async I/O so he's got his estimates on what it would take for
bookmarks quite right IMHO.


A lot of people seem to care about tags, and I personally feel the
least strongly about removing those. However, it turns out the
database schema for tags is the most problematic one (sdwilsh and mak
may back me up or disagree with me here) and will probably require the
most engineering effort going forward. That said, if lots of people
care about tags, then we have even the more reason to fix this!

I haven't seen much pushback about microsummaries and smart
bookmarks/queries. I think the latter are a neat feature, but
something that I'm not sure we need to support in the bookmarking UI.
If add-ons want to use places queries to display the bookmark tree in
different ways, that'll be great. But given our drive to leaner UI,
they seem like a good candidate for a UI feature to drop (not to
mention that they're nearly impossible to create right now in the UI).

As for Livemarks, we just have to make a call about whether we want
Firefox to be an RSS reader (and a bad one at that) or not. I
personally think the web has solved this problem better and if we feel
like Mozilla needs to continue to be in this space, you know, we do
cloud services these days...

Philipp von Weitershausen

unread,
Feb 7, 2011, 2:09:14 PM2/7/11
to

+1

I think we should consider having each major version of Firefox use a
different profile with an explicit upgrade step. That way, if users go
through the upgrade + oh-noez-i-dun-like-it + downgrade cycle as they
sometimes do, their original profile won't be destroyed. We could even
trim no longer used data in various DBs, potentially solving some of
the slow startup problems users with ancient profiles are seeing.

Ideally such a step would be silent (as would the upgrade be),
although copying/converting a profile could be rather expensive.

Zack Weinberg

unread,
Feb 7, 2011, 2:14:11 PM2/7/11
to
On 2011-02-07 11:09 AM, Philipp von Weitershausen wrote:
> I think we should consider having each major version of Firefox use a
> different profile with an explicit upgrade step. That way, if users go
> through the upgrade + oh-noez-i-dun-like-it + downgrade cycle as they
> sometimes do, their original profile won't be destroyed.

I'd like to second this proposal wholeheartedly.

zw

Rob Campbell

unread,
Feb 7, 2011, 2:31:28 PM2/7/11
to Philipp von Weitershausen, dev-apps...@lists.mozilla.org

On 2011-02-07, at 15:09 , Philipp von Weitershausen wrote:

> On Feb 7, 10:25 am, Mike Shaver <mike.sha...@gmail.com> wrote:
>> On Mon, Feb 7, 2011 at 10:10 AM, Marco Bonardo <ma...@supereva.it> wrote:
>>> - the database schema is hard to change (downgrade compatibility) and causes
>>> complicate code
>>
>> I think we should consider walking away from downgrade compatibility, tbh.
>
> +1
>
> I think we should consider having each major version of Firefox use a
> different profile with an explicit upgrade step. That way, if users go
> through the upgrade + oh-noez-i-dun-like-it + downgrade cycle as they
> sometimes do, their original profile won't be destroyed. We could even
> trim no longer used data in various DBs, potentially solving some of
> the slow startup problems users with ancient profiles are seeing.

Not a bad idea. Plus, if the Places backup schema (json) remains compatible, users could restore from their "future" profile to the previous one and not lose any data, albeit, with a manual step to bridge the two profiles..

Speaking of cloud services, I'd love to have the ability to actually share my places bookmarks (tags and all).

PS, +1 to not killing tags, thx.

~ rob

Les Orchard

unread,
Feb 7, 2011, 2:44:15 PM2/7/11
to
On 2/7/11 2:08 PM, Philipp von Weitershausen wrote:
> I realize I should've come to this list first. I was mostly trying to
> avoid having this discussion during the Firefox 4 end-game, so I
> merely filed a few bugs. I would definitely have brought this up post
> Firefox 4, but alas, people actually watch Bugzilla :)

Hope I wasn't too much of a troublemaker there! (Sorry if I was!) I
started angst-commenting based on a "hey, I just started using that!"
knee-jerk.

> These bugs were a classic case of rage-file while I was walking
> through our bookmark sync code. It is brittle and probably buggy. It
> will need a rewrite, if not for this then for the async I/O Shawn has
> already mentioned. Shawn and I spent several man-months making history
> sync do async I/O so he's got his estimates on what it would take for
> bookmarks quite right IMHO.

That does indeed sound like hard enough work to do some reflection on
whether some features are worth the trouble.

I'm a noob to Firefox development - so it's probably best I stay out of
the kitchen - but I'm interested enough in some of these features to
help if I can.

> A lot of people seem to care about tags, and I personally feel the
> least strongly about removing those. However, it turns out the
> database schema for tags is the most problematic one (sdwilsh and mak
> may back me up or disagree with me here) and will probably require the
> most engineering effort going forward. That said, if lots of people
> care about tags, then we have even the more reason to fix this!

Tags are one of those things, I suspect, that may have a small audience
but are relied upon heavily by that group.

For me personally, folders are useless. I suspect that it's a matter of
scale. Once you get above a certain number of items, hand-maintained
hierarchical structures become less useful and search / on-the-fly
tagging becomes more handy.

I guess it comes down to "what are bookmarks"? Is the feature in Firefox
meant to be a small collection of often-visited sites? Or, is it the
basis for a personal search engine? I want the latter, but I admittedly
want weird things sometimes. :)

> I haven't seen much pushback about microsummaries and smart
> bookmarks/queries. I think the latter are a neat feature, but
> something that I'm not sure we need to support in the bookmarking UI.

Microsummaries did indeed seem neat when I first saw them years ago, but
have never revisited them since. Smart Bookmarks, I never knew about
until the last month or so. They seem keen, but maybe still in need of
baking.

> If add-ons want to use places queries to display the bookmark tree in
> different ways, that'll be great. But given our drive to leaner UI,
> they seem like a good candidate for a UI feature to drop (not to
> mention that they're nearly impossible to create right now in the UI).

As long as Places URI's still work, it seems like Smart Bookmarks would
be a good candidate to spin off as an addon. Then, if someone really
cares about smart bookmarks, better UI could be worked on there by
developers with time and interest.

> As for Livemarks, we just have to make a call about whether we want
> Firefox to be an RSS reader (and a bad one at that) or not. I
> personally think the web has solved this problem better and if we feel
> like Mozilla needs to continue to be in this space, you know, we do
> cloud services these days...

This is an area where I personally have more enthusiasm than answers, so
I can't say that Livemarks are a hill to die on. But, I do think we
should explore this space. It seems like we have had some interesting
experiments in Labs, and I'd like to play too.

FWIW, something I hadn't considered until bwinton pinged me today in IRC
is that this may more properly be Mozilla Messaging's bailiwick than
Firefox's. I haven't had the chance to play much with Raindrop, but
something in that genre may be a better answer than making Firefox into
a better RSS reader.

lsblakk

unread,
Feb 7, 2011, 2:51:12 PM2/7/11
to

>
> PS, +1 to not killing tags, thx.
>
Another +1

I tag my bookmarks, it helps me find things faster in the awesomebar.
Tagging + awesomebar = a lot of win for me.

my $0.02

Mike Beltzner

unread,
Feb 7, 2011, 3:03:29 PM2/7/11
to lsblakk, dev-apps...@lists.mozilla.org
Not to pick on anyone who's +1'd the request to preserve tags, but it's unlikely that a vote of those who happening to be reading this channel will really be an effective input in this decision.

So far, over in the other thread or indeed in the bug itself, I have not yet heard a thoroughly compelling reason to *remove* tags. There are costs, to be sure, but it's generally acknowledged that the extensibility and usage patterns around tags warrant trying to solve those costs in other ways.

cheers,
mike

Hasse

unread,
Feb 7, 2011, 3:05:44 PM2/7/11
to
In article <e1358969-85dc-4468-956a-335de699514a@
8g2000prt.googlegroups.com>, Philipp von Weitershausen wrote...


> I haven't seen much pushback about microsummaries and smart
> bookmarks/queries. I think the latter are a neat feature, but
> something that I'm not sure we need to support in the bookmarking UI.
> If add-ons want to use places queries to display the bookmark tree in
> different ways, that'll be great. But given our drive to leaner UI,
> they seem like a good candidate for a UI feature to drop (not to
> mention that they're nearly impossible to create right now in the UI).

Why do you continue to insist that they are nearly impossible to
create? Didn't you learn in https://bugzilla.mozilla.org/show_bug.cgi?
id=622045#c5 that it is as easy as doing a search and clicking on the
Save button?

--
Hasse
sv-SE l10n team

lsblakk

unread,
Feb 7, 2011, 3:08:49 PM2/7/11
to

> So far, over in the other thread

Link please? I realize my input is not data-driven so I'm really just
asking out of curiosity and to see what happens

> or indeed in the bug itself,

I came over here because https://bugzilla.mozilla.org/show_bug.cgi?id=622047#c24
which said the bug was not the place to discuss.

> I have not yet heard a thoroughly compelling reason to *remove* tags. There are costs, to be sure, but it's generally acknowledged that the extensibility and usage patterns around tags warrant trying to solve those costs in other ways.

Thanks for this.


Philipp von Weitershausen

unread,
Feb 7, 2011, 3:21:07 PM2/7/11
to Hasse, dev-apps...@lists.mozilla.org

I apologize for my use of words. I didn't mean to say "impossible", I
meant to say "extremely difficult". So far I count two ways:

* drag a tag from the Tags folder to somewhere else (creates a smart
bookmark that queries that tag).

* save a search

I find both extremely undiscoverable. In fact, I didn't know about
them at all before I actually started asking people how the heck you
create a smart bookmark.

Marco Bonardo

unread,
Feb 7, 2011, 4:01:44 PM2/7/11
to
Il 07/02/2011 20:08, Philipp von Weitershausen ha scritto:
> A lot of people seem to care about tags, and I personally feel the
> least strongly about removing those. However, it turns out the
> database schema for tags is the most problematic one (sdwilsh and mak
> may back me up or disagree with me here) and will probably require the
> most engineering effort going forward.

What requires the most engineering effort imo is the downgrade issue,
and that's globally an issue that hits a lot of modules. I second your
suggestion to solve this issue once and for all, through a profile
behavior review, it would also help solving the longstanding
"dirty-profiles" issue.
Making a revised tagging backend would not be that hard, sure, it would
require some time, but it's a pretty self contained feature and would
simplify a lot of the code that today has to figure out if a bookmark is
real or is a tag.
Most likely a good tagging UI would be harder to make.

> I haven't seen much pushback about microsummaries and smart
> bookmarks/queries. I think the latter are a neat feature, but
> something that I'm not sure we need to support in the bookmarking UI.

I agree the UI is not that great, and I could even agree we could want
to remove it and try to come with something better. The point is that
this won't save a thing, Places would still have to handle place:
queries internally, and Sync would still have to manage them.
the UI part is not a large cost for Places, originally we had a
truth-table-like UI to build complicated queries, we removed most of it
for its complexity and maintenance cost (plus it was never finished)
during the process that brought to Firefox 3. So yes, what we have today
is a cut-off UI feature, the less expensive part of it. Removing it
would be a no-brainer, but there is no clear win. Instead there was (and
I think the project is still valid) discussion to move the Library to
content (like it was done in about:addons) and then having a place: uri
that can represent a filtered content comes back to be useful.

> As for Livemarks, we just have to make a call about whether we want
> Firefox to be an RSS reader (and a bad one at that) or not. I
> personally think the web has solved this problem better and if we feel
> like Mozilla needs to continue to be in this space, you know, we do
> cloud services these days...

I feel like, now that we have lost the rss indicator, this is a hard
discussion to get right. Surely the button was not used that much, but
that's an hard indicator of RSS usage, I use them everyday, but I add
new ones rarely (probably once every 2 months). What Firefox has, is
enough for me, using an add-on could even be fine... for me.
The problem is that livemarks are today provided by most web pages and
browser is moving away from the concept of being just a html reader. In
some markets it's seen and used more like an entertainment system. As a
user of this system, I'd be surprised to being unable to access some
information in a format that most of the websites provide by default.
Even if we remove our crappy livemarks-as-folders support, we will have
to spend time to provide an alternative to give access to this resource.
Regarding the maintenance cost, livemarks have similar cost (and
solutions) of tags, with the subtle difference that we don't care about
safety of their contents (since we can always re-download them).

Globally, most of the features you feel unfinished ARE unfinished (in
the sense of far-from-perfect), due to re-prioritization of stuff they
mostly got low priority in the cycle and were built, adapted or cut to
work in the most common use-cases. They can be improved, this is not a
new fact to anyone.

Marco

Philipp von Weitershausen

unread,
Feb 7, 2011, 4:09:55 PM2/7/11
to Mike Beltzner, l.m. orchard, dev-apps...@lists.mozilla.org
On Mon, Feb 7, 2011 at 8:06 AM, Mike Beltzner <belt...@mozilla.com> wrote:
> Let's all please try to keep this discussion focused on the costs and benefits, and look for real (not anecdotal) data where possible to support claims. Unfounded claims are welcome (indeed, that's how a lot of our product has been designed - by instinct) but please call those out when you're making them (as I did, above)

Filed a bug to get test pilot data for this:
https://bugzilla.mozilla.org/show_bug.cgi?id=632153

Shawn Wilsher

unread,
Feb 7, 2011, 4:18:07 PM2/7/11
to dev-apps...@lists.mozilla.org
On 2/7/2011 11:08 AM, Philipp von Weitershausen wrote:
> A lot of people seem to care about tags, and I personally feel the
> least strongly about removing those. However, it turns out the
> database schema for tags is the most problematic one (sdwilsh and mak
> may back me up or disagree with me here) and will probably require the
> most engineering effort going forward. That said, if lots of people
> care about tags, then we have even the more reason to fix this!
How tags are stored in the database is pretty problematic, and it is
certainly something that needs to be fixed moving forward (working off
the assumption that we keep tags). It's one of the most painful
architecture issues we have left to tackle in Places, IMO. In fact, if
I could call do-over, this would be #2 on my list of things we should
change from the original Places architecture.

Cheers,

Shawn

Shawn Wilsher

unread,
Feb 7, 2011, 4:23:31 PM2/7/11
to dev-apps...@lists.mozilla.org
On 2/7/2011 1:01 PM, Marco Bonardo wrote:
> Globally, most of the features you feel unfinished ARE unfinished (in
> the sense of far-from-perfect), due to re-prioritization of stuff they
> mostly got low priority in the cycle and were built, adapted or cut to
> work in the most common use-cases. They can be improved, this is not a
> new fact to anyone.
To elaborate on this, ever since Firefox 3.0 shipped with Places
enabled, the vast majority of the work that has been done has been
fixing architectural issues and some very minor polish of features (at
least that is the impression I've gotten while working on it over the
years). We simply do not have the engineering resources to do much of
anything else (and I don't foresee that changing within the next year).

With that said, if people want to step up and help out, I'm certain that
Marco, Dietrich, or myself would be happy to help by pointing out bugs
at a specified level of difficulty for you to work on, helping figure
out how to fix an issue, and providing prompt review so we can get
things fixed in Firefox 5.0 and beyond. Feel free to poke us on irc
(mak, dietrich, or sdwilsh) or send us mail directly.

Cheers,

Shawn

Shawn Wilsher

unread,
Feb 7, 2011, 4:27:58 PM2/7/11
to dev-apps...@lists.mozilla.org
On 2/7/2011 1:18 PM, Shawn Wilsher wrote:
> How tags are stored in the database is pretty problematic, and it is
> certainly something that needs to be fixed moving forward (working off
> the assumption that we keep tags). It's one of the most painful
> architecture issues we have left to tackle in Places, IMO. In fact, if I
> could call do-over, this would be #2 on my list of things we should
> change from the original Places architecture.
Since I've already gotten one question about this off-thread, #1 is to
not do synchronous disk I/O (ever).

Cheers,

Shawn

Dao

unread,
Feb 7, 2011, 4:35:48 PM2/7/11
to
On 07.02.2011 20:08, Philipp von Weitershausen wrote:
> I haven't seen much pushback about microsummaries and smart
> bookmarks/queries. I think the latter are a neat feature, but
> something that I'm not sure we need to support in the bookmarking UI.
> If add-ons want to use places queries to display the bookmark tree in
> different ways, that'll be great. But given our drive to leaner UI,
> they seem like a good candidate for a UI feature to drop (not to
> mention that they're nearly impossible to create right now in the UI).

By default there's a "Most Visited" folder on the bookmarks toolbar. I
see random people use that every now and then.

That folder is going to be mostly undiscoverable with the bookmarks
toolbar being hidden by default, though...

Alex Faaborg

unread,
Feb 7, 2011, 4:55:44 PM2/7/11
to Philipp von Weitershausen, dev-apps...@lists.mozilla.org
A couple thoughts from a UI perspective:

A lot of people seem to care about tags, and I personally feel the
> least strongly about removing those. However, it turns out the
> database schema for tags is the most problematic one
>

I've never really liked that we have both tags and folders, and that we felt
that the path of least resistance was to layer on greater levels of
complexity so as not to offend users of the existing system. Ideally we
would introduce a single grouping mechanism that had the properties of both
systems (ability to be nested in a hierarchy, pages can exist in multiple
places, either mouse or keyboard based input for associations). In terms of
fixing the database schema, that's of course orthogonal to if we want to
support two competing organization schemes in our UI.

As for Livemarks, we just have to make a call about whether we want
> Firefox to be an RSS reader (and a bad one at that) or not. I
> personally think the web has solved this problem better and if we feel
> like Mozilla needs to continue to be in this space
>

We might be introducing an ambient news feed in the Home Tab. Martell has a
really nice mockup here:
http://blog.seanmartell.com/wp-content/uploads/2009/04/newtab_1.jpg
That would effectively be the same use case as a Livemark (not the kind of
feed reader that behaves like an email client, and you read every message,
but just some glance-able information from your favorite sites.)

These bugs were a classic case of rage-file
>

Nice use of the phrase rage-file :)

-Alex

> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>

Axel Hecht

unread,
Feb 7, 2011, 5:11:53 PM2/7/11
to
On 07.02.11 22:01, Marco Bonardo wrote:
> Il 07/02/2011 20:08, Philipp von Weitershausen ha scritto:
<...>

One thing to keep in mind is that we shipped a live bookmark in default
profiles for ages. Ripping this out will not be as easy as just removing
code. Not rocket science either, too.

Axel

Axel Hecht

unread,
Feb 7, 2011, 5:25:10 PM2/7/11
to
On 07.02.11 20:08, Philipp von Weitershausen wrote:
<...>

> I haven't seen much pushback about microsummaries and smart
> bookmarks/queries. I think the latter are a neat feature, but
> something that I'm not sure we need to support in the bookmarking UI.
> If add-ons want to use places queries to display the bookmark tree in
> different ways, that'll be great. But given our drive to leaner UI,
> they seem like a good candidate for a UI feature to drop (not to
> mention that they're nearly impossible to create right now in the UI).

I'd like to comment on the microsummaries and rss piece, because I felt
that'd be interesting from an "implementors" side.

I did consider microsummaries for my variant of tbpl on the l10n
dashboard, kinda showing how builds for a landing progress.

The default timing is 15 mins IIRC, which was pretty much "neither fish
nor flesh". Not often enough to be up-to-date, and too often to not be a
hassle on the server for left-overs.

I did end up doing RSS feeds with a build status overview, though, check
out https://l10n-stage-sj.mozilla.org/builds/builds_for?change=70520 for
an example.

Axel

Alex Faaborg

unread,
Feb 7, 2011, 4:56:44 PM2/7/11
to Dao, dev-apps...@lists.mozilla.org
>
> By default there's a "Most Visited" folder on the bookmarks toolbar. I
> see random people use that every now and then.
>

Also an extremely likely candidate for Home Tab placement, to still allow
for the same use case.

-Alex

Asa Dotzler

unread,
Feb 7, 2011, 6:42:19 PM2/7/11
to
On 2/7/2011 11:09 AM, Philipp von Weitershausen wrote:
> On Feb 7, 10:25 am, Mike Shaver<mike.sha...@gmail.com> wrote:
>> On Mon, Feb 7, 2011 at 10:10 AM, Marco Bonardo<ma...@supereva.it> wrote:
>>> - the database schema is hard to change (downgrade compatibility) and causes
>>> complicate code
>>
>> I think we should consider walking away from downgrade compatibility, tbh.
>
> +1
>
> I think we should consider having each major version of Firefox use a
> different profile with an explicit upgrade step. That way, if users go
> through the upgrade + oh-noez-i-dun-like-it + downgrade cycle as they
> sometimes do, their original profile won't be destroyed. We could even
> trim no longer used data in various DBs, potentially solving some of
> the slow startup problems users with ancient profiles are seeing.

That assumes we're supporting downgrades and I honestly don't know if
that's the right thing to do. We'll certainly have reconsider our
downgrade and older version support commitment if we move to doing
several releases a year.

- A

Michael Lefevre

unread,
Feb 7, 2011, 7:39:43 PM2/7/11
to

Having data is probably a good thing, but I wonder how it might be used.
I don't think that simply looking at the percentage of users that use a
feature gives a complete assessment of the benefit.

In a year's time, will someone be coming along to find that not so many
users are using sync or panorama or app tabs or the web console and
propose dropping them?

I'm not suggesting it's happening yet or will happen, but going too far
in this direction would seem to lead to constantly implementing new
features, not polishing them enough, and then dropping them again, which
can't be good...

Michael

Shawn Wilsher

unread,
Feb 7, 2011, 7:49:05 PM2/7/11
to dev-apps...@lists.mozilla.org
On 2/7/2011 4:39 PM, Michael Lefevre wrote:
> In a year's time, will someone be coming along to find that not so many
> users are using sync or panorama or app tabs or the web console and
> propose dropping them?
We aren't going to just look at usage. We are looking at usage compared
to cost of maintenance. If the maintenance cost is low, and the usage
is low, I'm not sure we'd have a strong argument to cut a feature.
However, with some of these things, the cost is very high, so if it's
not being used, that's a data point that I would consider to be in favor
of dropping it. It certainly shouldn't be the only data point either.

Cheers,

Shawn

Asa Dotzler

unread,
Feb 7, 2011, 8:00:09 PM2/7/11
to

I also think we do look at a couple of different audiences when working
out our features and so we'll evaluate based on the audience the feature
was designed for.

For example, I don't think it's reasonable to say "let's cut the Web
Console because only 2% of our general audience use it" when the feature
isn't designed to be used by a general audience.

Fortunately, we have ways within TestPilot to survey users and determine
which audience they come from. So, if we found that near zero percent of
our Web Developer audience were using a Web Developer features, then
we'd probably want to start talking about opportunity costs for the
Mozilla developer hours put into that feature.

- A

Boris Zbarsky

unread,
Feb 7, 2011, 9:35:07 PM2/7/11
to
On 2/7/11 6:42 PM, Asa Dotzler wrote:
> That assumes we're supporting downgrades and I honestly don't know if
> that's the right thing to do. We'll certainly have reconsider our
> downgrade and older version support commitment if we move to doing
> several releases a year.

I feel like we really need to support downgrades to at least the version
before current, for people who install current and it breaks something
they rely on. What are they supposed to do? Not browse the web until
we fix it?

Downgrades past that point I'm not worried about.

-Boris

Mike Beltzner

unread,
Feb 7, 2011, 10:06:22 PM2/7/11
to dev-apps...@lists.mozilla.org
I'll blow all of your minds: this all assumes that we're planning on
continuing to support N-1 versions of the product once we've shipped
version N.

We do that now (in fact, we're planning on supporting 3.5 and 3.6 once
we ship 4.0!) but I don't think we can take that assumption for granted.
The only competitor of ours that continues to do that struggles mightily
for it and fragments their own user base.

cheers,
mike

Asa Dotzler

unread,
Feb 7, 2011, 10:32:38 PM2/7/11
to

That's sort of what I was getting at. And the most effective competitor
at keeping all their users on the latest version doesn't support n-1 and
never has.

I think supporting older versions is a huge burden and something we
should seriously consider moving away from especially as we move to a
more frequent release cadence.

- A

Boris Zbarsky

unread,
Feb 7, 2011, 11:22:49 PM2/7/11
to
On 2/7/11 10:32 PM, Asa Dotzler wrote:
> I think supporting older versions is a huge burden and something we
> should seriously consider moving away from especially as we move to a
> more frequent release cadence.

I think there's a difference, though, between "we no longer support
version N-1" and "if you ever try to run version N-1 after running
version N, it will corrupt your profile". The latter is where we are
now; for example the user "loses" places.sqlite in that situation (can
be recovered if you know the right magic, but it's not exactly obvious
magic).

iirc Chrome solves this by simply having version N-1 refuse to use the
profile if it detects that it's been upgraded to version N, but it's
been a bit since I tested this carefully.

Of course this does mean that if version N isn't working for some reason
you're screwed.

-Boris

Shawn Wilsher

unread,
Feb 7, 2011, 11:32:44 PM2/7/11
to dev-apps...@lists.mozilla.org
On 2/7/2011 8:22 PM, Boris Zbarsky wrote:
> I think there's a difference, though, between "we no longer support
> version N-1" and "if you ever try to run version N-1 after running
> version N, it will corrupt your profile". The latter is where we are
> now; for example the user "loses" places.sqlite in that situation (can
> be recovered if you know the right magic, but it's not exactly obvious
> magic).
I don't believe we are in either case right now. Users should be able
to go from 3.6 -> 4.0 -> 3.6 without corrupting their profile (I tested
this manually). We even have a test case in the tree that tests 4.0 ->
3.6 -> 4.0 [1] as well as one that tests 3.6 -> 4.0 [2]. There was a
time (during most of our beta phase) that going to back to 3.6 after 4.0
would cause this corruption (which I know you hit), but for most of our
users, that will never be a problem.

Cheers,

Shawn

[1]
https://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/tests/migration/test_v11_from_v10_migrated_from_v11.js
[2]
https://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/tests/migration/test_v11_from_v10.js

Alex Faaborg

unread,
Feb 7, 2011, 11:48:10 PM2/7/11
to Shawn Wilsher, dev-apps...@lists.mozilla.org
In the event that version N and version N-1 both support Sync (and assuming
that we decide that Sync servers will continue to have N-1 support), then we
could pretty effectively rely on that for downgrade. We wouldn't have to
worry about changes to the places schema, etc. and users will still have
access to all of their data (bookmarks, passwords, etc.) across both N and
N-1.

-Alex

On Mon, Feb 7, 2011 at 8:32 PM, Shawn Wilsher <sdw...@mozilla.com> wrote:

> On 2/7/2011 8:22 PM, Boris Zbarsky wrote:
>

>> I think there's a difference, though, between "we no longer support
>> version N-1" and "if you ever try to run version N-1 after running
>> version N, it will corrupt your profile". The latter is where we are
>> now; for example the user "loses" places.sqlite in that situation (can
>> be recovered if you know the right magic, but it's not exactly obvious
>> magic).
>>

> I don't believe we are in either case right now. Users should be able to
> go from 3.6 -> 4.0 -> 3.6 without corrupting their profile (I tested this
> manually). We even have a test case in the tree that tests 4.0 -> 3.6 ->
> 4.0 [1] as well as one that tests 3.6 -> 4.0 [2]. There was a time (during
> most of our beta phase) that going to back to 3.6 after 4.0 would cause this
> corruption (which I know you hit), but for most of our users, that will
> never be a problem.
>
> Cheers,
>
> Shawn
>
> [1]
> https://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/tests/migration/test_v11_from_v10_migrated_from_v11.js
> [2]
> https://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/tests/migration/test_v11_from_v10.js
>
>

Boris Zbarsky

unread,
Feb 7, 2011, 11:59:42 PM2/7/11
to
On 2/7/11 11:32 PM, Shawn Wilsher wrote:
> There was a
> time (during most of our beta phase) that going to back to 3.6 after 4.0
> would cause this corruption (which I know you hit), but for most of our
> users, that will never be a problem.

Ah, excellent. That makes me feel much better!

-Boris

Philip Chee

unread,
Feb 8, 2011, 12:20:07 AM2/8/11
to
On Mon, 07 Feb 2011 10:48:26 -0500, l.m. orchard wrote:

> In a nutshell: I don't want to be a stop energy generator, but I think
> some of these are important features. Okay, not microsummaries so much,
> but maybe smart bookmarks and definitely tagging and livemarks. In fact,
> dropping some of these will result in user data loss (eg. tags in
> particular)

We have SeaMonkey users reluctant to move from SM2.0 (bookmarks.html) to
the forthcoming SM2.1 (Places) due to perceived possible loss of
functionality. Tags were one of the features that we used to sell Places
bookmarks to them as a replacement workflow to what they were used to
with the bookmarks.html implementation.

> Again, not to make work for others, but: If we're dropping these from
> core Firefox, it might help to have a transition plan for people who use
> them. Could any or all of these be spun off into add-ons and possibly
> adopted by motivated developers? That might be a better story than
> simply getting rid of the features.

I hope that Firefox only removes the tagging UI as SeaMonkey would
certainly want to retain that as a selling point and a differentiator
to a less capable Firefox.

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

Philip Chee

unread,
Feb 8, 2011, 12:32:22 AM2/8/11
to
On Mon, 7 Feb 2011 13:55:44 -0800, Alex Faaborg wrote:

> I've never really liked that we have both tags and folders, and that we felt
> that the path of least resistance was to layer on greater levels of
> complexity so as not to offend users of the existing system. Ideally we
> would introduce a single grouping mechanism that had the properties of both
> systems (ability to be nested in a hierarchy, pages can exist in multiple
> places, either mouse or keyboard based input for associations). In terms of
> fixing the database schema, that's of course orthogonal to if we want to
> support two competing organization schemes in our UI.

I notice in user groups there are people who think in terms of tags and
there are people who think in terms of folder hierarchy and these two
groups can never agree. I'd suspect that neither would be willing to
accept a compromise either.

Robert Kaiser

unread,
Feb 8, 2011, 11:39:03 AM2/8/11
to
Philip Chee schrieb:

> I hope that Firefox only removes the tagging UI as SeaMonkey would
> certainly want to retain that as a selling point and a differentiator
> to a less capable Firefox.

SeaMonkey can't go and impose requirements on what Firefox developers
can do or not, so let's not get into that.
If this was to be removed, it would be nice if there was a possibility
for some consumer of the core code like SeaMonkey to implement it as an
extension of the core code - but then, this is all hypothetical and I
don't think that tags will be removed in the end anyhow.

Robert Kaiser


--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)

EE

unread,
Feb 8, 2011, 3:01:39 PM2/8/11
to
On 2011/02/07 12:44, Les Orchard wrote:

> On 2/7/11 2:08 PM, Philipp von Weitershausen wrote:
>> I realize I should've come to this list first. I was mostly trying to
>> avoid having this discussion during the Firefox 4 end-game, so I
>> merely filed a few bugs. I would definitely have brought this up post
>> Firefox 4, but alas, people actually watch Bugzilla :)
>
> Hope I wasn't too much of a troublemaker there! (Sorry if I was!) I
> started angst-commenting based on a "hey, I just started using that!"
> knee-jerk.

>
>> These bugs were a classic case of rage-file while I was walking
>> through our bookmark sync code. It is brittle and probably buggy. It
>> will need a rewrite, if not for this then for the async I/O Shawn has
>> already mentioned. Shawn and I spent several man-months making history
>> sync do async I/O so he's got his estimates on what it would take for
>> bookmarks quite right IMHO.
>
> That does indeed sound like hard enough work to do some reflection on
> whether some features are worth the trouble.
>
> I'm a noob to Firefox development - so it's probably best I stay out of
> the kitchen - but I'm interested enough in some of these features to
> help if I can.

>
>> A lot of people seem to care about tags, and I personally feel the
>> least strongly about removing those. However, it turns out the
>> database schema for tags is the most problematic one (sdwilsh and mak
>> may back me up or disagree with me here) and will probably require the
>> most engineering effort going forward. That said, if lots of people
>> care about tags, then we have even the more reason to fix this!
>
> Tags are one of those things, I suspect, that may have a small audience
> but are relied upon heavily by that group.
>
> For me personally, folders are useless. I suspect that it's a matter of
> scale. Once you get above a certain number of items, hand-maintained
> hierarchical structures become less useful and search / on-the-fly
> tagging becomes more handy.
>
> I guess it comes down to "what are bookmarks"? Is the feature in Firefox
> meant to be a small collection of often-visited sites? Or, is it the
> basis for a personal search engine? I want the latter, but I admittedly
> want weird things sometimes. :)

>
>> I haven't seen much pushback about microsummaries and smart
>> bookmarks/queries. I think the latter are a neat feature, but
>> something that I'm not sure we need to support in the bookmarking UI.
>
> Microsummaries did indeed seem neat when I first saw them years ago, but
> have never revisited them since. Smart Bookmarks, I never knew about
> until the last month or so. They seem keen, but maybe still in need of
> baking.

>
>> If add-ons want to use places queries to display the bookmark tree in
>> different ways, that'll be great. But given our drive to leaner UI,
>> they seem like a good candidate for a UI feature to drop (not to
>> mention that they're nearly impossible to create right now in the UI).
>
> As long as Places URI's still work, it seems like Smart Bookmarks would
> be a good candidate to spin off as an addon. Then, if someone really
> cares about smart bookmarks, better UI could be worked on there by
> developers with time and interest.

>
>> As for Livemarks, we just have to make a call about whether we want
>> Firefox to be an RSS reader (and a bad one at that) or not. I
>> personally think the web has solved this problem better and if we feel
>> like Mozilla needs to continue to be in this space, you know, we do
>> cloud services these days...
>
> This is an area where I personally have more enthusiasm than answers, so
> I can't say that Livemarks are a hill to die on. But, I do think we
> should explore this space. It seems like we have had some interesting
> experiments in Labs, and I'd like to play too.
>
> FWIW, something I hadn't considered until bwinton pinged me today in IRC
> is that this may more properly be Mozilla Messaging's bailiwick than
> Firefox's. I haven't had the chance to play much with Raindrop, but
> something in that genre may be a better answer than making Firefox into
> a better RSS reader.
>
While you are at it, why not remove "Unsorted Bookmarks"? I never could
see any point to that folder. I want to put bookmarks into the proper
category immediately, not into some temporary storage.

Asa Dotzler

unread,
Feb 8, 2011, 3:12:50 PM2/8/11
to
On 2/8/2011 8:39 AM, Robert Kaiser wrote:
> Philip Chee schrieb:
>> I hope that Firefox only removes the tagging UI as SeaMonkey would
>> certainly want to retain that as a selling point and a differentiator
>> to a less capable Firefox.
>
> SeaMonkey can't go and impose requirements on what Firefox developers
> can do or not, so let's not get into that.
> If this was to be removed, it would be nice if there was a possibility
> for some consumer of the core code like SeaMonkey to implement it as an
> extension of the core code - but then, this is all hypothetical and I
> don't think that tags will be removed in the end anyhow.
>
> Robert Kaiser

It's the core code that's being considered for removal.

- A

Dao

unread,
Feb 8, 2011, 3:27:03 PM2/8/11
to

All of Places?

Asa Dotzler

unread,
Feb 8, 2011, 3:41:59 PM2/8/11
to

No. That's silly.

The discussion was about Places support for microsummaries, smart
bookmarks, tagging, and livemarks. There's non-trivial Places-level,
(core code) work that is required if these features are going to live
on. See Shawn's comment estimating 6 to 11 months worth of work just to
get them onto async IO.

- A

Dao

unread,
Feb 8, 2011, 3:55:37 PM2/8/11
to
On 08.02.2011 21:41, Asa Dotzler wrote:
> On 2/8/2011 12:27 PM, Dao wrote:
>> On 08.02.2011 21:12, Asa Dotzler wrote:
>>> On 2/8/2011 8:39 AM, Robert Kaiser wrote:
>>>> If this was to be removed, it would be nice if there was a possibility
>>>> for some consumer of the core code like SeaMonkey to implement it as an
>>>> extension of the core code - but then, this is all hypothetical and I
>>>> don't think that tags will be removed in the end anyhow.
>>>>
>>>> Robert Kaiser
>>>
>>> It's the core code that's being considered for removal.
>>
>> All of Places?
>
> No. That's silly.

I know. Places is the core code that Robert was hoping to extend in case
tagging wouldn't be part of it anymore.

Asa Dotzler

unread,
Feb 8, 2011, 4:07:14 PM2/8/11
to

I hadn't realized that Robert was signing up for the months worth of
work in Places code to keep those features alive. Nothing he or Philip
said suggested they wanted to take over support of core places code to
support their front-end features.

- A

Dao

unread,
Feb 8, 2011, 4:16:25 PM2/8/11
to

Quite right. If extending Places is an option, they can just do that
without signing up for something. It's their core extension backing
their front-end then.

Shawn Wilsher

unread,
Feb 8, 2011, 4:21:50 PM2/8/11
to dev-apps...@lists.mozilla.org
On 2/8/2011 1:07 PM, Asa Dotzler wrote:

> On 2/8/2011 12:55 PM, Dao wrote:
>> I know. Places is the core code that Robert was hoping to extend in case
>> tagging wouldn't be part of it anymore.
>
> I hadn't realized that Robert was signing up for the months worth of
> work in Places code to keep those features alive. Nothing he or Philip
> said suggested they wanted to take over support of core places code to
> support their front-end features.
I think the two of you are talking past each other. Asa appears to be
referring specifically to the tagging code in Robert's post ("If this
was to be removed"), whereas Dao appears to be referring to the core
code ("implement it as an extension of the core code") which doesn't
include the tagging back end.

To answer Robert's concern, yes, someone could still do tags if we
decided to drop that feature (they would have a few options to do so too).

Cheers,

Shawn

Philip Chee

unread,
Feb 9, 2011, 1:20:06 AM2/9/11
to
On Tue, 08 Feb 2011 13:01:39 -0700, EE wrote:

> While you are at it, why not remove "Unsorted Bookmarks"? I never could
> see any point to that folder. I want to put bookmarks into the proper
> category immediately, not into some temporary storage.

I think this is useful for those people who don't think hierarchically
and don't use folders but use tags instead.

Also I don't think unsorted bookmarks causes much if any performance
hit, probably less as the SQL query doesn't have to sort or filter
anything at all.

Ron Hunter

unread,
Feb 9, 2011, 4:01:27 AM2/9/11