Patryk Adamczyk [:patryk] UX Reporter
	Description • 13 years ago

Here is a basic search widget for Firefox mobile.
If would be a nice to have if time permits for its implementation.
Here are the designs for 320w, 480w and 720w screens.
http://www.flickr.com/photos/patrykdesign/6477109545/in/photostream

	Sriram Ramasubramanian [:sriram] Assignee
	Comment 1 • 13 years ago

I like this design better :)
Some doubts:
1. Is the background of the widget having some noise? Current URL bar uses plain gradient without noise. Using noise will require us to use a PNG for background (which wouldn't be scalable). Or have noise as a separate layer -- which would impact startup time (not here but for URL bar).
2. Android doesn't support "box-shadows". We either need to have it as a PNG and use it or find other ways to do it.
3. I like the nice little border at the bottom (transparent line). However, I'm not sure if it's that simple to implement :(

I would like to know the size of the icons, search bar, padding between them on a 320px scale.

	Patryk Adamczyk [:patryk] UX Reporter
	Comment 2 • 13 years ago

1. The background would work exactly the same as the navigation bar header... just the bounding 9 slice would differ by having a different corner radius and the drop shadows.
2. Ok, probably a PNG might be a good start. Let me know what to provide.
3. That would part of the 9 slice. We'd want to make the noise texture into a pattern, so it can be replicated within the 9 slice.

Assets attached.

	Sriram Ramasubramanian [:sriram] Assignee
	Comment 7 • 12 years ago

This is a WIP for the widget. This uses the background asset from the attachment.
This doesn't have voice recognizer attached to it yet.

There are few things to be considered.
* Widgets can take any number of "cells" in the screen. A cell is typically 76dp X 76dp. Which means, if we want a widget to be the mobile screen's width (4 cells), we need to have 292dp (2dp left on each sides)

* I believe, the firefox icon will be replaced with Aurora and Nightly icons for their corresponding branding. Which means, we don't have anything more than 32dp x 32dp "logo" in channel-branded folders. Can we go with "large_logo" of size 52dp x 52dp? It's definitely going to affect the apk size.

* The url-bar cannot have focus color "from the device" just like we do in our app. That can be added when we do "single highlight color".

Resources:
I would need newer sizes, and newer resources. Basically mdpi is 1x, hdpi is 1.5x and xhdpi is 2x.

I will post a screenshot soonish.

	Sriram Ramasubramanian [:sriram] Assignee
	Comment 8 • 12 years ago

http://cl.ly/1847063S123P1M0D3u25 - is the current state of the widget.

	Patryk Adamczyk [:patryk] UX Reporter
	Comment 9 • 12 years ago

The spec PNG is MDPI, each square is 4dp.
The 9 slice graphics are should be vertically centered within the cells.
The mdpi widget fits 76dp.

	Sriram Ramasubramanian [:sriram] Assignee
	Comment 14 • 12 years ago

This patch adds branded icons (54x54 dp). I have made sure the Makefile.in looks identical for *dpi branding directories (instead of overloading MOZ_ANDROID_DRAWABLES).

	Sriram Ramasubramanian [:sriram] Assignee
	Comment 15 • 12 years ago

This patch adds the widget.
When the URL bar is tapped:
1. If the app is already open, it opens the awesomebar.
2. If the app is not open, it opens the app.

This can be changed by calling addTab() on onCreate(), but I am not sure if we want that. If needed, I can post a followup patch.

	Sriram Ramasubramanian [:sriram] Assignee
	Comment 16 • 12 years ago

Pushed to inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f0dbdf4d4768
https://hg.mozilla.org/integration/mozilla-inbound/rev/d7464788b572

	Ryan VanderMeulen [:RyanVM]
	Comment 17 • 12 years ago

https://hg.mozilla.org/mozilla-central/rev/f0dbdf4d4768
https://hg.mozilla.org/mozilla-central/rev/d7464788b572

	Adrian Tamas (:AdrianT)
	Comment 18 • 12 years ago

Created test cases for the feature in Moztrap. The test suite can be found here: https://moztrap.mozilla.org/manage/cases/?filter-suite=159.

The feature works as expected (the scenario in Comment 15). Marking the issue as verified.
Tested on:
Nightly 19.0a1 2012-10-28
Samsung Galaxy R (Android 2.3.4)

	Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]
	Comment 19 • 12 years ago

(In reply to Sriram Ramasubramanian [:sriram] from comment #15)
> When the URL bar is tapped:
> 1. If the app is already open, it opens the awesomebar.
> 2. If the app is not open, it opens the app.

This behavior seems unintuitive to me. Whether the app is open or closed should be transparent to the user and thus this behavior may seem non-deterministic.

Is it possible to open the awesomebar in both cases?