Places and Firefox 2
Michael Schroepfer
increasingly clear that we do not have time to complete an
implementation of places that lives up to our standards of user
experience and quality. Places is a complex and exciting feature which
changes the way people use bookmarks, history, and navigate through
their private space of the web. Rather than rush it to market - we'd
prefer to spend the time it takes to get it right.
Thus, we are going to disable Places on the 1.8 branch and continue work
on the feature on the trunk for inclusion on a future release. This is
a difficult decision - but doing it this early in the release cycle
gives us the time to focus on delivering an extremely high quality FF2
in Q3 and gives Places the room it needs to develop into a truly
innovative feature.
To be clear - we're still focused on delivering Places as a truly
compelling end user feature in a future release. We're also confident
that the other features and enhancements slated for FF2 will provide a
great upgrade for 1.5 users and continue to be a compelling browser
choice for new users. Firefox 2 will improve security, tabbed browsing,
search, RSS/structured content discovery, performance, and extension
support. In order words, all the reasons people love Firefox will get
demonstrably better in this release.
At the Bon Echo meeting Tuesday at 11am we'll do a more in-depth review
of status of every feature area to figure out what else is at risk and
make sure we have all available effort focused on the critical areas.
So come prepared to talk about your feature area and plan for a longer
meeting than normal.
Cheers,
Schrep
Matt Nordhoff
Without Places, Firefox 2.0 will have nothing new. Security
improvements, making the tabbed browsing UI worse ( :-P ), the search
XML backend and manager thingy, improved feed discovery, performance and
extension support... That's nothing. Even Places isn't very much, if
you're only thinking about the frontend as most users will. Users are
going to be extremely disappointed when they see nothing new or interesting.
mozilla.feedback has "I don't see any big differences" repeated
frequently over 2.0a1, and it had Places. From your post, Firefox 2.0
sounds like it should be called Firefox 1.6.
--
Matt Nordhoff
(aka Peng on IRC & the forums)
Matt Nordhoff
> Without Places, Firefox 2.0 will have nothing new. Security
> improvements, making the tabbed browsing UI worse ( :-P ), the search
> XML backend and manager thingy, improved feed discovery, performance and
> extension support... That's nothing. Even Places isn't very much, if
> you're only thinking about the frontend as most users will. Users are
> going to be extremely disappointed when they see nothing new or
> interesting.
>
> mozilla.feedback has "I don't see any big differences" repeated
> frequently over 2.0a1, and it had Places. From your post, Firefox 2.0
> sounds like it should be called Firefox 1.6.
Wait, are session restore and the in-line spell checking still going to
be in 2.0?
If they are, I'll be okay with 1.7, but still not 2.0. They aren't an
immediate "Wow!" when you open the browser.
(And yes, I know I'm being harsh, and even small improvements are a good
thing and can take a good amount of work, but Firefox 2.0 just doesn't
seem like a 2.0.)
Matt Nordhoff
> Wait, are session restore and the in-line spell checking still going to
> be in 2.0?
>
> If they are, I'll be okay with 1.7, but still not 2.0. They aren't an
> immediate "Wow!" when you open the browser.
>
> (And yes, I know I'm being harsh, and even small improvements are a good
> thing and can take a good amount of work, but Firefox 2.0 just doesn't
> seem like a 2.0.)
Okay, I retract my nastiness, but I still think that without Places,
Firefox 2.0 is somewhat disappointing. But then, most of the other
things don't really matter to me. Well, security and performance and
extension support do, but I don't have problems with them (except the
slowness of my huge amounts of bookmarks and history).
The session restore feature, I already use Session Manager and will
continue to, because the extension can be updated without the review
process and I can easily get those updates without having to download a
new build of Firefox.
The search stuff is nice, too. Using the XML format reduces the number
of files I have in searchplugins by half, and the format looks nicer
than the old one. (And importing them will make all the indentation and
stuff identical in each one. :-) )
And Places, well, at least it will be interesting. I'm back down to the
mozilla1.8.0 branch because I want to avoid it until it's fully working
and I've sorted out my duplicate bookmarks because Places'll screw 'em
up, but once I do that and have an hour or two where I can live without
being able to use Firefox while everything is imported, I'm game.
Meh. Whatever. I'm rambling more, but at least I'm being nicer. ;-)
Firefox 2.0 isn't seeming incredibly interesting, though.
steve....@gmail.com
get realised, but atm there's too many bugs filed against it in order
to give end users a highly polished experience for 2.0.
2.0 will still have a bunch of improvements, including:
* Visual Refresh
* Safebrowser anti-phising
* Inline spellcheck
* Session Management
* RSS handling improvements
* Extension/Themes UI change
* New search engine infrastructure and UI
* New installer
* Browser performance metric measurer
which is quite a few, and most of them something the end-user will be
able to see with their own eyes. Some ppl might say this isn't enough
to be worth calling it a 2.0 release, but for me it is, and a 2.0
release doesn't have to be a much-trumpeted affair.
schiller
> a 2.0 release doesn't have to be a much-trumpeted affair.
What if you want to stack your browser advances up against the other
next-generation browsers soon to be released: IE7 and Opera9?
I don't know, going up a rev number is usually a big deal. I guess if
you put all total advances from 1.0 -> 2.0 it is a big deal. So now I
see why edging the release number from 1.1 to 1.5 last year was a wise
choice, because the step to 2.0 is not exactly earth-shattering. Only
problem is, it's been so long since I used Firefox 1.0 that I kind of
forget the advances that Firefox 1.5 brought.
Anyway, it's not like people are not going to upgrade (especially with
the auto-upgrade functionality in 1.5)... there will just be less of a
fuss in the blogosphere (and prepare yourselves for a few
"disappointed" reviews). Heck, Firefox 1.5 still beats IE7, from what
I've heard...
Hey, maybe they can get those recently checked-in SVG performance
improvements into 2.0...;)
Doron Rosenberg
worth it for extension authors to have it, even if the main product
doesn't use it.
Doron
Vladimir Vukicevic
available to extension authors. This should give a much nicer
alternative to RDF/XML for data storage.
Benjamin Smedberg
How was that decided? Part of the codesize tradeoff for sqlite was the
removal of the full mork engine. Shipping both sounds like a silly idea
since the app won't be using sqlite at all (unless there are other
dependencies that I've missed).
--BDS
Myk Melez
> Thus, we are going to disable Places on the 1.8 branch and continue work
> on the feature on the trunk for inclusion on a future release.
Out of curiosity, how was this decision made? I would have thought
there would have been some discussion about it in this newsgroup and the
weekly meetings, but I don't recall any such discussion taking place.
-myk
Mike Connor
platform. There's also the strong possibility that we'll be supporting
a subset of the WHATWG local storage spec in Gecko 1.8.1, based on sqlite.
-- Mike
Benjamin Smedberg
Who is doing that work?
I am wary of shipping complex platform-level features that do not get
widespread "natural" testing, and have not received (IMO) sufficient
targeted testing in the field. The SQLite performance issues that were
turned up by the places work amplified my initial worry several times over.
Since we are certainly not going to be freezing the storage interfaces for
this cycle, I am very wary of shipping them or encouranging developers to
use them.
There are outstanding unresolved issues about how we plan to version the
SQLite data structures over time within profiles (most of which are
admittedly app-level issues, not platform-level issues), as well as
questions about whether and to what extent we should be supporting
multi-process access to the data. Unless there is a Firefox 2 feature that
requires the storage APIs, I do not think that "a stronger platform" is a
good reason to ship this code.
--BDS
schiller
Mike Connor wrote:
> There's also the strong possibility that we'll be supporting
> a subset of the WHATWG local storage spec in Gecko 1.8.1, based on sqlite.
>
Weird, I hadn't heard that this would be a possibility on any of the
planning meetings summaries or in the Firefox 2 Requirements wiki page.
What priority was that? In fact, seems that almost all the Places
stuff was P1 (i.e. Mandatory) and the Release Criteria states "all P1
product requirements are complete"...
Brett Wilson
some of the APIs around and make some things safer. If it's shipping in
2.0, I need to make this a priority. Otherwise, it will stay on the back
burner.
> I am wary of shipping complex platform-level features that do not get
> widespread "natural" testing, and have not received (IMO) sufficient
> targeted testing in the field. The SQLite performance issues that were
> turned up by the places work amplified my initial worry several times
> over.
I would come to exactly the opposite conclusion you have. Places
performs fine now, in some ways better than Mork. Any system requires
tuning to perform well. The previous history system no doubt had a lot
of performance work done on it to make it fast, and sqlite is no
different. I don't see this as a warning sign at all. (Perhaps some of
this feeling is a result of the early impression that was floating
around that sqlite would solve all our problems, which is clearly not
true.) We have produced a system that has been tested it to perform well
under constant use while you browse.
> There are outstanding unresolved issues about how we plan to version the
> SQLite data structures over time within profiles (most of which are
> admittedly app-level issues, not platform-level issues),
I would also like to see this discussion take place. At least we need a
plan, even if we don't actually do anything.
> as well as
> questions about whether and to what extent we should be supporting
> multi-process access to the data.
The decision is that we don't support this. Supporting it would kill a
lot of the performance. Maybe this decision wasn't made explicitly, but
it will take a lot of work that hasn't been planned and would give a
measurable performance hit no matter what, so I think the decision has
been made implicitly.
Brett
Mike Shaver
> Mike Connor wrote:
> > I'm less concerned with codesize than with shipping a stronger
> > platform. There's also the strong possibility that we'll be supporting
> > a subset of the WHATWG local storage spec in Gecko 1.8.1, based on sqlite.
>
> Who is doing that work?
jst and Neil Deakin, it's already underway. (See recent content team
minutes for more details, I expect.)
> I am wary of shipping complex platform-level features that do not get
> widespread "natural" testing, and have not received (IMO) sufficient
> targeted testing in the field. The SQLite performance issues that were
> turned up by the places work amplified my initial worry several times over.
> Since we are certainly not going to be freezing the storage interfaces for
> this cycle, I am very wary of shipping them or encouranging developers to
> use them.
Developers have been using the storage APIs for a long time now; since
the end of 2004 in calendar-land, and quite intensively with Places
since. That testing is what led to the revisions in the APIs and also
the commissioning of the sqlite performance work (which preserved API
compatibility at the mozStorage level, I believe).
sqlite itself has been tested quite extensively -- the rest of our
platform should be so lucky! -- so the only other element here is our
wrapping of it in the mozStorage APIs. Those APIs have had pretty
good testing proportionate to their scope, IMO.
I do not at all agree with the idea of not shipping things until
they're frozen. We have a terrible record of "predictive" API design,
and not many groups have good ones.
> There are outstanding unresolved issues about how we plan to version the
> SQLite data structures over time within profiles (most of which are
> admittedly app-level issues, not platform-level issues),
They are app-level issues, and I don't think that "best practices"
here are going to emerge until after people try various different
approaches to it in the wild, in extensions, on top of our storage
interfaces.
> as well as
> questions about whether and to what extent we should be supporting
> multi-process access to the data.
"should be supporting" isn't as interesting as "will support", and for
Fx2 our answer will likely be "don't" or "at your own peril;
synchronize out of band".
Mike
Brendan Eich
- Angst about Firefox 2 lacking a reason to exist without Places,
especially vis a vis IE7, is misplaced, if you will pardon the pun.
There are tons of good reasons to do a strong Firefox 2 upgrade to 1.5
this year, well before IE7 comes out -- some of these have already been
listed in this thread by others.
- Local storage based on the http://www.whatwg.org/ proposal should be
in Firefox 2. It wasn't planned early, but it looks like it will fit
easily, and the reward is big while Firefox can differentiate itself
against IE6. Again, Firefox 2 has a place in the stream of releases we
will make over the next few years in order to compete and to advance the
state of the open web. Making Firefox 2 all about Places is a mistake.
- There are other platform pieces being uplifted into Firefox 2, about
which shaver has led the planning. I'll let him jump in here.
While we should not be over-focused on IE7, the idea of sandwiching IE7
between continuously improving Firefox releases still wins over trying
to do one "big-bang", "matching" release.
More than any competitive strategy, it is vitally important that we
continuously improve the product and the platform soon and regularly.
Right now Firefox has >50% usage on "web 2.0"-ish sites. That market
share is pure leverage, which we should use to (a) keep improving user
and content author experiences; (b) keep the competition on *their* toes
-- which we are doing!
Avoiding all-or-nothing thinking, and big-bang mythical-man-month
last-minute-fix moves, are also Good Things (tm). Taking the time
needed to get Places right, adjusting the Firefox 2 bill of materials,
keeping on schedule, all shows mature judgment and realism. Huzzah to
all that -- we need more of it.
/be
Benjamin Smedberg
> I do not at all agree with the idea of not shipping things until
> they're frozen. We have a terrible record of "predictive" API design,
> and not many groups have good ones.
I didn't say that... I said "shipping things that we're not also going to
use internally". There is a much higher incentive to keep backwards
compatibility or provide compatibility workarounds as the code matures if we
are using the code internally and it's "our problem".
> "should be supporting" isn't as interesting as "will support", and for
> Fx2 our answer will likely be "don't" or "at your own peril;
> synchronize out of band".
Sure, and expediency is a fine plan if you actually are planning on using
the feature, which was the general agreement six months ago when we decided
that we didn't have time to think about multi-process SQLite access for FF2.
But (modulo local-storage APIs) we don't have to bite that bullet, which
gives us the extra 3-6 months before FF3 closes to see if we can come up
with a good sharing solution before we're committed to a file format,
locking pattern, and API.
--BDS
Mike Shaver
>
> Mike Connor wrote:
> > There's also the strong possibility that we'll be supporting
> > a subset of the WHATWG local storage spec in Gecko 1.8.1, based on sqlite.
>
> Weird, I hadn't heard that this would be a possibility on any of the
> planning meetings summaries or in the Firefox 2 Requirements wiki page.
http://wiki.mozilla.org/Firefox2/StatusMeetings/2006-04-04#Infrastructure:_Platform_Uplift
mentioned it, and
http://wiki.mozilla.org/Firefox2/StatusMeetings/2006-04-11#Infrastructure:_Platform_Uplift
as well, plus the content meeting minutes from
http://groups.google.com/group/mozilla.dev.platform/browse_frm/thread/bc6c8b5485141c97/cc7931a1cef8c2ac#cc7931a1cef8c2ac
> What priority was that?
It hasn't had an explicit priority set, we're still in the
"investigative initial development" stage. Is that important?
> In fact, seems that almost all the Places
> stuff was P1 (i.e. Mandatory) and the Release Criteria states "all P1
> product requirements are complete"...
So? Are you trying to say that we are in violation of some contract?
Many items have had their priorities adjusted as we learned more about
them or considered the tradeoffs further, as is the case for virtually
every piece of software I've ever worked on.
If you're just pointing out that the priorities changed, and that what
we once thought was going to be central to Firefox 2 is no longer
something we're comfortable holding the release for, then you're just
repeating what Schrep posted to start this thread.
It would be helpful, possibly, for you to finish the sentence, since I
don't think the ellipsis is clear enough to make your point plain.
(It's not to me, at least.)
If you have input on the prioritization of Fx2 elements, please do
join us on the weekly call tomorrow to share it, or add it to the
agenda page beforehand.
Mike
L. David Baron
> Thus, we are going to disable Places on the 1.8 branch and continue work
> on the feature on the trunk for inclusion on a future release. This is
So, what's going to happen to the portion of our testing community that
has migrated their primary profiles to places-based storage? Will they
just lose all the changes they've made to their bookmarks since the
switch to places? When we switch back to places, will they lose all the
changes they make from now until then?
We don't want to make things too painful for our bleeding-edge testers
or pretty soon we won't have any.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
Mike Connor
> Mike Connor wrote:
>
>> There's also the strong possibility that we'll be supporting
>> a subset of the WHATWG local storage spec in Gecko 1.8.1, based on sqlite.
>>
>>
>
> Weird, I hadn't heard that this would be a possibility on any of the
> planning meetings summaries or in the Firefox 2 Requirements wiki page.
>
Gecko 1.8.1 features are separately tracked from the Firefox 2 app
planning. It is not a requirement from the application end, other than
the generic item for Gecko 1.8.1 uplift and improvements.
> What priority was that? In fact, seems that almost all the Places
> stuff was P1 (i.e. Mandatory) and the Release Criteria states "all P1
> product requirements are complete"...
>
Well, the conversation around that was "if we're doing Places in this
release, we need all of these things for it to be done" which is why
they were all P1s. If something turns out to be too risky, in terms of
stability and/or schedule impact, we need to reassess things. The
requirements will evolve and change for any release based on what is
possible and what is not, at that point in time. Features and their
importance are relative to release dates, and we based the feature list
around a Q3 release. With a possible slip until next year to get Places
up to the right level of quality in Fx2, and a planned Q1 release for
Firefox 3, moving the feature to Firefox 3 isn't a big change in when
the feature should get to market, it just means others will get there
earlier.
-- Mike
Darin Fisher
> On Sunday 2006-04-23 22:00 -0700, Michael Schroepfer wrote:
> > on the feature on the trunk for inclusion on a future release. This is
>
> has migrated their primary profiles to places-based storage? Will they
> just lose all the changes they've made to their bookmarks since the
> switch to places? When we switch back to places, will they lose all the
> changes they make from now until then?
>
> We don't want to make things too painful for our bleeding-edge testers
> or pretty soon we won't have any.
If we do nothing, then they will "lose" any changes they made to their
bookmarks since running a places-enabled build. That may be a pill we
should swallow for simplicity sake. Going back to places, we can make
matters better by renaming the "history and bookmarks" sqlite file.
-Darin
Mike Connor
> On Sunday 2006-04-23 22:00 -0700, Michael Schroepfer wrote:
>
>> on the feature on the trunk for inclusion on a future release. This is
>>
>
> has migrated their primary profiles to places-based storage? Will they
> just lose all the changes they've made to their bookmarks since the
> switch to places? When we switch back to places, will they lose all the
> changes they make from now until then?
>
Given that there isn't an exporter, those recent bookmarks won't be
accessible in branch builds. If they're following the branch, they've
quite possibly had to nuke their sqlite file a couple times to make
stuff work right (I actually need to bite that bullet myself), so its
nothing really new.
Best case, someone could write an exporter soon, and they could run
that from a trunk build...
> We don't want to make things too painful for our bleeding-edge testers
> or pretty soon we won't have any.
>
Agreed in principle, but I'm not sure what you're saying we should do
here. Write a sqlite->html converter and ship that in the non-places
builds? There's only so much we can do here, its just going to suck for
some people, but they can always run a trunk build and recover that
bookmark, its not like the date is _gone_. They can at least drag the
bookmarks to Notepad or something and get the URLs.
-- Mike
Mike Shaver
> has migrated their primary profiles to places-based storage? Will they
> just lose all the changes they've made to their bookmarks since the
> switch to places? When we switch back to places, will they lose all the
> changes they make from now until then?
I believe the Places bookmark-export code has just landed, or is
reviewed and is ready to land, so that problem may be lessened.
Mike
(I could be totally wrong, though)
Chris Ilias
> I believe the Places bookmark-export code has just landed, or is
> reviewed and is ready to land, so that problem may be lessened.
>
> Mike
> (I could be totally wrong, though)
https://bugzilla.mozilla.org/show_bug.cgi?id=318057
https://bugzilla.mozilla.org/show_bug.cgi?id=327925
--
Chris Ilias
mozilla.test.multimedia moderator
Mozilla links <http://ilias.ca>
(Please do not email me tech support questions)
steve....@gmail.com
> reviewed and is ready to land, so that problem may be lessened.
>
> Mike
Yeah, it's landed on trunk and 2.0 branch:
https://bugzilla.mozilla.org/show_bug.cgi?id=318057 --
[Firefox:Places]-bookmarks.html exporter [All]
Brett Wilson
> Given that there isn't an exporter, those recent bookmarks won't be
> accessible in branch builds. If they're following the branch, they've
> quite possibly had to nuke their sqlite file a couple times to make
> stuff work right (I actually need to bite that bullet myself), so its
> nothing really new. Best case, someone could write an exporter soon, and
> they could run that from a trunk build...
I checked in the bookmarks exporter today. It's in the File menu in the
places organizer window.
Brett
Brett Wilson
> I checked in the bookmarks exporter today. It's in the File menu in the
> places organizer window.
My bad. Apparently 1.5 doesn't like the format. Filed as:
https://bugzilla.mozilla.org/show_bug.cgi?id=335308
Brett
Brett Wilson
OK, exported files should be readable by 1.5 now.
Brett
schiller
Mike Shaver wrote:
> http://wiki.mozilla.org/Firefox2/StatusMeetings/2006-04-04#Infrastructure:_Platform_Uplift
> mentioned it
Thanks, Mike. I missed that. Sometimes that low-hanging fruit is
where it's at. Plus, I think web developers love getting surprises
like this...
> > What priority was that?
>
> It hasn't had an explicit priority set, we're still in the
> "investigative initial development" stage. Is that important?
I'm not doing the planning or the development, I'm just an observer
asking a question. It seems that in order to pursue something new that
you'd want to attach a priority to it. It would only be of minor
importance to me if it was lower priority work being pursued instead of
higher priority work (but no one has stated this).
>
> > In fact, seems that almost all the Places
> > stuff was P1 (i.e. Mandatory) and the Release Criteria states "all P1
> > product requirements are complete"...
My ellipsis is dangling, it's true ;) If the criteria is that all P1s
are to be complete, then either Places is being de-prioritized or the
release criteria is changing (otherwise you'd push back Firefox 2.0).
As you state, the answer is it's being de-prioritized because of its
complexity, so i appreciate your clarification, which may have been
obvious to you, just not to me. Everything else P1 is still a lock for
Firefox 2.0.
>
> So? Are you trying to say that we are in violation of some contract?
> Many items have had their priorities adjusted as we learned more about
> them or considered the tradeoffs further, as is the case for virtually
> every piece of software I've ever worked on.
Of course priority adjustments will happen. Every piece of software
I've worked on has also suffered the same fate. The best laid plans of
mice and men... (woops there's that ellipsis again)
All in all, please don't get defensive. I enjoy the open-source, open
planning nature of Mozilla and I appreciate the "fly-on-the-wall"
opportunity. When the flies start to get loud, bring out the
flyswatter. ;)
Regards,
Jeff
Brendan Eich
> Sure, and expediency is a fine plan if you actually are planning on
> using the feature, which was the general agreement six months ago when
> we decided that we didn't have time to think about multi-process SQLite
> access for FF2. But (modulo local-storage APIs) we don't have to bite
> that bullet, which gives us the extra 3-6 months before FF3 closes to
> see if we can come up with a good sharing solution before we're
> committed to a file format, locking pattern, and API.
You know, like: worse is better, and stuff.
Seriously, we do not gain by such ambitious designing in advance of use
cases. Firefox 2 does not need to support MP access to any sqlite db
used for local web app storage, and I doubt we ever will want that. It
costs a lot.
But whatever the case down the road, getting local storage surfaced in
Firefox 2, rather than holding it for 3 in the hope (how, exactly?) of
making MP access cheap enough, and correct to boot, is "better is
better" thinking. It's overkill that underserves (underserving to zero)
by delaying, and delay is the best form of denial.
If we can get single-process sqlite in Firefox 2, then rev the APIs for
3 based on more substantive feedback from extension authors than we
would get from alpha-3 releases, then I think everyone wins.
/be
edh...@gmail.com
be a way for us nightly testers to enable it?
Being able to do this from a zip build would be nice, since I share
this computer with someone who needs a plain-vanilla version for work.
Mike Beltzner
> Out of curiosity, how was this decision made? I would have thought
> there would have been some discussion about it in this newsgroup and the
> weekly meetings, but I don't recall any such discussion taking place.
Excellent question, Myk. I'm sure that we'll go over it in the meeting
tomorrow, but late last week, mconnor and ben started to look over the
buglist for Places while doing their SWAGs and began to realize that
in order to implement the feature properly, they were really going to
need more time. So they took a good hard look at what sort of delay
they would need, and what the pros and cons would be of pulling it,
and then came to the decision in consultation with engineering and
product leads at MoCo that it would be best to de-prioritize and pull
it from the branch.
And that's where we're at, and that's what we'll be talking about at
tomorrow's meeting. We all want what's best for the product, and it's
become clear that to get Places to a point where it's kick-ass enough
to be part of Firefox, we need more time than the Fx2 schedule allows.
It's a lot of work, and I for one am glad that the decision came down
to quality and looking out for the user.
cheers,
mike
(ps: I hope that this also gets us talking about how to plan and scope
releases better, but that conversation would most profitably done
*after* tomorrow's meeting, I think ;)
--
/ mike beltzner / user experience lead / mozilla corporation /
Mike Beltzner
> When 2.0a1/a2 builds start showing up with Places disabled, would there
> be a way for us nightly testers to enable it?
The best thing to do would be to run Minefield (trunk) and point it at
a different profile (you can just make a new profile, copy the entire
contents of your old profile into it, and presto, instant migration).
As I understand it, the team will no longer be landing Places patches
on the branch, so if you want to stay up to date with developments,
you'll need to be running the trunk code.
If you really want to re-enable it on your branch builds,
ac_add_options --enable-places might still work. Dunno. bsmedberg?
> Being able to do this from a zip build would be nice, since I share
> this computer with someone who needs a plain-vanilla version for work.
Minefield will install into a different directory, so you should be
able to share pretty sucessfully. Just change your shortcut (assuming
Windows) to point to ".../firefox.exe -P <newProfileName>" to get the
places-enabled profile.
cheers,
mike
Vladimir Vukicevic
> Sure, and expediency is a fine plan if you actually are planning on using
> the feature, which was the general agreement six months ago when we decided
> that we didn't have time to think about multi-process SQLite access for FF2.
> But (modulo local-storage APIs) we don't have to bite that bullet, which
> gives us the extra 3-6 months before FF3 closes to see if we can come up
> with a good sharing solution before we're committed to a file format,
> locking pattern, and API.
I don't see how this is relevant; without Places, we're not placing any
profile data into storage. Extensions will be able to create and use
their own databases, and nothing more; multi-process sqlite access
(directly, through sqlite) does not affect them. Any schemes for
multi-process database access will be another layer on top (e.g.
various token-passing schemes that were discussed a while back); any
multi-process locking will be part of this system. The APIs will also
only be exposed to extension and platform app authors, not to general
web content; so even given a drastic need to make an incompatible API
change, it won't have been the first time we've needed to do that.
Giving extension and app authors an alternative to RDF/XML (mork isn't
accessible from JS) for structured data storage is a huge
platform-level win, IMO.
(We should probably move this discussion for another thread, since it
doesn't directly relate to Places.)
- Vlad
Axel Hecht
Myk, does this impact microsummaries, too?
Axel
Jonas Sicking
> On 4/24/06, Myk Melez <m...@mozilla.org> wrote:
>> Out of curiosity, how was this decision made? I would have thought
>> there would have been some discussion about it in this newsgroup and the
>> weekly meetings, but I don't recall any such discussion taking place.
>
> Excellent question, Myk. I'm sure that we'll go over it in the meeting
> tomorrow, but late last week, mconnor and ben started to look over the
> buglist for Places while doing their SWAGs and began to realize that
> in order to implement the feature properly, they were really going to
> need more time. So they took a good hard look at what sort of delay
> they would need, and what the pros and cons would be of pulling it,
> and then came to the decision in consultation with engineering and
> product leads at MoCo that it would be best to de-prioritize and pull
> it from the branch.
>
> And that's where we're at, and that's what we'll be talking about at
> tomorrow's meeting. We all want what's best for the product, and it's
> become clear that to get Places to a point where it's kick-ass enough
> to be part of Firefox, we need more time than the Fx2 schedule allows.
> It's a lot of work, and I for one am glad that the decision came down
> to quality and looking out for the user.
Honestly, I am actually impressed with how this was handled. The people
responsible for this feature took the hard decision that the feature
won't be ready by the time it needs to in order to get into the next
release. That decision doesn't need to involve everyone, just the people
responsible for writing the code or the people responsible for the release.
Of course, if we don't agree with the decision we could try to get it
changed, but I haven't heard a lot of that.
/ Jonas
Myk Melez
> We all want what's best for the product, and it's
> become clear that to get Places to a point where it's kick-ass enough
> to be part of Firefox, we need more time than the Fx2 schedule allows.
> It's a lot of work, and I for one am glad that the decision came down
> to quality and looking out for the user.
Sure, I understand the reasoning, and I want the same good things for
Firefox. I was only perplexed by the lack of public discussion about
the issue in advance of a decision, especially given the productive
public discussions about these kinds of issues that we've been having in
this newsgroup and at the weekly meetings over the last few months.
-myk
Myk Melez
> Myk, does this impact microsummaries, too?
The microsummaries service stores data in annotations, and bookmark
views need to be modified to support them, so switching back to the old
system on the branch does affect microsummaries.
I looked at what it would take to get microsummaries working on the old
bookmarks code, and it looks doable (storing the data in RDF properties
instead of annotations, and making the old personal toolbar view support
microsummaries).
I suspect I can even write a single patch that works with both places
and the old code. But it makes landing before a2 more uncertain. I'll
see what I can do.
-myk
hold...@gmail.com
IE7, but I think a substatial release is more important than a "Hey!
We're still working!" one. I think you'll get reemed by the press for
not putting out what you promised.
nrth...@gmail.com
> I don't see how this is relevant; without Places, we're not placing any
> profile data into storage. Extensions will be able to create and use
>
> <snip>
>
> - Vlad
Isn't form data in formhistory.sqlite now ?
Brad Fults
This will be one of the most underwhelming 2.0 releases in recent
software history from a consumer's point of view.
I would much rather wait another 6 months or a year for a worthy 2.0
than see 1.6 shipped as "2.0" when it introduces no new large features
at all. This is the old religious argument about version numbers, but
most software vendors (and I) agree that a major version increment
means *at least* large new features, if not huge changes that break
backwards compatibility (e.g. 1.9 trunk).
schiller
Brad Fults wrote:
> This will be one of the most underwhelming 2.0 releases in recent
> software history from a consumer's point of view.
>
> I would much rather wait another 6 months or a year for a worthy 2.0
> than see 1.6 shipped as "2.0" when it introduces no new large features
The problem with this is the pain that will exist in having three
separate load lines, 1.8, 1.8.1 and the trunk. A 6-month delay in 2.0
would question why do the 1.8.1 branch at all, just release the trunk
when it's ready next year...
No, after thinking about it my vote is for sticking to the plan and
releasing something of high quality this year. A high quality visual
refresh will go along way with some people. Changes to feed and theme
management will also be something to talk about.
Anyway, the sooner developers focus on the trunk, the better.
Robert Sayre
>
> Sure, I understand the reasoning, and I want the same good things for
> Firefox. I was only perplexed by the lack of public discussion about
> the issue in advance of a decision, especially given the productive
> public discussions about these kinds of issues that we've been having in
> this newsgroup and at the weekly meetings over the last few months.
I've found group decision-making to be a lot less productive than group
design and issue tracking. Sorry if this comes off snarky, but if the
product leads feel a feature should be postponed, I don't think they
need to waste everyone's time pretending to include the entire Internet
in the decision. I'm happy to get advance notice and decision reports.
-Rob
Myk Melez
> I've found group decision-making to be a lot less productive than group
> design and issue tracking.
I'm not suggesting we make decisions as a group, only that we discuss
the issues as a group before the product leads make the decisions.
-myk
Boris Zbarsky
> Thus, we are going to disable Places on the 1.8 branch and continue work
> on the feature on the trunk for inclusion on a future release.
Are there extant places bugs that would block a trunk alpha? It would be good
to identify them so that we can get them fixed in the next month or so...
-Boris
Axel Hecht
I think a posting like "the heads of Firefox intend to propose pulling
places on the next meeting on tuesday for ... reasons" would have been
the same thing in terms of workload, without sounding so obscure.
But, as I said, it'd be the same thing, so why worry now.
Axel
Brett Wilson
That's places only. We can turn that on or off independent of places,
however, and it's relatively low risk. But becuase it offers no visible
benefit, I don't think it would be worthwhile to turn on with any risk
at all.
We did that so we can get rid of Mork, which is the old database, to
free up space for strorage in the download.
Brett Wilson
Maybe, but I doubt we'll get around to retargeting everything until
after 2.0a2. I think it's in a pretty good state. It will be much better
than the 2.0a1 release we already did, and I'm not sure the trunk alpha
requires better quality than the last one.
Brett
Håkan Waara
codenames during the development phase, even until the late stages of
it, and then decide on a version number when you have something that is
really starting to materialize.
Right now, whether anyone wants it or not, there is a big hype about
2.0 this and 3.0 that. If the features for the "next release" would be
added "lazily" - in programming terms - then there would be a natural
pressure on developers to make their features stable and good-looking
enough for the upcoming release.
/Håkan
Brendan Eich
I don't buy it in this case, or in many others -- even if the group is
just "discussing".
First, there's a fair amount of potential individual and group
sensitivity inherent in any decision to defer a major feature, both on
the part of the people working on the feature, and on the part of the
people managing the release. That may involve some amount of
negotiation, persuasion, etc. (perhaps not all seven stages of grief,
let's hope ;-). That is not best done in public.
Second, once that more sensitive and necessarily non-public decision
process has been "done" among the critical players, there is not much
point in going through the motions of soliciting public feedback as if
it would change the decision.
(At least not in this case. If the subject were a matter of great
unknowns or controversies about the facts before us, and it seemed
likely that newcomers or "outside" experts could shed light and resolve
a vexing dilemma, then maybe. Such a scenario is not credible in this
case, or in many like it that come to mind. There's no way around the
Mythical Man Month.)
Third, the peers with standing to discuss and debate in advance of a
decision being "virtually made" are generally the people included in the
less-than-public talk, in this case and most others. I do not believe
someone was left out. I do not believe that some valuable newcomer --
whom I *do* believe exists in spades, don't get me wrong -- is thereby
"left out".
(OTOH, if *you* felt left out, that's different! It may have been wrong
not to include you. But I am not sure how the outcome would have been
different. That's probably cold comfort, and it may well not justify
leaving you out, of course.)
The bottom line is this: It is truly not "everyone's business" to
discuss every decision before it is made, if there is to be meaningful
ownership of modules, products, and releases.
Let me repeat that: ownership implies subsidiary authority to decide
things, sometimes with public discussion first, sometimes without -- and
it's usually up to the owners to dial in the right amount of public
pre-decision discussion.
I am not saying that all decisions should happen in non-public venues,
and then be announced as if from on high. But it does not follow that
all decisions must be discussed in public in advance of being "made",
either. Often a fait accompli is better than a false dialog, especially
if the outcome is over-determined. (Ben and others may disagree with my
opinion here.)
For one thing, and this has been true over and over in the history of
the Mozilla project, discussing almost every decision leads to a false
sense of entitlement, and to a pretense that the relevant owners and
leaders really have not decided what they have in fact already decided
to do.
(Examples that come to mind go back to the dawn of the project. Even
though drivers mishandled the appeal process, I would cite the MNG
decision of the imglib owners as a good example of how decisions need
not *necessarily* be discussed in public before being made.)
Another point: I think I agree with Robert Sayre, that public design
tracking is more important than globally-public design discussions for
all the pieces of the system. As for "issue" (in the vogue sense of
"problem", as in "Houston, we have one" ;-)) tracking, that's even more
often best done without first publicly re-discussing the near-decision
already made by the principal owners. And that's what happened here, it
seems to me.
My 2+ cents.
/be
Brendan Eich
Who knows what the press will do? We can't control that, except by
delivering value to Firefox users, which should be our focus.
But what you propose is a recipe for being late, bloated *and* buggy.
Here's how it happens:
* We missed with a big feature (but not the only valuable feature!),
let's slip to give it more time.
* Let's put more people on it. Read Fred Brook's "The Mythical Man
Month" if you haven't.
* Wait, it's still not done, still not at Firefox 1.5 feature parity,
and we are slipping past IE7 -- we must have *other, whizzy* features to
compete!
* Repeat from the top.
This has been done over and over in the software industry ([1]). It's
pure folly. Don't propagate it.
/be
[1] One good writeup, from one of my past lives (and too often, such a
post mortem is simply not done, or if done is hidden behind a firewall):
http://yarchive.net/risks/sgi_irix.html
Myk Melez
> First, there's a fair amount of potential individual and group
> sensitivity inherent in any decision to defer a major feature, both on
> the part of the people working on the feature, and on the part of the
> people managing the release. That may involve some amount of
> negotiation, persuasion, etc. (perhaps not all seven stages of grief,
> let's hope ;-). That is not best done in public.
Sure, but there's no reason for this part of the discussion to be the
entire conversation. We could still bring the issue into public forums
once the sensitive private conversations have taken place.
> Second, once that more sensitive and necessarily non-public decision
> process has been "done" among the critical players, there is not much
> point in going through the motions of soliciting public feedback as if
> it would change the decision.
Sure, if we're really just going through the motions without actually
caring about the response. But I'm wary of us assuming our plans won't
benefit from community input. I think we should assume they will,
unless we have very good reason to believe otherwise, and take responses
seriously.
> Third, the peers with standing to discuss and debate in advance of a
> decision being "virtually made" are generally the people included in the
> less-than-public talk, in this case and most others. I do not believe
> someone was left out. I do not believe that some valuable newcomer --
> whom I *do* believe exists in spades, don't get me wrong -- is thereby
> "left out".
If there are spades of valuable newcomers, then I think we will benefit
from including them in the discussion, even once a decision is
"virtually made," and even if we're making the right decision. At the
very least, we'll get additional reinforcement that we're doing the
right thing, and community members will have a chance to distinguish
themselves with useful feedback.
> (OTOH, if *you* felt left out, that's different! It may have been wrong
> not to include you. But I am not sure how the outcome would have been
> different. That's probably cold comfort, and it may well not justify
> leaving you out, of course.)
I was left out, but that's not the issue (including me probably wouldn't
have changed anything, especially since I agree with the decision, and
it's unclear that I had anything to contribute in this case).
The issue is that this project has taken valuable strides in the last
few months to include the community in its planning process by
discussing significant planning issues in the newsgroups and the weekly
meetings, and we shouldn't regress those improvements by now making some
planning decisions completely in private without a very good reason for
doing so (which, as far as I can tell, is not the case here).
-myk
Mike Connor
> Brendan Eich wrote:
>
>> First, there's a fair amount of potential individual and group
>> sensitivity inherent in any decision to defer a major feature, both
>> on the part of the people working on the feature, and on the part of
>> the people managing the release. That may involve some amount of
>> negotiation, persuasion, etc. (perhaps not all seven stages of grief,
>> let's hope ;-). That is not best done in public.
>
> Sure, but there's no reason for this part of the discussion to be the
> entire conversation. We could still bring the issue into public
> forums once the sensitive private conversations have taken place.
>
If the people working on the feature and the people managing the release
agree that the feature isn't going to make it, I'm not sure what
discussion would be productive here. The only possible question is
whether to delay the release until the feature is ready, but that's a
trap, as Brendan has pointed out repeatedly (and I will join him in
seeking to avoid that trap). If there's a benefit from adding another
feedback cycle (that offsets the cost of the delay in moving on the
decision), great, but I don't see a case where one exists here.
> The issue is that this project has taken valuable strides in the last
> few months to include the community in its planning process by
> discussing significant planning issues in the newsgroups and the
> weekly meetings, and we shouldn't regress those improvements by now
> making some planning decisions completely in private without a very
> good reason for doing so (which, as far as I can tell, is not the case
> here).
I believe people not directly involved in managing the release or
developing a feature will not have a lot of relevant insight into
whether a feature is going to miss a release. If it is going to miss
the release, the community can't change the outcome (c.f. The Mythical
Man-Month) and can only agitate for delaying the release. If we are
committed to shipping regular releases without gating on any single
feature, then the outcome will not change, so what does a discussion
with a predetermined outcome do, other than possibly make the situation
worse by invoking essentially pointless discussion?
Getting feedback on general plans/priorities/design is positive and we
need to continue to do that. And we will continue to bring people into
the folds of the ownership model as they develop into the roles. As
Brendan indicated, if a decision will benefit from public feedback
before it is made, we need to make sure that feedback is sought, but
that will not always be the case. We need to avoid dogmatic principles
around openness, and take the highest-value path wherever possible.
-- Mike
nrth...@gmail.com
> > Isn't form data in formhistory.sqlite now ?
>
> That's places only. We can turn that on or off independent of places,
> however, and it's relatively low risk. But becuase it offers no visible
> benefit, I don't think it would be worthwhile to turn on with any risk
> at all.
>
> We did that so we can get rid of Mork, which is the old database, to
> free up space for strorage in the download.
So testers will end up with an export option for bookmarks, but not
history or form data. I guess I can live with that, but the loss of
history is a pain.
Brendan Eich
> The issue is that this project has taken valuable strides in the last
> few months to include the community in its planning process by
> discussing significant planning issues in the newsgroups and the weekly
> meetings, and we shouldn't regress those improvements by now making some
> planning decisions completely in private without a very good reason for
> doing so (which, as far as I can tell, is not the case here).
I don't buy it, and I gave my reasons. You seem to put more value in a
rote "discussion" after a decision has actually been made than I do.
I also don't believe that it is always automatically "regressive" to
decide things among a quorum of owners and peers, and I gave reasons for
that opinion. The owners and peers are not everyone, and "everyone"
does not own the particular valuables in question. Everyone does not
need to see all the sausage-making details of decision-making to assent
to the value of ownership, or to support the particular owners, for
every decision.
A few bad decisions can call ownership into question, for sure. But
this was not an example of such a bad decision. And even several poor
decisions by themselves would not call much into question, if the
owner(s) took corrective actions when the decisions were questioned.
As Robert Sayre put it, ability to track decisions in the open matters
more than details of the decision making being open from the get-go.
That means the rationale must be clear, once the decision has been made.
That happened here.
Anyway, I've written enough on this. What do others think?
/be
Mike Beltzner
> I don't buy it, and I gave my reasons. You seem to put more value in a
> rote "discussion" after a decision has actually been made than I do.
I get the impression -- yet Myk should really speak for himself --
that the issue isn't as much with this particular instance, as opposed
to the idea that somewhere there are choices being made about what
issues are or are not discussed broadly before decisions are more or
less made.
My personal take on this is that we need that system for speed. There
are people who are active in the day to day management of this
particular release, and they have, in my opinion, earned our trust and
should therefore have the discretion to determine who should be
involved in making this sort of decision. This is not to say that they
have carte blanche, and as Sayerer (and Brendan) point out, the very
fact that their decisions are made public and put out in fora like
this for comment shows that they are looking to involve the community
and take their lumps if the decision can be demonstrated to have been
the wrong one.
> does not own the particular valuables in question. Everyone does not
> need to see all the sausage-making details of decision-making to assent
> to the value of ownership, or to support the particular owners, for
> every decision.
Agreed wholeheartedly. To do otherwise would slow us down to a point
where we couldn't use our breadth and speed appropriately.
cheers,
mike
Axel Hecht
My impression is that few suggested an open discussion on pulling
places. Mike posted the decision on Sunday-Monday, there is a scheduled
conf call with 15-20 people that already did the prioritization work for
fx2 on every Tuesday. That groups has reliably worked on profound
proposals of feature owners in the past, giving usable feedback and
adjustments on some of it.
In this particular case, there was an established way between a sunday
coffee table and everbody's mother ranting.
The meeting did have the important discussion, like, what we could do
with those coders that were planned to drive places to a2 for a2.
Still, I'd prefer the post-mortem of this to include all readily
available options, which was one more than just owners or everybody.
Practical difference? Probably zilch, given that everybody on that
call/meeting knew for the past weeks that places approached borderline,
at least that is my perception.
Axel
Ben Goodger
> We need to avoid dogmatic principles around openness, and take the highest-value path wherever possible.
"Highest value path" is vague. Highest value in terms of what? Short
term convenience? Community growth? Technical superiority?
We have taken many of these "high value" paths before, many of them have
led us to good places, but not without some pretty significant cost.
-Ben
Ben Goodger
> We need to avoid dogmatic principles around openness, and take the highest-value path wherever possible.
"Highest value path" is vague. Highest value in terms of what? Short
Boris Zbarsky
> Maybe, but I doubt we'll get around to retargeting everything until
> after 2.0a2. I think it's in a pretty good state. It will be much better
> than the 2.0a1 release we already did, and I'm not sure the trunk alpha
> requires better quality than the last one.
Quite frankly I don't buy that, but that's because I actually want people to
test the trunk alpha. ;)
It's comments like http://mozillazine.org/talkback.html?article=8283#19 that
worry me. Maybe all the people testing trunk who're ok with things are just not
feeling a need to say anything, and maybe the issues are largely resolved at
this point. I'm not using Places-enabled builds for my daily browsing (and not
likely to be in the near future unless Places comes to Seamonkey), so it's a
little difficult for me to judge how actual usability of the builds is affected.
So who here _does_ use a Places build day-in and day-out? Are there any bugs in
it that would prevent widespread testing of Gecko 1.9a? Basically, anything
that would prevent a not-too-clueless user from using the browser for at least a
month?
If there are such bugs, please nominate them to block Gecko 1.9a1.
Thanks,
-Boris
Robert O'Callahan
> So who here _does_ use a Places build day-in and day-out?
Me.
> Are there any bugs in it that would prevent widespread testing of Gecko 1.9a?
> Basically, anything that would prevent a not-too-clueless user from
> using the browser for at least a month?
I don't think so. Bookmarks work. What else do you need?
Rob
Chris Hofmann
of weeks, and many of the problems I saw early seem to have been cleaned
up. Anyone switching back and forth between trunk and 1.5/2.0 branch
builds? We should figure out what shape migration back to non-places
builds will look like by 1.9a1. That might be the key to deciding.
chris h,
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
Boris Zbarsky
> I don't think so. Bookmarks work. What else do you need?
No idea. You tell me. ;)
-Boris
Brett Wilson
I have been using it for the past several weeks on branch as my main
browser. Now that we've dropped it from the branch, I'm back to 1.5
until I get a noplaces branch build out which I'll probably use.
Normal bookmarks and history basically work. The places window has
varied between decent and pretty broken on a nightly basis, and the add
bookmark dialog also varies. The brand new popup has lots of problems (I
think we may give up on it since Gecko really can't handle it).
Sometimes the toolbar has been broken (The main culprit seems to be
getting it to work with customization. I'm not sure about the current
state.) Certainly if you try to manage your bookmarks on many nightlies,
you may be disappointed.
I read these complaints about how it is unstable, not usable, etc. But
they seem to be always vague. I don't see this at all, and I wish these
people would file bugs if it is really so bad.
I suspect these people think places is the popup and the new places
window with problems as described above. I don't think they think about
all the backend stuff that is storing their history, coloring links
correctly, autocomplete, not deleting their bookmarks, etc. as places.
They extrapolate the varying frontend problems as indicative of the
whole system.
Brett
Boris Zbarsky
> Normal bookmarks and history basically work. The places window has
> varied between decent and pretty broken on a nightly basis, and the add
> bookmark dialog also varies.
Do we know why? Is this due to Gecko changes, or front-end changes? Are there
bugs covering this breakage?
> The brand new popup has lots of problems (I
> think we may give up on it since Gecko really can't handle it).
Are there bugs covering these problems? On trunk, "Gecko really can't handle
it" doesn't mean the same things it means on branch, of course. ;)
> Sometimes the toolbar has been broken (The main culprit seems to be
> getting it to work with customization. I'm not sure about the current
> state.)
Bug numbers?
> Certainly if you try to manage your bookmarks on many nightlies,
> you may be disappointed.
OK. Bugs in that would definitely be alpha blockers, in my opinion. Bug numbers?
> I read these complaints about how it is unstable, not usable, etc. But
> they seem to be always vague. I don't see this at all, and I wish these
> people would file bugs if it is really so bad.
I think we'd all prefer bugs were filed, yes... Perhaps we should make some
announcements to that effect in the relevant Mozillazine forums?
> I suspect these people think places is the popup and the new places
> window with problems as described above. I don't think they think about
> all the backend stuff that is storing their history, coloring links
> correctly, autocomplete, not deleting their bookmarks, etc. as places.
You're right. They don't. No one ever really thinks about the parts that they
don't see, until they break. ;)
> They extrapolate the varying frontend problems as indicative of the
> whole system.
The varying front-end problems are what users will see, though. If they
download the alpha and their first experience is "bookmarks don't really work --
I tried moving one from one folder to another and it lost the bookmark" or
whatever (you and I know things work in the vast majority of cases, but I'm
talking user perception here), they're not going to use the alpha. So issues
like that should be nominated as blocking to be evaluated, imo.
-Boris
Brett Wilson
> Brett Wilson wrote:
>> Normal bookmarks and history basically work. The places window has
>> varied between decent and pretty broken on a nightly basis, and the
>> add bookmark dialog also varies.
>
> Do we know why? Is this due to Gecko changes, or front-end changes?
> Are there bugs covering this breakage?
Almost all the bugs are frontend changes in the components. I think Joe
has the add bookmark dialog working pretty well. I think there are
pretty good filed bugs. The current empty toolbar bug is 334082.
>> The brand new popup has lots of problems (I think we may give up on it
>> since Gecko really can't handle it).
>
> Are there bugs covering these problems? On trunk, "Gecko really can't
> handle it" doesn't mean the same things it means on branch, of course. ;)
There are many bugs filed on the popup. The fundamental problem is that
you can't have a dependent popup window that can handle focus properly.
As a result the current window is a hacky dialog box (or something) that
causes many problems.
> OK. Bugs in that would definitely be alpha blockers, in my opinion.
> Bug numbers?
I don't see any now. These things have usually been short lived and have
been results of the frequent large changes.
I think we're a little vague on the current state of places because
development on places basically stopped 2 weeks ago and won't happen
again until after 2.0a2. I haven't really used it in that time.
Brett
Boris Zbarsky
> Almost all the bugs are frontend changes in the components. I think Joe
> has the add bookmark dialog working pretty well. I think there are
> pretty good filed bugs. The current empty toolbar bug is 334082.
Thanks!
> There are many bugs filed on the popup.
Bug numbers, please?
> The fundamental problem is that
> you can't have a dependent popup window that can handle focus properly.
What are the exact focus issues? Is there a bug filed on this?
> These things have usually been short lived and have
> been results of the frequent large changes.
OK, that's good to know. That would match up with the nightly testers
complaints, but doesn't promise particular problems for the alpha. ;)
> I think we're a little vague on the current state of places because
> development on places basically stopped 2 weeks ago and won't happen
> again until after 2.0a2. I haven't really used it in that time.
I see. What's the current time estimate for 2.0a2? How would restarting
development after that square with a Gecko alpha in early June? Is it possible
to at least do blocker triage before 2.0a2?
Also, I feel that we need to get bug triage of Gecko 1.9a blockers (including
places) largely done by at least a few weeks before the alpha, so hopefully by a
week or two from now. Which means we need to at least get any Places bugs that
might be blockers nominated in the next week or so.
-Boris
Mike Shaver
> bookmark dialog also varies. The brand new popup has lots of problems (I
> think we may give up on it since Gecko really can't handle it).
Are there bugs on file for the cases that Gecko make impossible or too
fragile? We should make sure there are, and that they're nominated as
blocking 1.9 (a2?), to take advantage of the fact that we'll be
shipping Places against a newer Gecko.
Mike
Brett Wilson
The main problem we have been having is a problem with keyboard input in
any type of <popup> or menu, etc. I just looked a bit and did not see a
bug on this, but I didn't look very hard. Maybe somebody more
experienced in this area can find one.
Brett
Boris Zbarsky
> The main problem we have been having is a problem with keyboard input in
> any type of <popup> or menu, etc.
You mean like typing text into a textfield in them or something?
-Boris
Brett Wilson
> Brett Wilson wrote:
>> Almost all the bugs are frontend changes in the components. I think
>> Joe has the add bookmark dialog working pretty well. I think there are
>> pretty good filed bugs. The current empty toolbar bug is 334082.
>
> Thanks!
>
>> There are many bugs filed on the popup.
>
> Bug numbers, please?
:) Like I said, the popup may go away, so I wouldn't worry about filing
blockers on it yet. There is a lot unimplemented in the popup which is
what many of the bugs are about.
>> The fundamental problem is that you can't have a dependent popup
>> window that can handle focus properly.
>
> What are the exact focus issues? Is there a bug filed on this?
I couldn't find one, but I didn't look very hard. You can't have a popup
that takes keyboard focus. If you put an edit box or something in any
type of popup it won't work. Menus only work because there is some
special-case code to handle menu keyboard navigation.
We've discusses this with a few people, and there has been reluctance to
touch it, apparently the popup focus thing is horrible :(
> I see. What's the current time estimate for 2.0a2?
This Friday, although it wouldn't surprise me if it slipped a few days.
Brett
Mike Shaver
> > Are there bugs on file for the cases that Gecko make impossible or too
> > fragile? We should make sure there are, and that they're nominated as
> > blocking 1.9 (a2?), to take advantage of the fact that we'll be
> > shipping Places against a newer Gecko.
>
> The main problem we have been having is a problem with keyboard input in
> any type of <popup> or menu, etc. I just looked a bit and did not see a
> bug on this, but I didn't look very hard. Maybe somebody more
> experienced in this area can find one.
Can you file one with some details (enough for someone to write a
testcase, if you don't have time to provide a minimal one yourself)?
If it's a dup, someone will repair that redundancy swiftly, I'm sure.
Mike
Neil Deakin
> Mike Shaver wrote:
> The main problem we have been having is a problem with keyboard input in
> any type of <popup> or menu, etc. I just looked a bit and did not see a
> bug on this, but I didn't look very hard. Maybe somebody more
> experienced in this area can find one.
>
> Brett
Popups attach their own capturing keyboard event listeners to
themselves. Is this the issue you are having?
Or are you trying to put something keyboard usable inside a menuitem?
/ Neil
Brett Wilson
OK, I filed bug 336159.
Brett Wilson
> Popups attach their own capturing keyboard event listeners to
> themselves. Is this the issue you are having?
That sounds like it might be it.
> Or are you trying to put something keyboard usable inside a menuitem?
Is this a separate issue? That would be cool as well (though a much
lower priority), I had some initial mock-ups (in Photoshop) that
required this.
Brett
Neil Deakin
> Neil Deakin wrote:
>> Popups attach their own capturing keyboard event listeners to
>> themselves. Is this the issue you are having?
>
> That sounds like it might be it.
>
<popup ignorekeys="true">
...
</popup>
which disables the default keyboard events.
You didn't say what kind of popup though. The code above should work for
those that are referenced by id with the popup attribute.
>> Or are you trying to put something keyboard usable inside a menuitem?
>
> Is this a separate issue? That would be cool as well (though a much
> lower priority), I had some initial mock-ups (in Photoshop) that
> required this.
Don't know if it's a separate issue. It isn't a bug that you can't do
that though. Could you post some details, or the mock-ups?
/ Neil
Michael Lefevre
>Brett Wilson wrote:
[snip]
>> I read these complaints about how it is unstable, not usable, etc. But
>> they seem to be always vague. I don't see this at all, and I wish these
>> people would file bugs if it is really so bad.
>
> I think we'd all prefer bugs were filed, yes... Perhaps we should make some
> announcements to that effect in the relevant Mozillazine forums?
If things are settled to the point where that is useful (I must admit I
haven't been following close in recent weeks), it might be a good idea to
request that.
I think what discourages people from filing (useful) bugs is when they
know there are already dozens of bugs on file (Peter W who tracks a bunch
of bugs in daily forum posts gave up on tracking places bugs when there
were around 30 places bugs hanging around...), and things are changing
quickly. People don't want to spend an hour diagnosing a bug, only to
find that in the next nightly, the thing they were reporting a bug with
has changed so that their bug report makes no sense, and the bug gets
marked invalid some time later when someone triages it.
Having said all that, there is no shortage of bugs on file, and I suspect
it's partly a matter of people describing things as really horrible when
Brett's view of the same bugs is that they aren't "really so bad". Peter W's
query for bugs in the component is:
https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Firefox&component=Places&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
Picking the recent major ones out of there would be a reasonable start
for triage...
https://bugzilla.mozilla.org/show_bug.cgi?id=335512 (Import Bookmarks from
file is broken)
https://bugzilla.mozilla.org/show_bug.cgi?id=334694 (After deleting
separator all bookmarks gone)
https://bugzilla.mozilla.org/show_bug.cgi?id=335062 (No way to move
bookmarks except drag/drop)
https://bugzilla.mozilla.org/show_bug.cgi?id=334437 (Crash and asserts
when clicking on context-menu items places history)
https://bugzilla.mozilla.org/show_bug.cgi?id=334082 (Bookmarks Toolbar empty)
https://bugzilla.mozilla.org/show_bug.cgi?id=334130 (Bookmarks | Organize
Bookmarks shows History in the Places window)
And the collection of bugs filed on the flaky popup dialog windows thing
are mostly marked in the summary:
https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=popup&product=Firefox&component=Places&&bug_status=NEW&bug_status=ASSIGNED
>> They extrapolate the varying frontend problems as indicative of the
>> whole system.
>
> The varying front-end problems are what users will see, though.
Indeed. To assess the overall state of development based on the UI may be
unfair. But in terms of whether a system is working or not, from a user
perspective if the UI is broken it doesn't really matter if the back-end
works or not, because you can't use it without the UI.
--
Michael
Brett Wilson
we can do ignore keys, which is a problem we used to have but figured out.
Annie will post soon to clarify things.
Brett
Annie Sullivan
>> There are many bugs filed on the popup.
>
> Bug numbers, please?
>
>> The fundamental problem is that you can't have a dependent popup
>> window that can handle focus properly.
>
> What are the exact focus issues? Is there a bug filed on this?
The big problem we have with the popup isn't focus (seems to work fine
if you set the ignorekeys attribute to true). It's that the popup is
supposed to have a menulist inside of it, and the menulist wasn't
working correctly inside the popup--the list would show up next to the
drop-down instead of inside it. I don't know of a bug on this.
We tried to work around this by making the popup a dependent window
instead of a real popup, but this caused tons of other
problems--titlebars sometimes show on the popup in linux, the popup
doesn't move with the parent window, etc. I think it would be better to
fix the menulist problem instead.
Boris Zbarsky
> The big problem we have with the popup isn't focus (seems to work fine
> if you set the ignorekeys attribute to true). It's that the popup is
> supposed to have a menulist inside of it, and the menulist wasn't
> working correctly inside the popup--the list would show up next to the
> drop-down instead of inside it. I don't know of a bug on this.
Please file one and attach a XUL testcase showing what you're doing that would
allow someone else to debug the problem and such.
> I think it would be better to fix the menulist problem instead.
Sure. But it's impossible to fix problems with no bugs filed on them. Unless
we have telepaths around? ;)
-Boris
Mike Shaver
> Sure. But it's impossible to fix problems with no bugs filed on them. Unless
> we have telepaths around? ;)
I knew you were going to say that.
Mike
vlad
the things that I care about all seem to work fine. Some things work
much better -- in particular, searching through history works really
well now, and is very fast. Even though I'm probably not a very heavy
bookmarks user, I wouldn't say that there are any problems with places
that would impede usability for a trunk alpha. You may have people
complaining that they don't /like/ the way something is done, but as
for actual breakage, I haven't seen anything in a while.
- Vlad
Brett Wilson
> Sure. But it's impossible to fix problems with no bugs filed on them.
> Unless we have telepaths around? ;)
I though I saw one, but all I found come up with are these:
https://bugzilla.mozilla.org/show_bug.cgi?id=304784
https://bugzilla.mozilla.org/show_bug.cgi?id=280373
I'm not positive these are the same.
Brett
Boris Zbarsky
> I though I saw one, but all I found come up with are these:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=304784
> https://bugzilla.mozilla.org/show_bug.cgi?id=280373
>
> I'm not positive these are the same.
If you're not sure, file a new bug. Worst-case, we'll have a duplicate. The
worst case the other way around is that we won't fix the bug...
-Boris
Brett Wilson
I filed bug 336179 from what my understanding of the bug is.
Brett
fantasai
> Myk Melez wrote:
>
>> The issue is that this project has taken valuable strides in the last
>> few months to include the community in its planning process by
>> discussing significant planning issues in the newsgroups and the
>> weekly meetings, and we shouldn't regress those improvements by now
>> making some planning decisions completely in private without a very
>> good reason for doing so (which, as far as I can tell, is not the case
>> here).
>
> I don't buy it, and I gave my reasons. You seem to put more value in a
> rote "discussion" after a decision has actually been made than I do.
> I also don't believe that it is always automatically "regressive" to
> decide things among a quorum of owners and peers, and I gave reasons for
...
> Anyway, I've written enough on this. What do others think?
I think a decision like this should not be worded like a press release
for posting *here*. Make a press release for Mozillazine, not for m.d.planning
> That means the rationale must be clear, once the decision has been made.
*This* is important. Not reassurances about how great Firefox is/will be.
The two are mixed up in schrep's posting, which makes for a garbled message
about the important part.
I think Myk's objection is less about owners and peers talking about a
feature and coming to a conclusion about it than it is how that conclusion
is communicated and interpreted. I suspect it would be more palatable to
everyone who was left out of the discussion if their decision were
communicated more like (to steal a few lines from Beltzner) this:
mconnor and ben started to look over the buglist for Places while doing
their SWAGs last week and began to realize that in order to implement
the feature properly, we were really going to need more time. We talked
with [A], [B] and other product leads at MoCo about the pros and cons
of pulling the feature, and decided we should disable Places on the
1.8 branch and continue work on the feature on the trunk for inclusion
on a future release. We all want what's best for the product, and it's
become clear that to get Places to a point where it's kick-ass enough to
be part of Firefox, we need more time than the Fx2 schedule allows. Making
this change early in the release cycle gives us the time to focus on
delivering an extremely high quality FF2 in Q3, and it gives Places the
room it needs to develop. We don't want to delay the release for Places
because... <etc rationale>
We'll be discussing this at the next Bon Echo meeting at 11am on Tuesday.
We'll also conduct a more in-depth review of status of every other feature
area to figure out what else is at risk and make sure we have all available
effort focused on the critical areas. So come prepared to talk about your
feature area and plan for a longer meeting than normal.
That could use a bit more polish maybe, but my point is
- It's a more personal message: it's targeted to fellow developers,
not to a massive audience of strangers.
- It explains who is making this decision and how it came about. This
doesn't put such a gulf between the people included in "we" and
everyone else, and it gives enough background to put the decision in
its proper context.
- The rationale is laid out without intervening marketspeak.
- It closes up with a statement about moving forward on this decision
that still leaves room open for further input from others--without
asking for a fake conversation.
~fantasai
fantasai
> On 4/24/06, Myk Melez <m...@mozilla.org> wrote:
>> Out of curiosity, how was this decision made? I would have thought
>> there would have been some discussion about it in this newsgroup and the
>> weekly meetings, but I don't recall any such discussion taking place.
>
> Excellent question, Myk. I'm sure that we'll go over it in the meeting
> tomorrow, but late last week, mconnor and ben started to look over the
> buglist for Places while doing their SWAGs and began to realize that
> in order to implement the feature properly, they were really going to
> need more time. So they took a good hard look at what sort of delay
> they would need, and what the pros and cons would be of pulling it,
> and then came to the decision in consultation with engineering and
> product leads at MoCo that it would be best to de-prioritize and pull
> it from the branch.
>
> And that's where we're at, and that's what we'll be talking about at
> tomorrow's meeting. We all want what's best for the product, and it's
> become clear that to get Places to a point where it's kick-ass enough
> to be part of Firefox, we need more time than the Fx2 schedule allows.
> to quality and looking out for the user.
Can I nominate you for spokesperson of such decisions? :)
You're much better at communicating these things, imho.
~fantasai
Robert O'Callahan
Perhaps if I was a hard-core Web-2.0 RSS-consuming man of the world, I
would encounter more problems. But at heart I'm actually a Luddite who
doesn't even use tabs.
Rob
Boris Zbarsky
> I filed bug 336179 from what my understanding of the bug is.
Thank you!
If someone (doesn't have to be Brett or anything) can attach a XUL testcase to
the bug, that would be great, by the way.
-Boris