Re-enable ScreenOrientationProviderTest with flakyness fixes.

Re-enable ScreenOrientationProviderTest with flakyness fixes.

The fixes consist of locking on the UI thread and  wait for idle sync
after a lock

BUG=353500
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=287337

[mlamouri (slow - plz ping), 2014-08-04 11:19:45]

Peter, can you have a quick look?

[Peter Beverloo, 2014-08-04 11:29:09]

https://codereview.chromium.org/429173004/diff/20001/content/public/android/j...
File
content/public/android/javatests/src/org/chromium/content/browser/ScreenOrientationProviderTest.java
(right):

https://codereview.chromium.org/429173004/diff/20001/content/public/android/j...
content/public/android/javatests/src/org/chromium/content/browser/ScreenOrientationProviderTest.java:70:
fail("Should not be there! " + e);
Please use a somewhat saner string :-).

https://codereview.chromium.org/429173004/diff/20001/content/public/android/j...
content/public/android/javatests/src/org/chromium/content/browser/ScreenOrientationProviderTest.java:75:
// this if it doesn't flakes the test.
How much does it slow the tests down?

https://codereview.chromium.org/429173004/diff/20001/content/public/android/j...
content/public/android/javatests/src/org/chromium/content/browser/ScreenOrientationProviderTest.java:100:
ScreenOrientationProvider.unlockOrientation();
It feels kind of odd to call lockOrientation() on the UI thread, but
unlockOrientation() on "whatever thread". Should this be documented in
ScreenOrientationProvider?

https://codereview.chromium.org/429173004/diff/20001/content/public/android/j...
content/public/android/javatests/src/org/chromium/content/browser/ScreenOrientationProviderTest.java:128:
// an "accurate mode" that will fix this by polling.
Perhaps the second part of this comment ("We will...by polling") should be a
TODO, pointing to a bug?

[mlamouri (slow - plz ping), 2014-08-04 11:41:18]

https://codereview.chromium.org/429173004/diff/20001/content/public/android/j...
File
content/public/android/javatests/src/org/chromium/content/browser/ScreenOrientationProviderTest.java
(right):

https://codereview.chromium.org/429173004/diff/20001/content/public/android/j...
content/public/android/javatests/src/org/chromium/content/browser/ScreenOrientationProviderTest.java:70:
fail("Should not be there! " + e);
On 2014/08/04 11:29:09, Peter Beverloo wrote:
> Please use a somewhat saner string :-).

Done. Actually the try/catch wasn't needed there so I just removed it.

https://codereview.chromium.org/429173004/diff/20001/content/public/android/j...
content/public/android/javatests/src/org/chromium/content/browser/ScreenOrientationProviderTest.java:75:
// this if it doesn't flakes the test.
On 2014/08/04 11:29:09, Peter Beverloo wrote:
> How much does it slow the tests down?

Not much. Unlikely noticeable. It might slow it down because of we need to wait
for idle but that might help for flakyness so as we did for the Listener tests,
I would prefer this to land with it and if the tests are fine experiment without
the call.

https://codereview.chromium.org/429173004/diff/20001/content/public/android/j...
content/public/android/javatests/src/org/chromium/content/browser/ScreenOrientationProviderTest.java:100:
ScreenOrientationProvider.unlockOrientation();
On 2014/08/04 11:29:09, Peter Beverloo wrote:
> It feels kind of odd to call lockOrientation() on the UI thread, but
> unlockOrientation() on "whatever thread". Should this be documented in
> ScreenOrientationProvider?

Hmm, I make sure those calls a run in the UI thread mostly to prevent flakyness.
Obviously, tear down isn't that important with that regards but you are right. I
will run that in the UI thread.

https://codereview.chromium.org/429173004/diff/20001/content/public/android/j...
content/public/android/javatests/src/org/chromium/content/browser/ScreenOrientationProviderTest.java:128:
// an "accurate mode" that will fix this by polling.
On 2014/08/04 11:29:09, Peter Beverloo wrote:
> Perhaps the second part of this comment ("We will...by polling") should be a
> TODO, pointing to a bug?

Done.

[Peter Beverloo, 2014-08-04 11:43:33]

lgtm

On 2014/08/04 11:41:18, Mounir Lamouri wrote:
>
https://codereview.chromium.org/429173004/diff/20001/content/public/android/j...
>
content/public/android/javatests/src/org/chromium/content/browser/ScreenOrientationProviderTest.java:75:
> // this if it doesn't flakes the test.
> On 2014/08/04 11:29:09, Peter Beverloo wrote:
> > How much does it slow the tests down?
> 
> Not much. Unlikely noticeable. It might slow it down because of we need to
wait
> for idle but that might help for flakyness so as we did for the Listener
tests,
> I would prefer this to land with it and if the tests are fine experiment
without
> the call.

Having the code there is fine, the comment just makes it sound like it's a
horrible thing to do which will slow down the world. May as well remove the
comment and file a bug (or write a note) to remind yourself.

[mlamouri (slow - plz ping), 2014-08-04 12:17:58]

The CQ bit was checked by mlamouri@chromium.org

[commit-bot: I haz the power, 2014-08-04 12:18:49]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/mlamouri@chromium.org/429173004/60001

[commit-bot: I haz the power, 2014-08-04 13:29:06]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  android_dbg_triggered_tests on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_dbg_tri...)

[mlamouri (slow - plz ping), 2014-08-04 14:13:43]

The CQ bit was unchecked by mlamouri@chromium.org

[mlamouri (slow - plz ping), 2014-08-04 14:25:27]

The CQ bit was checked by mlamouri@chromium.org

[commit-bot: I haz the power, 2014-08-04 14:25:56]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/mlamouri@chromium.org/429173004/80001

[commit-bot: I haz the power, 2014-08-04 15:36:05]

Change committed as 287337