Closed
Bug 754958
Opened 11 years ago
Closed 11 years ago
Pairing aborts if device screen turns off
Categories
(Firefox for Android Graveyard :: Android Sync, defect, P1)
Tracking
(firefox14 fixed, blocking-fennec1.0 +)
VERIFIED
FIXED
mozilla15
People
(Reporter: netoarmando, Assigned: liuche)
References
Details
Attachments
(3 files)
6.90 KB,
text/plain
|
Details | |
4.36 KB,
text/plain
|
Details | |
4.45 KB,
patch
|
mfinkle
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
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•11 years ago
|
||
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
Reporter | ||
Comment 2•11 years ago
|
||
Reporter | ||
Comment 3•11 years ago
|
||
Reporter | ||
Comment 4•11 years ago
|
||
(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.
Updated•11 years ago
|
Component: General → Android Sync
Product: Fennec Native → Mozilla Services
QA Contact: general → android-sync
Version: Firefox 15 → unspecified
Assignee | ||
Updated•11 years ago
|
Summary: sync: cannot pair device due screen timeout → Pairing aborts if device screen turns off
Updated•11 years ago
|
Priority: -- → P1
Comment 5•11 years ago
|
||
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
Assignee | ||
Updated•11 years ago
|
Whiteboard: [needs review: rnewman/nalexander]
Comment 7•11 years ago
|
||
(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.
Assignee | ||
Comment 8•11 years ago
|
||
Orientation changes creating new J-PAKE codes is a regression tracked by Bug 755935, unrelated to aborting sync on screen sleep.
Comment 9•11 years ago
|
||
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: --- → ?
Comment 10•11 years ago
|
||
(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.
Updated•11 years ago
|
Assignee: nobody → liuche
Status: NEW → ASSIGNED
Whiteboard: [needs review: rnewman/nalexander]
Comment 11•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/6a002ac9ea6c
Whiteboard: [fixed in inbound; sorry sheriff for whiteboard spam]
Target Milestone: --- → mozilla15
Updated•11 years ago
|
status-firefox14:
--- → affected
Comment 12•11 years ago
|
||
Just landed on inbound; setting flags in the expectation of this being marked as blocking during triage.
Attachment #625180 -
Flags: approval-mozilla-aurora?
Updated•11 years ago
|
blocking-fennec1.0: ? → +
Comment 13•11 years ago
|
||
Are we sure the screen is reset if the JPAKE process fails too?
blocking-fennec1.0: + → ?
Comment 14•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/6a002ac9ea6c
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Updated•11 years ago
|
Whiteboard: [fixed in inbound; sorry sheriff for whiteboard spam]
Comment 15•11 years ago
|
||
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•11 years ago
|
||
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
Updated•11 years ago
|
blocking-fennec1.0: ? → +
Updated•11 years ago
|
Attachment #625180 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 18•11 years ago
|
||
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•11 years ago
|
||
(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•11 years ago
|
||
(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.
Updated•10 years ago
|
Product: Mozilla Services → Android Background Services
Updated•5 years ago
|
Product: Android Background Services → Firefox for Android
Updated•2 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•