hiding bookmarks from the awesomebar
Dietrich Ayala
some bookmarked URLs from showing up in the awesomebar:
Use a special tag to block results from the awesomebar:
https://bugzilla.mozilla.org/show_bug.cgi?id=450314
Add the ability to mark a folder of bookmarks as "private":
https://bugzilla.mozilla.org/show_bug.cgi?id=455649
However, the private browsing feature may cover some of the use-cases
for these features. Often the use-case involves all sites for a
domain, not just a single URL. For example, if you bookmarked
http://www.nekkidninjas.com, you'd likely want all URLs for that
domain blocked from the awesomebar, not just the bookmarked URL. In
this case, either private browsing, or a domain block-list seems like
a better approach.
Are there any use-cases for blocking only specific URLs? Or is this
use-case best served by using private browsing, or maybe by blocking
all bookmarks from the awesomebar? (Which is already in 3.1:
http://ed.agadak.net/2008/07/firefox-31-restricts-matches-keywords)
-d
Simon Bünzli
> Use a special tag to block results from the awesomebar:
> https://bugzilla.mozilla.org/show_bug.cgi?id=450314
>
> Add the ability to mark a folder of bookmarks as "private":
> https://bugzilla.mozilla.org/show_bug.cgi?id=455649
Should we want to cut one of these (and I don't see why we'd need both),
I'd prefer the second solution, as that one would not only be more
discoverable (through the Library/a folder's Properties) but would also
more obviously allow to hide a whole collection of bookmarks.
> Are there any use-cases for blocking only specific URLs?
I do have a folder full of keyword searches which I've got no need at
all for appearing in the address bar (since they're invalid URLs),
except when explicitly entering their keyword. Not sure if that'd be
possible with one of the above solutions.
Furthermore, I could imagine wanting to block the folder with all those
URLs which we need Private Browsing mode for in the first place... ;-)
Cheers,
Simon
Mike Beltzner
> Dietrich Ayala schrieb am 06.10.08 21:01:
>> Use a special tag to block results from the awesomebar:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=450314
>>
>> Add the ability to mark a folder of bookmarks as "private":
>> https://bugzilla.mozilla.org/show_bug.cgi?id=455649
>
> Should we want to cut one of these (and I don't see why we'd need
> both),
> I'd prefer the second solution, as that one would not only be more
> discoverable (through the Library/a folder's Properties) but would
> also
> more obviously allow to hide a whole collection of bookmarks.
Let's not start with the assumption that we only need one. One thing
that's been clear to us throughout the exercise of adding tagging to
our bookmarking infrastructure is that some people love tagging, some
people love fodlers, and some people love both.
I can see rationale for being able to quickly tag something in a way
that assures privacy, and rationale for being able to put all one's
private bookmarks into a folder which is then marked private. I think
it would be good to allow a multiplicity of control here.
>> Are there any use-cases for blocking only specific URLs?
>
> I do have a folder full of keyword searches which I've got no need at
> all for appearing in the address bar (since they're invalid URLs),
> except when explicitly entering their keyword. Not sure if that'd be
> possible with one of the above solutions.
>
> Furthermore, I could imagine wanting to block the folder with all
> those
> URLs which we need Private Browsing mode for in the first place... ;-)
It would be possible, but you'd also end up blocking the entire domain
as well. I do think you point out a good use case here, which is
people who use the privacy controls as a way of actually saying "I
don't want to pollute my awesomebar results with this bookmark".
cheers,
mike
Robert Kaiser
> Are there any use-cases for blocking only specific URLs? Or is this
> use-case best served by using private browsing, or maybe by blocking
> all bookmarks from the awesomebar? (Which is already in 3.1:
> http://ed.agadak.net/2008/07/firefox-31-restricts-matches-keywords)
I'm quite unhappy with the current way of how the restrict preferences
work, as when one of those is not set, we only match that type by
default - resulting in matching nothing (i.e. only URLs that match all
categories) when none are set.
I think we actually should have prefs saying "include XXX in urlbar
search results" which could be ticked on/off, and then we wouldn't need
such a hack like emptying the restrict key to restrict to that categroy
by default.
Robert Kaiser
Mike Beltzner
> Dietrich Ayala wrote:
>> Are there any use-cases for blocking only specific URLs? Or is this
>> use-case best served by using private browsing, or maybe by blocking
>> all bookmarks from the awesomebar? (Which is already in 3.1:
>> http://ed.agadak.net/2008/07/firefox-31-restricts-matches-keywords)
>
> I'm quite unhappy with the current way of how the restrict preferences
> work, as when one of those is not set, we only match that type by
> default - resulting in matching nothing (i.e. only URLs that match all
> categories) when none are set.
I don't understand what you're saying. By default we match based on
our "frecency" algrotihm which weights factors differently, using a
text match that discerns word boundaries but also allows to "find
within". If you use about:config to change the default set of
restriction-matches being used, we'll by-default restrict down. If you
use a restriction match character in the location bar, we'll also
start restricting.
The whole *goal* of restriction-based matching is to not reach out and
find additional data. If you want to expand your search, simply remove
the restriction character:
foo @ (shows only urls)
foo (shows urls and others)
I don't think we want to start expanding this case to care for people
who want to re-weight frecency. That should be done by tweaking the
various frecency bonuses.
> I think we actually should have prefs saying "include XXX in urlbar
> search results" which could be ticked on/off, and then we wouldn't
> need
> such a hack like emptying the restrict key to restrict to that
> categroy
> by default.
SeaMonkey is free to add more preferences, and add-on authors are
welcome to create add-ons that leverage these existing methods to
provide finer control over the awesomebar. Firefox is not interested
in that sort of customizability within our default preferences dialog.
cheers,
mike
Robert Kaiser
I think you're misunderstanding what I meant there. I wasn't talking
about re-weighing frecency or any UI-facing prefs or any prefs in
app-specific code.
I'm talking about the hidden prefs in the toolkit part originally
introduced by bug 395161, which can be set to empty since bug 424557 to
restrict to a certain type (urls/history/titles/bookmarks/tags) by
default, which in turn causes bug 447900 as if none of those are set at
all, we always (!) restrict to entries matching all (!) of those types,
which is practically never true and makes all searches return empty.
IMHO, while the fix to bug 424557 looked simple, it was the wrong way to
go as the toolkit code doesn't work any more if the app doesn't set
restriction match characters for all possible types from the beginning.
This also makes it hard to extend places to include, say, downloads (or
anything else for that matter) in the future, as we again need to rely
on every possible consumer of that toolkit functionality to set up those
(hidden) prefs.
I don't mainly care about this because SeaMonkey now needs to set
bookmark and tag restriction chars in it's default prefs JS file, that's
annoying but doable. I mainly care about because I feel this is wrong
software design and hinders future extensibility of the places backend,
which probably is not what we want to have.
Robert Kaiser
Mark Gosdin
> cheers,
> mike
Mike,
You really need to look at that last sentence of yours.
I always thought that Firefox was a community effort. I see that it, in
reality, belongs to you - or rather the development resources that you
are a part of.
Nice browser you had here.
Mark Gosdin
Mike Beltzner
>> SeaMonkey is free to add more preferences, and add-on authors are
>> welcome to create add-ons that leverage these existing methods to
>> provide finer control over the awesomebar. Firefox is not interested
>> in that sort of customizability within our default preferences
>> dialog.
>>
>> cheers,
>> mike
>
> Mike,
>
> You really need to look at that last sentence of yours.
>
> I always thought that Firefox was a community effort. I see that
> it, in
> reality, belongs to you - or rather the development resources that you
> are a part of.
Hey Mark,
Firefox is indeed a community effort, and part of the Mozilla
community. You'll note that Robert and the SeaMonkey team are free to
take this code and add prefs for it as they see fit. You'll also note
that I clearly invited our add-on community to feel free to tweak and
modify our browser in their ideal image.
There is a set of community members, including myself, who have taken
on the responsibility for guiding the product itself. The module owner
is Mike Connor, for example, and he and the peers within Firefox
review and approve code. I have a broad responsibility for guiding and
directing the design of end-user features, which I do using the ui-
review flag in Bugzilla and through discussions like these.
Community members (such as yourself) are free to disagree with me (and
if you'll check the record, you'll note that such healthy discord
occurs!) but a founding principle of Firefox, going back to Firefox
1.0, is "just because you can doesn't mean that we'll let you."
Control over the design choices used to produce Firefox has always,
and will always continue to exist.
> Nice browser you had here.
For what it's worth, dramatic, fatalistic statements like these really
fail to impress the reader or further your goals, assuming your goals
are actually to try and influence change.
cheers,
mike
Mark Gosdin
> On 7-Oct-08, at 11:29 AM, Mark Gosdin wrote:
>
>>> SeaMonkey is free to add more preferences, and add-on authors are
>>> welcome to create add-ons that leverage these existing methods to
>>> provide finer control over the awesomebar. Firefox is not interested
>>> in that sort of customizability within our default preferences dialog.
>>>
>>> cheers,
>>> mike
>>
>> Mike,
>>
>> You really need to look at that last sentence of yours.
>>
>> I always thought that Firefox was a community effort. I see that it, in
>> reality, belongs to you - or rather the development resources that you
>> are a part of.
>
> Hey Mark,
>
> Firefox is indeed a community effort, and part of the Mozilla community.
> You'll note that Robert and the SeaMonkey team are free to take this
> code and add prefs for it as they see fit. You'll also note that I
> clearly invited our add-on community to feel free to tweak and modify
> our browser in their ideal image.
>
> There is a set of community members, including myself, who have taken on
> the responsibility for guiding the product itself. The module owner is
> Mike Connor, for example, and he and the peers within Firefox review and
> approve code. I have a broad responsibility for guiding and directing
> Bugzilla and through discussions like these.
>
> Community members (such as yourself) are free to disagree with me (and
> if you'll check the record, you'll note that such healthy discord
> occurs!) but a founding principle of Firefox, going back to Firefox 1.0,
> is "just because you can doesn't mean that we'll let you." Control over
> the design choices used to produce Firefox has always, and will always
> continue to exist.
>
>> Nice browser you had here.
>
> For what it's worth, dramatic, fatalistic statements like these really
> fail to impress the reader or further your goals, assuming your goals
> are actually to try and influence change.
>
> cheers,
> mike
Mike,
I apologize for getting "Dramatic" on you. I can only plead that I do
care about the course that Firefox takes.
I've enjoyed using Firefox & it's predecessors for a number of years.
I honestly do think it is worth trying to preserve the things that I
have found worthwhile in the program, and I will disagree with you, and
the other designers, when I see you discard the very things I want to
see preserved.
I can see that what I thought was how the development process worked and
how it actually works are not the same.
I will not take up any more of your time.
Mark Gosdin
Shawn Wilsher
> IMHO, while the fix to bug 424557 looked simple, it was the wrong way to
> go as the toolkit code doesn't work any more if the app doesn't set
> restriction match characters for all possible types from the beginning.
> This also makes it hard to extend places to include, say, downloads (or
> anything else for that matter) in the future, as we again need to rely
> on every possible consumer of that toolkit functionality to set up those
> (hidden) prefs.
sets the defaults, so I'm not sure how you are seeing this behavior.
> I don't mainly care about this because SeaMonkey now needs to set
> bookmark and tag restriction chars in it's default prefs JS file, that's
> annoying but doable. I mainly care about because I feel this is wrong
> software design and hinders future extensibility of the places backend,
> which probably is not what we want to have.
I don't see how this hinders the future extensibility of the places
back-end. Care to elaborate?
Cheers,
Shawn
Gavin Sharp
> The code [1] doesn't fail if the pref isn't set, and the constructor
> sets the defaults, so I'm not sure how you are seeing this behavior.
Except that the constructor-set defaults are overwritten for the prefs
Kairo mentions in bug 447900 comment 2, because prefStr is empty when
the getCharPref calls fail[2].
Gavin
Alex Faaborg
if later shown would embarrass the user. My understanding is that in
general these bookmarks were usually hidden pretty far down in
hierarchies, sometimes using folders with obscure names. One user on
dev.apps.firefox made an analogy to hiding a physical object: If
someone digs through all of your stuff they can find it, but it is at
least a little harder to find for people casually passing by. We
changed the game for users in Firefox 3, where suddenly these
bookmarks that they had buried away were now being proactively
presented as results in the location bar.
So given that these bookmarks already exist, and users still want to
create bookmarks that are intentionally only accessible through a
laborious browse-based interface, I don't think private browsing mode
by itself solves all of the existing problems.
An alternate solution (and in general stronger solution) would be to
allow users to create private accounts, perhaps by exposing some type
of log in interface when we are eventually ready to bring Weave into
Firefox. Currently we have the profile manager, but that interface
was never meant for mainstream public consumption.
> if you bookmarked
> http://www.nekkidninjas.com, you'd likely want all URLs for that
> domain blocked from the awesomebar, not just the bookmarked URL.
In general this makes sense, but I haven't been able to think of how
we would expose that functionality in a way that doesn't seem like
Firefox is being too smart, or exhibiting random behavior. The
private tag + private browsing is conceptually a little clearer:
To control what bookmarks are shown: use the private tag on them
To control what areas of history are shown: use private browsing mode,
or the clear recent history dialog
> a domain block-list seems like a better approach.
Since we have to support undo (so the user can never say never), we
end up ironically creating a list of all the things the user doesn't
want to have appear in an organized list. For instance, the classic
Firefox ruined my marriage bug:
Firefox: Do you want me to remember your password?
User: Never!
Firefox: I'll remember that I shouldn't remember it
When it comes to privacy it seems like we need to avoid block-lists.
-Alex
On Oct 6, 2008, at 12:01 PM, Dietrich Ayala wrote:
> There are a couple of bugs targeting Firefox 3.1 that let users block
> some bookmarked URLs from showing up in the awesomebar:
>
> Use a special tag to block results from the awesomebar:
> https://bugzilla.mozilla.org/show_bug.cgi?id=450314
>
> Add the ability to mark a folder of bookmarks as "private":
> https://bugzilla.mozilla.org/show_bug.cgi?id=455649
>
> However, the private browsing feature may cover some of the use-cases
> for these features. Often the use-case involves all sites for a
> domain, not just a single URL. For example, if you bookmarked
> http://www.nekkidninjas.com, you'd likely want all URLs for that
> domain blocked from the awesomebar, not just the bookmarked URL. In
> this case, either private browsing, or a domain block-list seems like
> a better approach.
>
> Are there any use-cases for blocking only specific URLs? Or is this
> use-case best served by using private browsing, or maybe by blocking
> all bookmarks from the awesomebar? (Which is already in 3.1:
> http://ed.agadak.net/2008/07/firefox-31-restricts-matches-keywords)
>
> -d
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox