Closed Bug 708707 Opened 8 years ago Closed 7 years ago

Mobile Widget for Firefox Mobile (Version 1)

Categories

(Firefox for Android :: General, defect, P5)

ARM
Android
defect

Tracking

()

VERIFIED FIXED
Firefox 19

People

(Reporter: padamczyk, Assigned: sriram)

References

Details

Attachments

(5 files, 5 obsolete files)

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
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.
Priority: -- → P5
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.
Attached file Widget Assets in PNG (obsolete) —
Attached image widgeting space (obsolete) —
Assignee: nobody → sriram
Summary: Mobile Widget for Firefox Mobile 11 (if time permits) → Mobile Widget for Firefox Mobile (Version 1)
Attached file Widget Assets in PNG (Gradient) (obsolete) —
Attachment #580555 - Attachment is obsolete: true
Attached patch WIP (obsolete) — Splinter Review
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.
http://cl.ly/1847063S123P1M0D3u25 - is the current state of the widget.
Attachment #608118 - Flags: feedback?(mark.finkle)
OS: Mac OS X → Android
Hardware: x86 → ARM
Attached file New Graphics
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.
Attachment #580564 - Attachment is obsolete: true
Attachment #605946 - Attachment is obsolete: true
Attachment #605948 - Attachment is obsolete: true
Duplicate of this bug: 631717
Duplicate of this bug: 648853
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).
Attachment #608118 - Attachment is obsolete: true
Attachment #608118 - Flags: feedback?(mark.finkle)
Attachment #672078 - Flags: review?(mark.finkle)
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.
Attachment #672079 - Flags: review?(mark.finkle)
Attachment #672078 - Flags: review?(mark.finkle) → review+
Attachment #672079 - Flags: review?(mark.finkle) → review+
https://hg.mozilla.org/mozilla-central/rev/f0dbdf4d4768
https://hg.mozilla.org/mozilla-central/rev/d7464788b572
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → Firefox 19
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)
Status: RESOLVED → VERIFIED
Flags: in-moztrap+
(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?
You need to log in before you can comment on or make changes to this bug.