Closed Bug 898352 Opened 8 years ago Closed 8 years ago

Explore opensearch UI

Categories

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

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: vingtetun, Assigned: kgrandon)

References

Details

(Whiteboard: [d-watch])

Attachments

(1 file)

It would be nice to have a UI to use opensearch engine if there is an opensearch database somewhere.
I think at this point it makes sense to continue with the prototype and make a pull request from that.
Assignee: nobody → kgrandon
Attachment #782704 - Flags: review?(21)
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 :)
Attachment #782704 - Flags: review?(21)
Whiteboard: [d-watch]
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.
Blocks: 899773
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!
Attachment #782704 - Flags: review?(21)
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
Flags: needinfo?(l10n)
(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.
Obviously all the parsing logic would good to re-used at some point.
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.
Flags: needinfo?(l10n)
(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 on attachment 782704 [details]
github-pull-request.html

r+ with nits.
Attachment #782704 - Flags: review?(21) → review+
(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.
(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.
Depends on: 900208
Depends on: 900211
You need to log in before you can comment on or make changes to this bug.