'Allowed Sites - Popups' list customization

[Cyrille Mertens]

Hi All,

I have to deploy Firefox on several workstations with one site added to the
'Allowed Sites - Popups' list. Is there a way to customize this?

Thanks,
Cyrille

[Gavin Sharp]

My initial implementation of the Firefox search service (bug 317107)
lived in browser/components/search, but Mike Connor recently suggested
it might be better suited for inclusion in the toolkit (e.g.
toolkit/components/search). The nsISearchService interface
(http://wiki.mozilla.org/Search_Service:API) is used to manage search
engine files, and provides an easy way to obtain search result objects
(nsISearchSubmissions) given a set of search terms. It will be used as a
backend to the functionality that the Firefox search bar offers. One
idea for possible uses outside of a browser was desktop search widgets.
I imagine it could be useful for applications other than browsers,
especially since it could eventually be easily extended to provide
search result aggregation functionality, and management of search result
formats (RSS, HTML, etc).

What initially lead me to this train of thought was Ben's suggestion
that the Sherlock parsing code be factored out to facilitate writing
test programs that verify that the parsing is correct, without having to
copy code from the search service. Were the search service to move to
the toolkit, an nsISherlockParser interface could be implemented
alongside it for use in testing tools and other possible applications.

I'd appreciate feedback on whether or not people think the search
service (and a Sherlock parser) would be of value to the toolkit.

Thanks,
Gavin Sharp

[Gavin Sharp]

(Apologies for the duplication, my first message had an incorrect In-Reply-To header)

[Robert Strong]

It should reside in toolkit... SongBird might be able to use it since it
also has search.

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

[Ben Goodger]

What does being in browser vs. toolkit have to do with what kind of
testing can be performed?

I'm generally pretty hesitant these days to advocate putting something
in toolkit because another app "might" want to use it. Without actually
working with another implementor, we end up with an API designed only
for ourselves that becomes more difficult to change later since it's
part of the "toolkit api".

-Ben

[Ben Goodger]

What does being in browser vs. toolkit have to do with what kind of
testing can be performed?

I'm generally pretty hesitant these days to advocate putting something
in toolkit because another app "might" want to use it. Without actually
working with another implementor, we end up with an API designed only
for ourselves that becomes more difficult to change later since it's
part of the "toolkit api".

-Ben

[Gavin Sharp]

Ben Goodger wrote:
> What does being in browser vs. toolkit have to do with what kind of
> testing can be performed?

The "makes it easier to test" argument was an argument in favor of the
Sherlock parser being it's own component. I wrote a small XULRunner
application that I used to test the Sherlock parser on a large sample of
plugins, and I ended up having to just copy the code. If the code were
to remain in /browser, I suppose that application could be used as an
extension, but with the sherlock code embedded in the search service it
still wouldn't be able to test the parsing independently.

> I'm generally pretty hesitant these days to advocate putting something
> in toolkit because another app "might" want to use it. Without
> actually working with another implementor, we end up with an API
> designed only for ourselves that becomes more difficult to change
> later since it's part of the "toolkit api".

Good point. I suppose it's easier to move the code to toolkit later on,
if there's a need. I'm not sure that keeping it in /browser makes the
API any more flexible though, considering that it will likely be used by
browser extensions.

Gavin Sharp

[Axel Hecht]

I had three questions here, the first is impact on seamonkey, the latter
is impact on thunderbird. And then there's xulrunner and default plugins.

Would seamonkey like to move over to the new search engines, too, and if
so, when?

How much is the increase in download size for thunderbird if we add the
search engine stuff to toolkit is the other question.

If we put search into toolkit, should we put default searchengines in
there, too? It's a bit like the issue with security certificates, if we
consider searching a toolkit feature, what does management of search
mean? (This may be 4.0 material, though.)

Axel

[Nick Thomas (cf)]

There are a couple of ways to go about this. For a completely automated
install and general customization, see
http://developer.mozilla.org/en/docs/Deploying_Firefox
and follow the link to the Firefox CCK.

Alternatively you can take the manual approach, given that the
information is stored in a file hostperm.1 in the profile. There isn't a
default file in c:\program files\mozilla firefox\defaults\profile, but
if you copy one there it will be used for all new profiles. Doesn't help
for any existing profiles though (eg if anyone has already run Firefox
on any of these workstations).

[Benjamin Smedberg]

Ben Goodger wrote:
> What does being in browser vs. toolkit have to do with what kind of
> testing can be performed?
>
> I'm generally pretty hesitant these days to advocate putting something
> in toolkit because another app "might" want to use it. Without actually
> working with another implementor, we end up with an API designed only
> for ourselves that becomes more difficult to change later since it's
> part of the "toolkit api".

In general, my guidelines for putting something in the toolkit look
something like this:

1) it doesn't significantly affect FF codesize. For any feature that's going
to be in Firefox anyway this is mostly a non-issue because we can easily
move stuff.

2) It presents *either* a stable API *or* a feature that apps or embedders
need or will definitely use even if it's not frozen.

3) If it doesn't present a frozen API, we should document clearly that it
may change significantly in the future and "use at your own risk".

In this case, I agree with Ben. The search service at this point is pretty
focused on the browser and doesn't provide services that we know are going
to be used by other apps. If other apps *do* want these services, it is
pretty simple to use the code from browser/components without having to
worry about conflicts with other code.

--BDS