862377 - Android WebRTC permissions UI will only respect first doorhanger

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Gian-Carlo Pascutto [:gcp]]

This is a very similar problem to bug 861716, but filing separately as it's not necessarily exactly the same issue.

Currently, the permissions are asked separately for audio and video and 2 doorhangers are popped up. The first doorhanger clicked will fire a callback and this will set up the WebRTC gUM call. The second doorhanger clicked will also fire a callback but gUM currently does not take it into account.

As a result, you can currently enable audio or video, but not both, unless you disable permission checks.

Comment 1

[Brad Lassey [:blassey] (use needinfo?)]

Ian, we'll need a UX for this

Comment 2

[Brad Lassey [:blassey] (use needinfo?)]

Sorry, read that wrong

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

How does desktop handle this differently? I assume it works fine on desktop.

Comment 4

[Jason Smith [:jsmith]]

Attachment: Desktop gUM Audio Video Request Together

Here's the UI design on desktop for the doorhanger as a reference.

Comment 5

[Jason Smith [:jsmith]]

(In reply to Mark Finkle (:mfinkle) from comment #3)
> How does desktop handle this differently? I assume it works fine on desktop.

See the screenshot. We have a single doorhanger appear with two select boxes that allow the user to choose which mic and camera to share. The user can then confirm to share those devices, not share, or not now.

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

In fact, the desktop UI only respects the last getUserMedia request (and there's a bug on it not sending success or failure to earlier ones, among other fallouts from that.)  Bug 861716

(I don't think apprtc does multiple requests however, see Jason's comment)

Comment 7

[Gian-Carlo Pascutto [:gcp]]

This is probably easiest to address inside the JavaScript that sits between the C++ and the Java UI, by having it remember outstanding requests and delay the callback, making it work similarly to desktop.

That being said, due to the way doorhangers on Android currently work, I'd be more logical from a user pespective if the moment you click "Share" on audio, the audio stream (setup) can start, and the moment you click "Share" on video, the video stream (setup) can start.

But is this something our current code/model can handle?

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

Currently the API to MediaManager doesn't support incremental permissions, and even if it did, the getUserMedia API doesn't really support it - the apps will expect when getUserMedia's success callback happens they can query the stream to see which streams were approved.

Comment 9

[Gian-Carlo Pascutto [:gcp]]

Okay. So the UI needs to change to "merge" the UI into a single doorhanger, or we can delay calling back until all doorhangers are dismissed in the JavaScript. No need to handle the incremental case.

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Gian-Carlo Pascutto (:gcp) from comment #9)
> Okay. So the UI needs to change to "merge" the UI into a single doorhanger,
> or we can delay calling back until all doorhangers are dismissed in the
> JavaScript. No need to handle the incremental case.

We could check to see if the media doorhanger is visible, and if so use it for both permissions. We will need to track the state: video only, audio only, or both. We might also need to change the text in the permission prompt based on the state. I don't know how to do that using our current system. We may need to close the first prompt and display a new prompt.

Comment 11

[Gian-Carlo Pascutto [:gcp]]

Don't forget that you need to be able to select from multiple devices too (especially for the camera), so it's certainly not only 3 states.

Comment 12

[Wesley Johnston (:wesj)]

Attachment: Patch 1/3 Move prompt inputs to its own file

Comment 13

[Wesley Johnston (:wesj)]

Attachment: Patch 2/3 - Allow showing inputs on doorhangers

These two patches together let us show any of the input types we can show in dialogs in doorhangers as well. I've made a small change so that spinners don't create a PopupWindow anymore, but instead use a dialog look (popupwindows in popupwindows cause things to crash), plus some other cleanup.

Comment 14

[Wesley Johnston (:wesj)]

Attachment: Patch 3/3 - Use spinners in webrtc doorhangers

This is the js piece to use spinners in the webrtc doorhangers. Screenshot coming (my phone only has one speaker, so I'll have to try other devices to see if we can get both an audio and a video spinner to show)....

Comment 15

[Wesley Johnston (:wesj)]

Attachment: Screenshot

Comment 16

[Jason Smith [:jsmith]]

Comment on attachment 749572 [details] [diff] [review]
Patch 3/3 - Use spinners in webrtc doorhangers

Review of attachment 749572 [details] [diff] [review]:
-----------------------------------------------------------------

::: mobile/android/app/mobile.js
@@ +731,5 @@
>  pref("dom.payment.provider.0.requestMethod", "GET");
>  
>  // This needs more tests and stability fixes first, as well as UI.
> +pref("media.navigator.enabled", true);
> +pref("media.peerconnection.enabled", true);

Why are we flipping these prefs on?

There's still some outstanding bad bugs that exist that argue against a pref on at this point. Bugs I think that are needed besides this one include:

- bug 843365
- bug 862808
- bug 867185

Randell might know of others too in the list. A second UI piece might be needed too (past security/privacy discussions revealed we need an always visible indicator to the user when the camera/mic is in use).

I'm concerned if we jump the gun here to pref on that we'll get noisy with bugs filed by contributors for some of the obvious bugs cited above.

Comment 17

[Wesley Johnston (:wesj)]

Its just a patch. I flipped them for testing and forgot to flip them when I uploaded it.

Comment 18

[Ian Barlow (:ibarlow)]

Attachment: Menu mockup

Hi Wes, a few UI comments here, with an included mockup

1. Use sentence case for buttons
2. Tweak styling on picker menus
3. Use more human friendly language on the camera picker (Front facing camera, Rear facing camera)

The mockup also includes the case where multiple microphone options are available, but this is just for reference, I realize this is currently out of scope

Comment 19

[Jason Smith [:jsmith]]

Some comments on the UX spec:

I don't see an option to allow denial of a specific camera/mic in the video+audio case. Drop-downs for an input device should be:

- Camera 1
- Camera 2
- No Video <--- missing this case

- Mic 1
- No Audio <--- missing this case

A user needs to be able to limit to only allowing audio or video if a video/audio gUM call is requested.

Also, putting the multiple microphone option use case out of scope doesn't really make sense to me. That's going to be a crippling user experience to users that intend to use anything but the default microphone (you'll miss the bluetooth use case for example). This is also a key piece of the getUserMedia API and goes against parity with desktop if we don't do this.

Be sure to take into account in the implementation also that you'll have phones with either front/rear cameras, only a front or rear camera, or none at all. For mics, be ready for alternative input sources than the default.

Comment 20

[Gian-Carlo Pascutto [:gcp]]

>I don't see an option to allow denial of a specific camera/mic in the video+audio case.

The "Don't share" option?

>Also, putting the multiple microphone option use case out of scope doesn't really make sense to me.

Not to me either, but according to Plantronics (which has quite the interest in it), Android simply doesn't support selecting the input device if we use the low-latency backend. See bug 859430.

Until that gets fixed...somehow...we don't need to worry about showing audio inputs. The code doesn't support it at all either, IIRC.

Comment 21

[Jason Smith [:jsmith]]

Attachment: The No Video Option for gUM Doorhanger

Comment 22

[Jason Smith [:jsmith]]

(In reply to Gian-Carlo Pascutto (:gcp) from comment #20)
> >I don't see an option to allow denial of a specific camera/mic in the video+audio case.
> 
> The "Don't share" option?

Nope, not that. See the screenshot I just attached.

> 
> >Also, putting the multiple microphone option use case out of scope doesn't really make sense to me.
> 
> Not to me either, but according to Plantronics (which has quite the interest
> in it), Android simply doesn't support selecting the input device if we use
> the low-latency backend. See bug 859430.
> 
> Until that gets fixed...somehow...we don't need to worry about showing audio
> inputs. The code doesn't support it at all either, IIRC.

Hmm...well, that sucks. We should bring that up in next week's WebRTC meeting.

Comment 23

[Ian Barlow (:ibarlow)]

(In reply to Jason Smith [:jsmith] from comment #22)
> (In reply to Gian-Carlo Pascutto (:gcp) from comment #20)
> > >I don't see an option to allow denial of a specific camera/mic in the video+audio case.
> > 
> > The "Don't share" option?
> 
> Nope, not that. See the screenshot I just attached.

Sure, we can include it. Last week we felt comfortable with going ahead with an all-or-nothing approach, since WebRTC would only respect the first decision you made. But now that we have added these pickers into the mix, there's no reason not to have more fine grain control. 


> 
> > 
> > >Also, putting the multiple microphone option use case out of scope doesn't really make sense to me.
> > 
> > Not to me either, but according to Plantronics (which has quite the interest
> > in it), Android simply doesn't support selecting the input device if we use
> > the low-latency backend. See bug 859430.
> > 
> > Until that gets fixed...somehow...we don't need to worry about showing audio
> > inputs. The code doesn't support it at all either, IIRC.
> 
> Hmm...well, that sucks. We should bring that up in next week's WebRTC
> meeting.

Yeah, obviously I too would prefer to have the ability to choose multiple microphones sooner rather than later, if we can.

Comment 24

[Wesley Johnston (:wesj)]

Comment on attachment 749572 [details] [diff] [review]
Patch 3/3 - Use spinners in webrtc doorhangers

Clearing this review while I update things. I'll also need to do some style changes, but I'll throw them in a fourth patch.

Comment 25

[Ian Barlow (:ibarlow)]

Attachment: Mockup

Same basic mockup, but with some additional notes about allowing users to choose "no audio" or "no video"

Comment 26

[Jason Smith [:jsmith]]

Oh one slight nit on the spec - the "No Video" or "No Audio" case applies when video/audio are both requested in gUM. We don't need to show that option in the case when only video or audio is requested by gUM.

Comment 27

[Ian Barlow (:ibarlow)]

Doh. 

Ok. I think we can safely just proceed though, let's remember these mockups came after we already started implementing the menus. :)

Comment 28

[Sriram Ramasubramanian [:sriram]]

Comment on attachment 749568 [details] [diff] [review]
Patch 1/3 Move prompt inputs to its own file

Seems like just pulling out code to a new file. LGTM.

Comment 29

[Sriram Ramasubramanian [:sriram]]

Comment on attachment 749571 [details] [diff] [review]
Patch 2/3 - Allow showing inputs on doorhangers

Review of attachment 749571 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me. r+ with couple of changes mentioned.

::: mobile/android/base/DoorHanger.java
@@ +31,5 @@
>      // The popup that holds this doorhanger
>      private DoorHangerPopup mPopup;
>      private LinearLayout mChoicesLayout;
>      private TextView mTextView;
> +    private ArrayList<PromptInput> mInputs;

It's better to declare it as List<PromptInput> (not being a Java pundit here :( ). It's just a good approach.

@@ +49,5 @@
>      private int mPersistence = 0;
>      private boolean mPersistWhileVisible = false;
>      private long mTimeout = 0;
>  
> +    DoorHanger(Context aActivity, DoorHangerPopup aPopup, int aTabId, String aValue) {

Could you make this java style instead of javascript style? And "Context context" instead of "aActivity".

@@ +56,4 @@
>          mPopup = aPopup;
>          mTabId = aTabId;
>          mValue = aValue;
> +        mInputs = null;

This will be null by default. We don't need to set it.

@@ +60,2 @@
>      }
>   

Remove this.

@@ +211,5 @@
> +                } catch(JSONException ex) { }
> +            }
> +        }
> +
> +        // XXX - We should deprecate this style of input eventually

Do we need this comment?

::: mobile/android/base/resources/layout/doorhanger.xml
@@ +18,5 @@
> +              android:layout_width="fill_parent"
> +              android:layout_height="wrap_content"
> +              android:orientation="vertical"
> +              android:gravity="right"
> +              android:visibility="gone"/>

Seems like you might need a padding here, based on the screenshots and mockups.

Comment 30

[Wesley Johnston (:wesj)]

Attachment: Patch 3/4 - Add spinners to webrtc doorhangers

If you're not comfortable with reviewing this ram, feel free to pass it to someone else. One more styling patch for you...

Comment 31

[Wesley Johnston (:wesj)]

Attachment: Patch 4/4 - Styling stuff

This does all the styling work. Making the text align on the left like the mockups will require using custom images. I... didn't want to do that here. I'll post some screenshots.

Comment 32

[Wesley Johnston (:wesj)]

Attachment: ICS screenshot

Here's a screenshot of this on ICS. I went with "Microphone 1" in this case because we don't technically know anything about the mic.

Comment 33

[Wesley Johnston (:wesj)]

Attachment: GB Screenshot

Screenshot on GB. I just realized there's a bug here... in cases where the page only requests audio or video AND there's only one audio or video device, we don't really need a spinner at all. Will put up another patch...

Comment 34

[Wesley Johnston (:wesj)]

Attachment: Patch 5/4

Don't show the spinners if they're not helpful. Also contains two other little cleanup pieces I apparently forgot to qref in the last patch.

Comment 35

[Ian Barlow (:ibarlow)]

Looking good Wes. Whatever we can do to get that text aligning better on the left would be great :)

Your "CAMERA TO USE" headings on the Gingerbread screenshot look a little tiny too. We can look at it on a device, but I have a feeling we'll want to bump those up a bit

Comment 37

[Sriram Ramasubramanian [:sriram]]

Comment on attachment 750736 [details] [diff] [review]
Patch 3/4 - Add spinners to webrtc doorhangers

Review of attachment 750736 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me. But I haven't worked on Gecko side much. It would be nice if you pass on the review to someone else.

Comment 38

[Sriram Ramasubramanian [:sriram]]

Comment on attachment 750762 [details] [diff] [review]
Patch 4/4 - Styling stuff

Review of attachment 750762 [details] [diff] [review]:
-----------------------------------------------------------------

Needs some refactor while adding inputs to doorhangers.

::: mobile/android/base/DoorHanger.java
@@ +209,5 @@
>                      mInputs.add(pi);
> +
> +                    View v = pi.getView(getContext());
> +                    // add some top and bottom padding to separate inputs
> +                    v.setPadding(0, getResources().getDimensionPixelSize(R.dimen.doorhanger_padding_spinners),

Get this value once, store it in a variable and use it please. Resolving these values is always costly. In fact, you could make it a static final, if this doesn't change with different layouts (phone vs tablets). That's even better. Android codebase does this everywhere -- as long as the value wouldn't change / or needn't be exposed as a themed value.

@@ +216,5 @@
> +                    // for spinners that have a label, style the label
> +                    if (pi instanceof PromptInput.MenulistInput) {
> +                        PromptInput.MenulistInput spinInput = (PromptInput.MenulistInput)pi;
> +                        if (spinInput.textView != null) {
> +                            if (android.os.Build.VERSION.SDK_INT < android.os.Build.VERSION_CODES.ICE_CREAM_SANDWICH) {

Please import "android.os.Build". This statement will be shorter and easier to read.

@@ +222,5 @@
> +                                spinInput.textView.setText(label.toUpperCase());
> +                            } else {
> +                                spinInput.textView.setAllCaps(true);
> +                            }
> +                            

Extra space here.

@@ +224,5 @@
> +                                spinInput.textView.setAllCaps(true);
> +                            }
> +                            
> +                            spinInput.textView.setTextColor(getResources().getColor(R.color.text_color_primary_disable_only));
> +                            spinInput.textView.setTextSize(getResources().getDimension(R.dimen.doorhanger_spinner_textsize));

Could you move this entire chunk to a custom TextView? And we have an AllCapsTextView, that you could use.

::: mobile/android/base/PromptInput.java
@@ +242,5 @@
>          public static final String INPUT_TYPE = "menulist";
>          private static String[] mListitems;
>          private static int mSelected;
> +        private Spinner mSpinner;
> +        public TextView textView;

This needn't be declared here. Could be a block level variable.

@@ +251,5 @@
>              mSelected = obj.optInt("selected");
>          }
>  
>          public View getView(final Context context) throws UnsupportedOperationException {
> +            if (android.os.Build.VERSION.SDK_INT < android.os.Build.VERSION_CODES.HONEYCOMB) {

Import android.os.Build please.

@@ +267,4 @@
>                  }
>              } catch(Exception ex) { }
>  
> +            Log.i(LOGTAG, "Spinner has label: " + mLabel);

Remove this.

@@ +267,5 @@
>                  }
>              } catch(Exception ex) { }
>  
> +            Log.i(LOGTAG, "Spinner has label: " + mLabel);
> +            mView = (View)mSpinner;

Are we using mView anywhere else? If not, please return the "container/mSpinner" below. We don't need a cast.

@@ +271,5 @@
> +            mView = (View)mSpinner;
> +
> +            if (!TextUtils.isEmpty(mLabel)) {
> +                LinearLayout container = new LinearLayout(context);
> +                container.setOrientation(LinearLayout.VERTICAL);

I would suggest adding the padding here. Instead of doing it in DoorHanger.java.

@@ +273,5 @@
> +            if (!TextUtils.isEmpty(mLabel)) {
> +                LinearLayout container = new LinearLayout(context);
> +                container.setOrientation(LinearLayout.VERTICAL);
> +
> +                textView = new TextView(context);

final AllCapsTextView textView = new AllCapsTextView(context, null, R.style.default_doorhanger_textstyle);

::: mobile/android/base/resources/values-v11/styles.xml
@@ +74,5 @@
>      </style>
>  
>      <!-- Spinner Item -->
>      <style name="SpinnerItem" parent="@android:style/Widget.Holo.Light.TextView.SpinnerItem">
> +        <item name="android:textColor">#444</item>

#FF444444 please.

::: mobile/android/base/resources/values/styles.xml
@@ +442,5 @@
> +        <item name="android:minWidth">@dimen/doorhanger_input_width</item>
> +    </style>
> +
> +    <style name="SpinnerItem" parent="android:style/Widget.TextView.SpinnerItem">
> +        <item name="android:textColor">#000</item>

#FF000000. RGB doesn't feel android-ish. AARRGGBB feels better.

::: mobile/android/base/resources/values/themes.xml
@@ +69,5 @@
>          <item name="android:textAppearanceMediumInverse">@style/TextAppearance.Medium.Inverse</item>
>          <item name="android:textAppearanceSmallInverse">@style/TextAppearance.Small.Inverse</item>
> +
> +        <item name="android:spinnerStyle">@style/Spinner</item>
> +        <item name="android:spinnerItemStyle">@style/SpinnerItem</item>

This is scary. If Settings screen uses a spinner, that would default to this. I would suggest testing it with other activities that might use a spinner. Or better, move it to be with Gecko.App.

@@ -80,5 @@
>          <item name="android:buttonStyle">@style/Widget.Button</item>
>          <item name="android:dropDownItemStyle">@style/Widget.DropDownItem</item>
>          <item name="android:editTextStyle">@style/Widget.EditText</item>
>          <item name="android:spinnerDropDownItemStyle">@style/TextAppearance.Widget.TextView</item>
> -        <item name="android:spinnerItemStyle">@style/Widget.TextView.SpinnerItem</item>

I somehow like naming the style this way. Instead of just a "Spinner". Could you change it in styles.xml? This follows how Android names styles.

Comment 39

[Sriram Ramasubramanian [:sriram]]

Comment on attachment 750775 [details] [diff] [review]
Patch 5/4

Review of attachment 750775 [details] [diff] [review]:
-----------------------------------------------------------------

Merge it with previous patch please.

::: mobile/android/base/PromptInput.java
@@ -271,1 @@
>              mView = (View)mSpinner;

Please do this cleanup with the previous patch.

::: mobile/android/base/resources/layout/doorhanger.xml
@@ +18,5 @@
>                android:layout_width="wrap_content"
>                android:layout_height="wrap_content"
>                android:orientation="vertical"
>                android:gravity="right"
> +              android:paddingLeft="@dimen/doorhanger_padding"

Please do this with the previous patch.

Comment 40

[Wesley Johnston (:wesj)]

Attachment: Patch 4/4 - Styling stuff

> Get this value once, store it in a variable and use it please. Resolving
> these values is always costly. In fact, you could make it a static final, if

We can't really do static final here AFAIK. We need access to a Resources object to initialize things, which means we can't do it in a static context (requires if its static and final). If we do it in the constructor, we have to either just be static of just final. I chose static but not final.

> > +        private Spinner mSpinner;
> > +        public TextView textView;
> This needn't be declared here. Could be a block level variable.

I... don't want to style the textView in here so that we can reuse this in separate contexts. In fact in this case, I needed to do some kinda special styling to make this match ian's designs. That means the caller needs some way to access the inner views to style them.

> Are we using mView anywhere else? If not, please return the
> "container/mSpinner" below. We don't need a cast.

I kinda liked having it defined in case the super class decided to do something with it. But sounds fine until that happens.

> This is scary. If Settings screen uses a spinner, that would default to
> this. I would suggest testing it with other activities that might use a
> spinner. Or better, move it to be with Gecko.App.

Moved this and renamed. Need to test this on GB, but works well on ICS.

Comment 41

[Wesley Johnston (:wesj)]

Attachment: Patch 3/4 - Add spinners to webrtc doorhangers

Updated and folded patch. This is a bit smarter and only shows the "No Video" or "No Audio" options if we have both video and audio options to show (otherwise its redundent with the "Don't Share" button).

Comment 42

[Wesley Johnston (:wesj)]

Attachment: ICS screenshot

Screenshot with the new patch.

Comment 43

[Lucas Rocha (:lucasr)]

Comment on attachment 750736 [details] [diff] [review]
Patch 3/4 - Add spinners to webrtc doorhangers

Review of attachment 750736 [details] [diff] [review]:
-----------------------------------------------------------------

I haven't seen the actual UI but I was wondering: you'll still show a list of devices even when there's only one option, right? It would be nice if the the doorhanger would become simpler if there's only one option for camera and mic. Just show a simpler text instead of a list.

Looks good anyway.

::: mobile/android/chrome/content/WebrtcUI.js
@@ +39,5 @@
> +      callback: function(checked /* ignored */, inputs) {
> +        let allowedDevices = Cc["@mozilla.org/supports-array;1"].createInstance(Ci.nsISupportsArray);
> +
> +        let audioId = 0;
> +        if (inputs && inputs.audioDevice != undefined)

I'd use "inputs.audioDevice !== undefined" just to be safer.

@@ +45,5 @@
> +        if (audioDevices[audioId])
> +          allowedDevices.AppendElement(audioDevices[audioId]);
> +
> +        let videoId = 0;
> +        if (inputs && inputs.videoDevice != undefined)

Ditto.

@@ +59,5 @@
> +
> +  // Get a list of string names for devices. Ensures that none of the strings are blank
> +  _getList: function(aDevices, aType) {
> +    let defaultCount = 0;
> +    return aDevices.map(function(device) {

I assume device.name is never null here?

@@ +76,5 @@
> +
> +  _addDevicesToOptions: function(aDevices, aType, aOptions) {
> +    if (aDevices.length) {
> +
> +      // Filter out empty items from the list

Well, it's more like "Ensure there are no empty device names in the list", no?

Comment 44

[Wesley Johnston (:wesj)]

(In reply to Lucas Rocha (:lucasr) from comment #43)
> I haven't seen the actual UI but I was wondering: you'll still show a list
> of devices even when there's only one option, right? It would be nice if the
> the doorhanger would become simpler if there's only one option for camera
> and mic. Just show a simpler text instead of a list.

Yeah. That should work with this patch.

Comment 47

[Ian Barlow (:ibarlow)]

(In reply to Wesley Johnston (:wesj) from comment #42)
> Created attachment 753626 [details]
> ICS screenshot
> 
> Screenshot with the new patch.

This looks excellent. Can we adjust the picker strings to be sentence case, and read "Front facing camera" and "Rear facing camera"?

Comment 48

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Ian Barlow (:ibarlow) from comment #47)
> (In reply to Wesley Johnston (:wesj) from comment #42)
> > Created attachment 753626 [details]
> > ICS screenshot
> > 
> > Screenshot with the new patch.
> 
> This looks excellent. Can we adjust the picker strings to be sentence case,
> and read "Front facing camera" and "Rear facing camera"?

L10N String Length Police: Can we drop "camera"? or "facing"? I'm worried about long L10N translations.

Maybe we could add a note for L10N people: "Try to keep the strings short. Consider dropping words".

Comment 49

[Ian Barlow (:ibarlow)]

> L10N String Length Police: Can we drop "camera"? or "facing"? I'm worried
> about long L10N translations.

Yes, Officer L1on -- we can drop camera. :)

> 
> Maybe we could add a note for L10N people: "Try to keep the strings short.
> Consider dropping words".

Also a good idea, even as a more general comment l10n folks

Comment 50

[Wesley Johnston (:wesj)]

Attachment: Patch 3/4 - Add spinners to webrtc doorhangers

Updated the strings. Lucas, you didn't mark this + or - before, so I'm re-requesting to make sure I didn't miss something?

Comment 51

[Wesley Johnston (:wesj)]

Attachment: Patch 3/4 - Add spinners to webrtc doorhangers

And this one is qref'ed.

Comment 52

[Wesley Johnston (:wesj)]

Attachment: Patch 4/4 - Styling stuff

This updates the style patch to work better on Gingerbread:

http://dl.dropboxusercontent.com/u/72157/gumGingerbread.png

It also fixes a bug where the list that shows up was pretty ugly on gingerbread by removing some styling we aren't using anymore.

Comment 53

[Wesley Johnston (:wesj)]

Comment on attachment 754995 [details] [diff] [review]
Patch 4/4 - Styling stuff

One other thing. Before we advertise this to addons devs, I need to run some tests with other inputs. This really only cares about how spinners look. I'm going to file a separate bug for that.

Comment 54

[Lucas Rocha (:lucasr)]

Comment on attachment 754993 [details] [diff] [review]
Patch 3/4 - Add spinners to webrtc doorhangers

Review of attachment 754993 [details] [diff] [review]:
-----------------------------------------------------------------

Nice.

Comment 55

[Wesley Johnston (:wesj)]

Attachment: Screenshot to explain padding

This has some arrows and colors to (hopefully) help explain the padding calculations in here...

Comment 56

[Sriram Ramasubramanian [:sriram]]

Comment on attachment 754995 [details] [diff] [review]
Patch 4/4 - Styling stuff

Review of attachment 754995 [details] [diff] [review]:
-----------------------------------------------------------------

Overall looks good. Just a few renaming variable names and good to be landed.
r+ with changes mentioned in review comments.

::: mobile/android/base/DoorHanger.java
@@ +53,5 @@
>  
>      private int mPersistence = 0;
>      private boolean mPersistWhileVisible = false;
>      private long mTimeout = 0;
> +    private static int mInputPadding = -1;

Why "static" here? If needed, use "sInputPadding".

@@ +72,5 @@
> +        if (mSpinnerTextColor == -1) {
> +            mSpinnerTextColor = getResources().getColor(R.color.text_color_primary_disable_only);
> +        }
> +        if (mSpinnerTextSize == -1) {
> +            mSpinnerTextSize = getResources().getDimensionPixelSize(R.dimen.doorhanger_spinner_textsize);

These values won't change for a device between orientation right?

Then better implemented as,

private static int sSpinnerTextSize;

static {
    sSpinnerTextSize = getResources().getDimension...();
}

... constructor follows ...

@@ +248,5 @@
> +            styleSpinner(input, view);
> +        } else {
> +            // add some top and bottom padding to separate inputs
> +            view.setPadding(0, mInputPadding,
> +                            0, mInputPadding);

If there are two inputs, and say mInputPadding has a value of 5dp,
won't we have 5dp on top, 10dp in between and 5dp at the bottom?

@@ +254,5 @@
> +    }
> +
> +    private void styleSpinner(PromptInput input, View view) {
> +        PromptInput.MenulistInput spinInput = (PromptInput.MenulistInput) input;
> +        // Spinners have some intrinsic padding of their own. This aligns things so that

Change comment to something like:

/* Spinners have some intrinsic padding. Use this with spinner label text and
 * doorhanger text to align them.
 */

A new line before the comment please.

@@ +256,5 @@
> +    private void styleSpinner(PromptInput input, View view) {
> +        PromptInput.MenulistInput spinInput = (PromptInput.MenulistInput) input;
> +        // Spinners have some intrinsic padding of their own. This aligns things so that
> +        // the spinner text, spinner label text, and main doorhanger text are all aligned
> +

Could you add some ASCII art of the padding here? This would make things easier.

Something like:

  |-------------| <-- Doorhanger padding.
  |-A-|-B-|--C--| <-- Spinner to be aligned.

  A - Required padding to align (doorhangerPadding).
  B - Spinner drawable padding (rect.left).
  C - Spinner (dropdown?) text padding (textPadding).

(I know, I am asking too much. But, 2 months down the lane, we won't understand what's happening here :( ).

@@ +259,5 @@
> +        // the spinner text, spinner label text, and main doorhanger text are all aligned
> +
> +        // First get the padding of the selected view inside the spinner. Since the spinner
> +        // hasn't been shown yet, we get this view directly from the adapter.
> +        SpinnerAdapter a = spinInput.spinner.getAdapter();

Store spinInput.spinner to a variable, say spinner. This is getting used many times.

@@ +261,5 @@
> +        // First get the padding of the selected view inside the spinner. Since the spinner
> +        // hasn't been shown yet, we get this view directly from the adapter.
> +        SpinnerAdapter a = spinInput.spinner.getAdapter();
> +        View dropView = a.getView(0, null, spinInput.spinner);
> +        int left = 0;

"textPadding" please.

@@ +266,5 @@
> +        if (dropView != null) {
> +            left = dropView.getPaddingLeft();
> +        }
> +
> +        // Then get the intrinsic padding built into the background image of the spinner.

Move this below the padding for the doorhanger. That makes the comment go with the actual code.

@@ +267,5 @@
> +            left = dropView.getPaddingLeft();
> +        }
> +
> +        // Then get the intrinsic padding built into the background image of the spinner.
> +        int p = getResources().getDimensionPixelSize(R.dimen.doorhanger_padding);

Add a different comment here.
"Padding for the doorhanger text".
And may be name it to "doorhangerPadding". That makes it clear.

@@ +273,5 @@
> +        spinInput.spinner.getBackground().getPadding(rect);
> +
> +        // Now offset the entire spinner view enough so that when the background drawable
> +        // padding and the textview's padding are added, the text is aligned
> +        // with the doorhanger text.

"Set the difference in padding to the spinner view to align it with doorhanger text."

@@ +278,5 @@
> +        view.setPadding(p - rect.left - left, 0, rect.right, mInputPadding);
> +
> +        if (spinInput.textView != null) {
> +            spinInput.textView.setTextColor(mSpinnerTextColor);
> +            spinInput.textView.setTextSize(mSpinnerTextSize);

And I guess this should go with global theme style. We don't use spinners anywhere else.

::: mobile/android/base/PromptInput.java
@@ +280,5 @@
> +                container.addView(spinner);
> +                return container;
> +            }
> +
> +            return spinner;

Could we make these as layout XMLs? Adding elements in Java feels like doing servlet code :(
May be a followup, please.

::: mobile/android/base/resources/values/styles.xml
@@ +437,5 @@
> +    <style name="Widget.Spinner" parent="android:style/Widget.Spinner">
> +        <item name="android:minWidth">@dimen/doorhanger_input_width</item>
> +    </style>
> +
> +    <style name="Widget.TextView.SpinnerItem" parent="android:style/Widget.TextView.SpinnerItem"/>

Could you move it so that all "Widget." styles stay closer?

::: mobile/android/base/resources/values/themes.xml
@@ +80,5 @@
>          <item name="android:buttonStyle">@style/Widget.Button</item>
>          <item name="android:dropDownItemStyle">@style/Widget.DropDownItem</item>
>          <item name="android:editTextStyle">@style/Widget.EditText</item>
> +        <item name="android:textViewStyle">@style/Widget.TextView</item>
> +

Remove this newline.

Comment 57

[Sriram Ramasubramanian [:sriram]]

I might be wrong in using "getResources() in a "static" block. If so, please move it to the constructor. Anyways, "sInputPadding" (and other "s") renaming holds :)

Comment 58

[Wesley Johnston (:wesj)]

Grr. Forgot the last set of comments. Will push one last patch to fix 'em:

https://hg.mozilla.org/integration/mozilla-inbound/rev/6aefa02e952e
https://hg.mozilla.org/integration/mozilla-inbound/rev/a9bb036dbfcb
https://hg.mozilla.org/integration/mozilla-inbound/rev/306323d8318c
https://hg.mozilla.org/integration/mozilla-inbound/rev/87e72452cd1a

Comment 59

[Wesley Johnston (:wesj)]

Comments:
https://hg.mozilla.org/integration/mozilla-inbound/rev/45ae4fc68b89

Comment 60

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/87e72452cd1a
https://hg.mozilla.org/mozilla-central/rev/306323d8318c
https://hg.mozilla.org/mozilla-central/rev/a9bb036dbfcb
https://hg.mozilla.org/mozilla-central/rev/6aefa02e952e
https://hg.mozilla.org/mozilla-central/rev/45ae4fc68b89