898352 - Explore opensearch UI

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System, defect)

Description

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

It would be nice to have a UI to use opensearch engine if there is an opensearch database somewhere.

Comment 1

[Kevin Grandon :kgrandon]

I think at this point it makes sense to continue with the prototype and make a pull request from that.

Comment 2

[Kevin Grandon :kgrandon]

Attachment: github-pull-request.html

Comment 3

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 782704 [details]
github-pull-request.html

I made some comments on github. Thanks for tacking this work Kevin, you will be a hero :)

Comment 4

[Axel Hecht [:Pike]]

I think there are a few folks that are good to get feedback from, including myself. I'd also nominate gavin, margaret, mfinkle, to make sure we're converging on a somewhat consistent feature set around opensearch. Noteworthy as Android and desktop are already exposing naughty little differences.

Comment 5

[Kevin Grandon :kgrandon]

Comment on attachment 782704 [details]
github-pull-request.html

Hi Vivien - I think this is ready for another pass. I think the only remaining item is the issue of labeling the methods in the object. I'm really not a fan of having the duplicate label when we can infer the function name, but if you think it's necessary we can add them. Thanks!

Comment 6

[Kevin Grandon :kgrandon]

Axel - Definitely looking to be open and collaborative about the approach. I would argue that we're *not* trying to copy our prior works, but I'm fairly new, and if there's any knowledge we can take advantage of - we certainly should.

I've CC'd the suggested audience to this bug. If anyone has time, I would suggest going through the following tree and chiming in where appropriate: https://bugzilla.mozilla.org/showdependencytree.cgi?id=899773&hide_resolved=1

Comment 7

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Axel Hecht [:Pike] from comment #4)
> I think there are a few folks that are good to get feedback from, including
> myself. I'd also nominate gavin, margaret, mfinkle, to make sure we're
> converging on a somewhat consistent feature set around opensearch.
> Noteworthy as Android and desktop are already exposing naughty little
> differences.

The current implementation does not take advantage of the prior art exposed via Services.search and all the magical things there.
There are a few reasons for that, the first one beeing that toolkit/search is disable on b2g/ in order to save 1mb of memory iirc.
The second is that we want to explore exposing the opensearch list as a Data Store which is not available right now on desktop/android.
The third is that we may need to extend the opensearch standard at some point and we don't want to land such behavior under toolkit/ for now.

Comment 8

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Obviously all the parsing logic would good to re-used at some point.

Comment 9

[Axel Hecht [:Pike]]

Here's a few things on my mind:

Support for MozSearch. Most of these just implement the things we got asked to support for monetization, and I'd be surprised if that wouldn't show up on fx os at some point.

Consistent <Image> handling. In gecko, we always use the 16x16 image, on android preferably with a 32x32 image data uri. At least, don't expect the size in the <Image> element to be the size of the image, we may have very well trained opensearch plugins in the wild to not do that.

Correct data: uri handling. Right now, Android doesn't url unescape, and hard-codes base64. I guess you're using the data uri's straight away, so that may not be a problem at all for you.

Localizable defaults: I'm not too eager to add that to my plate, but I expect that we'll want that.

Consistent extensions to opensearch: I think we should have public discussions about those, so that other platforms can chime in, and benefit. geo-aware like mentioned in bug 899779 comment 0 sounds beneficial on at least Android, for example.

Comment 10

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Axel Hecht [:Pike] from comment #9)
> Here's a few things on my mind:
> 
> Support for MozSearch. Most of these just implement the things we got asked
> to support for monetization, and I'd be surprised if that wouldn't show up
> on fx os at some point.
> 

Thanks for the information. I opened bug 900004

> Consistent <Image> handling. In gecko, we always use the 16x16 image, on
> android preferably with a 32x32 image data uri. At least, don't expect the
> size in the <Image> element to be the size of the image, we may have very
> well trained opensearch plugins in the wild to not do that.
> 

The interface to add search engine is not part of this bug - but that's definitively a good consideration. I guess since Mobile buttons tend to be bigger, 32x32 would be good if possible... but that's a different bug. I'm not opening bug for that right now as I'm unsure how Kevin wants to deal with the editing feature.
 
> Localizable defaults: I'm not too eager to add that to my plate, but I
> expect that we'll want that.
> 

I open a bug to be able to feed the open search provider database at build time.
Bow that I'm thinking more about that I wonder if partners are going to want them to depends on the mcc/mnc of the sim card inserted during first run experience...

Let's discuss that into bug 900002 (yeah! > 900000)

> Consistent extensions to opensearch: I think we should have public
> discussions about those, so that other platforms can chime in, and benefit.
> geo-aware like mentioned in bug 899779 comment 0 sounds beneficial on at
> least Android, for example.

Yeah. Right now we have added one field to the suggestions format to accommodate applications search. But there could be other ways of doing that.

Kevin has already opened bug 899779 for that.


Thanks for those good points!

Comment 11

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 782704 [details]
github-pull-request.html

r+ with nits.

Comment 12

[:Margaret Leibovic]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #10)

> > Consistent <Image> handling. In gecko, we always use the 16x16 image, on
> > android preferably with a 32x32 image data uri. At least, don't expect the
> > size in the <Image> element to be the size of the image, we may have very
> > well trained opensearch plugins in the wild to not do that.
> > 
> 
> The interface to add search engine is not part of this bug - but that's
> definitively a good consideration. I guess since Mobile buttons tend to be
> bigger, 32x32 would be good if possible... but that's a different bug. I'm
> not opening bug for that right now as I'm unsure how Kevin wants to deal
> with the editing feature.

The fact that the search service just expects one 16x16 icon (and that we actually stick at 32x32 icon in there for Android), is mainly a historical artifact. We've talked about fixing the search service to accept multiple icon sizes, but someone would just need to do that work (not sure if there's a bug filed on that, Gavin would know). We'd actually really like that on Android, since 32x32 can still be too small on high-res devices.

Comment 13

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

https://github.com/mozilla-b2g/gaia/commit/4154883618958057ba897ca9dd1a5b3038820872

Comment 14

[:Gavin Sharp [email: [e-mail]]]

(In reply to :Margaret Leibovic from comment #12)
> We've talked about fixing the search service to accept multiple
> icon sizes, but someone would just need to do that work (not sure if there's
> a bug filed on that, Gavin would know).

I filed bug 900137.