Comment 1 Sriram Ramasubramanian [:sriram] 2012-07-24 15:47:08 PDT

Created attachment 645548 [details] [diff] [review]
Patch

The problem was depending on child's height -- which is 0 until it is shown for the first time -- which caused the problem.
Hence the ScrollView measured a 0, and then the actual height -- showing the flickering.
Instead, this does an AT_MOST call on preferred height of 75% of screen height. This fixes the problem.

Comment 2 Sriram Ramasubramanian [:sriram] 2012-07-24 15:49:17 PDT

*** Bug 767668 has been marked as a duplicate of this bug. ***

Comment 3 Alex Keybl [:akeybl] 2012-07-24 15:50:30 PDT

Moving the tracking flags over from bug 767668.

Comment 4 Matt Brubeck (:mbrubeck) 2012-07-24 16:19:30 PDT

Comment on attachment 645548 [details] [diff] [review]
Patch

Nice!

>         protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
>+            super.onMeasure(widthMeasureSpec, heightMeasureSpec);
> 
>             DisplayMetrics metrics = new DisplayMetrics();
>             ((Activity) GeckoApp.mAppContext).getWindowManager().getDefaultDisplay().getMetrics(metrics);
> 
>             // heightPixels changes during rotation.
>+            int restrictedHeightSpec = MeasureSpec.makeMeasureSpec((int) (0.75 * metrics.heightPixels), MeasureSpec.AT_MOST);
> 
>             super.onMeasure(widthMeasureSpec, restrictedHeightSpec);
>         }

We're calling super.onMeasure twice now.  Is the first call still useful, or should it be removed?

Comment 5 Sriram Ramasubramanian [:sriram] 2012-07-24 16:21:35 PDT

The first call is still useful. I still removing it and it failed.
So (from my understanding), the first call makes the size to be 100% of its children (which may fill the entire screen). The second call restricts the height to 75%.
We do super.onMeasure() which takes care of setMeasuredDimension().

Comment 6 Sriram Ramasubramanian [:sriram] 2012-07-24 21:35:39 PDT

http://hg.mozilla.org/integration/mozilla-inbound/rev/9f8f2b6e2f8b

Comment 7 Sriram Ramasubramanian [:sriram] 2012-07-24 21:36:27 PDT

Comment on attachment 645548 [details] [diff] [review]
Patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): -
User impact if declined: The menu will take time to show in JB. HTC will have visual glitches.
Testing completed (on m-c, etc.): Landed in m-i on 07/24
Risk to taking this patch (and alternatives if risky): None.
String or UUID changes made by this patch: None.

Comment 8 Ed Morley [:emorley] 2012-07-25 08:09:44 PDT

https://hg.mozilla.org/mozilla-central/rev/9f8f2b6e2f8b

Comment 9 Lukas Blakk [:lsblakk] use ?needinfo 2012-07-25 13:49:07 PDT

Comment on attachment 645548 [details] [diff] [review]
Patch

no risk, mobile only - approving.

Comment 10 Sriram Ramasubramanian [:sriram] 2012-07-27 00:04:40 PDT

Pushed to aurora:
https://hg.mozilla.org/releases/mozilla-aurora/rev/540cd72d8445

Comment 11 Sriram Ramasubramanian [:sriram] 2012-07-27 00:09:19 PDT

Pushed to beta:
https://hg.mozilla.org/releases/mozilla-beta/rev/686479fc0e26

Comment 12 Daniel Asarnow 2012-07-30 14:45:36 PDT

I am still seeing bug 767668 (duplicate of this bug) in Beta. Did the beta update of 7/27 include Sriram's fixes?

Comment 13 Matt Brubeck (:mbrubeck) 2012-07-30 14:49:36 PDT

(In reply to Daniel Asarnow from comment #12)
> I am still seeing bug 767668 (duplicate of this bug) in Beta. Did the beta
> update of 7/27 include Sriram's fixes?

No, it didn't.  This fix will be included in the next beta update (probably later this week).