Closed Bug 754958 Opened 9 years ago Closed 9 years ago

Pairing aborts if device screen turns off

Categories

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

ARM
Android
defect

Tracking

(firefox14 fixed, blocking-fennec1.0 +)

VERIFIED FIXED
mozilla15
Tracking Status
firefox14 --- fixed
blocking-fennec1.0 --- +

People

(Reporter: netoarmando, Assigned: liuche)

References

Details

Attachments

(3 files)

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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → Android
Hardware: x86 → ARM
(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.
Component: General → Android Sync
Product: Fennec Native → Mozilla Services
QA Contact: general → android-sync
Version: Firefox 15 → unspecified
Summary: sync: cannot pair device due screen timeout → Pairing aborts if device screen turns off
Priority: -- → P1
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
Duplicate of this bug: 755422
Whiteboard: [needs review: rnewman/nalexander]
(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.
Orientation changes creating new J-PAKE codes is a regression tracked by Bug 755935, unrelated to aborting sync on screen sleep.
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.
blocking-fennec1.0: --- → ?
(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.
Assignee: nobody → liuche
Status: NEW → ASSIGNED
Whiteboard: [needs review: rnewman/nalexander]
https://hg.mozilla.org/integration/mozilla-inbound/rev/6a002ac9ea6c
Whiteboard: [fixed in inbound; sorry sheriff for whiteboard spam]
Target Milestone: --- → mozilla15
Attached patch Aurora uplift.Splinter Review
Just landed on inbound; setting flags in the expectation of this being marked as blocking during triage.
Attachment #625180 - Flags: approval-mozilla-aurora?
blocking-fennec1.0: ? → +
Are we sure the screen is reset if the JPAKE process fails too?
blocking-fennec1.0: + → ?
https://hg.mozilla.org/mozilla-central/rev/6a002ac9ea6c
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Whiteboard: [fixed in inbound; sorry sheriff for whiteboard spam]
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.
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.
Status: RESOLVED → VERIFIED
blocking-fennec1.0: ? → +
Attachment #625180 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
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
(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?
(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.
Product: Mozilla Services → Android Background Services
Product: Android Background Services → Firefox for Android
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.