754958 - Pairing aborts if device screen turns off

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Android Sync, defect, P1)

Description

[Armando Neto [:netoarmando]]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/15.0 Firefox/15.0a1
Build ID: 20120513030522

Steps to reproduce:

When I try to pair my device its shown 3 codes to insert on my desktop instance of Firefox. I inserted the codes, clicked on 'Continue'. Now my device and desktop is 'working'.


Actual results:

While the pairing is happening, the screen of my device turns off. My desktop shows a confirmation message. I press my device's home button, And now It shows a new set of codes, not the same as before, and my device is not paired.




Expected results:

The pairing process should not stop if screen goes off.

Comment 1

[Reuben Morais [:reuben]]

I can reproduce this on today's Nightly.

STR:
1) On a fresh profile, open the Add a Firefox Sync Account wizard.
2) Type the code in your Firefox Desktop "Pair a Device" dialog.
3) Wait for phone to lock.
4) Press Continue in Firefox Desktop.

Results:
"Please try again" on Desktop dialog, unlocking the phone screen shows a different code.

We should hold a wake lock while the user is typing the code in his desktop or just not generate new codes on window focus.

Comment 2

[Armando Neto [:netoarmando]]

Attachment: log for 'screen turned off'

Comment 3

[Armando Neto [:netoarmando]]

Attachment: log for 'screen turned on all the time'

Comment 4

[Armando Neto [:netoarmando]]

(In reply to Armando Neto from comment #3)
> Created attachment 623779 [details]
> log for 'screen turned on all the time'

(In reply to Armando Neto from comment #2)
> Created attachment 623778 [details]
> log for 'screen turned off'

The screen was turned off when the two attached files start to differ.

Comment 5

[Allison Naaktgeboren :ally]

Sync triage: p1, Preliminary thinking: the wake lock is the way to go on this one. http://developer.android.com/reference/android/os/PowerManager.html

Comment 7

[Reuben Morais [:reuben]]

(In reply to :Ally Naaktgeboren from comment #5)
> Sync triage: p1, Preliminary thinking: the wake lock is the way to go on
> this one. http://developer.android.com/reference/android/os/PowerManager.html

Orientation changes also create new codes and abort the pairing, so there's probably more to it than holding the wake lock.

Comment 8

[Chenxia Liu [:liuche]]

Orientation changes creating new J-PAKE codes is a regression tracked by Bug 755935, unrelated to aborting sync on screen sleep.

Comment 9

[Tony Chung [:tchung]]

People are seeing this on beta 1 now, and bringing this up.   It's not hard to reproduce, since many android phones default with only 1 minute screen lock.

Comment 10

[Tony Chung [:tchung]]

(In reply to Tony Chung [:tchung] from comment #9)
> People are seeing this on beta 1 now, and bringing this up.   It's not hard
> to reproduce, since many android phones default with only 1 minute screen
> lock.

i stand corrected, it's more like 20-30secs on default.

Comment 11

[Richard Newman [:rnewman]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6a002ac9ea6c

Comment 12

[Richard Newman [:rnewman]]

Attachment: Aurora uplift.

Just landed on inbound; setting flags in the expectation of this being marked as blocking during triage.

Comment 13

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

Are we sure the screen is reset if the JPAKE process fails too?

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/6a002ac9ea6c

Comment 15

[Richard Newman [:rnewman]]

Mark, did you intend to re-? this one 30 seconds after johnath +ed it?

(In reply to Mark Finkle (:mfinkle) from comment #13)
> Are we sure the screen is reset if the JPAKE process fails too?

If you mean "does another J-PAKE code get generated if the channel fails": it should be, but it should certainly be on the routine QA list for both desktop and mobile.

This bug is part of a set where the view gets rebuilt more frequently than it should.

Comment 16

[Tracy Walker [:tracy]]

with nightly build, in J-PAKE code screen, device doesn't go to sleep. Code is regenerated after five minutes of inactivity, as expected.

manually sleeping device and unlocking it, causes new code to be generated.  But tht is expected.

Comment 17

[Richard Newman [:rnewman]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/89fe604e9e28

Comment 18

[Catalin Suciu [:csuciu]]

I tested this on the latest builds and this are my findings:

On Nightly 15.0a1 (2012-05-24) 
On Aurora 14.a02 (2012-05-24)
On Beta 14.0b3 buid2

       - in J-PAKE code screen, device doesn't go to sleep and the code is regenerated after five minutes of inactivity - expected
       - manually sleeping device and unlocking it, doesn't generate new code - This is NOT expected according to comment #16

Comment 19

[Tracy Walker [:tracy]]

(In reply to Catalin Suciu from comment #18)

>        - manually sleeping device and unlocking it, doesn't generate new
> code - This is NOT expected according to comment #16

I am not 100% certain about the expected behavior in manual put to sleep.  Devs?

Comment 20

[Richard Newman [:rnewman]]

(In reply to Tracy Walker [:tracy] from comment #19)

> I am not 100% certain about the expected behavior in manual put to sleep. 
> Devs?

IMO manual sleep should not regenerate a new code. A new code should be produced after five minutes regardless.