Closed
Bug 1017506
Opened 10 years ago
Closed 10 years ago
[Settings][Bluetooth] The un-pair devices dialog(modal) could be closed by clicking on places other than the buttons
Categories
(Firefox OS Graveyard :: Gaia::Settings, defect)
Tracking
(tracking-b2g:backlog, b2g-v1.3 affected, b2g-v1.3T affected, b2g-v1.4 affected, b2g-v2.0 verified, b2g-v2.1 verified)
RESOLVED
FIXED
tracking-b2g | backlog |
People
(Reporter: greatwall2686, Assigned: iliu)
References
Details
(Whiteboard: torch)
Attachments
(4 files)
102.52 KB,
application/x-rar
|
Details | |
54.14 KB,
application/x-7z-compressed
|
Details | |
46 bytes,
text/x-github-pull-request
|
arthurcc
:
review+
bajaj
:
approval-gaia-v1.3-
bajaj
:
approval-gaia-v1.4-
bajaj
:
approval-gaia-v2.0+
|
Details | Review |
1.55 MB,
video/3gpp
|
Details |
* Description: Paired with another phone, then trying to unpair it. But there is no response when tap 'Confirm' to unpair the device. The device is still displayed under Paired device list.This issue maybe occurs when first time using Bluetooth function. The device can be unpaired after you restart the phone. logcat file is attached. * Precontion: * Reproduction steps: 1. Go to settings and scroll down to Bluetooth section. 2. Enable Bluetooth and Visible to all. 3. Pair with another phone which bluetooth has been enabled.( Sometimes it can't pair successfully at once, try again.) 4. Trying to unpair the device has been paired. Check the result. * Expected result: The device should be unpaired successfully. * Actual result: There is no response when tap 'Confirm' to unpair the device. The device is still displayed under Paired device list. * Reproduction build:(Buri - Firefox OS V2.0 inside) - Gaia 17b102ee8d9a724b62285547cc5f1c5d30bfb01c - Gecko https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/95be84248033 - BuildID 20140520000201 - Version 30.0 * Reproduction Frequency - 10% This issue has been reproduced on 2 devices. But it looks like only occurs when first time using bluetooth function. It can't be reproduced after using BT function.The device also can be unpaired successfully after restart it.( We use Flame to pair with HTC T329W in testing.)
Reporter | ||
Comment 1•10 years ago
|
||
Paired with HTC T329w, then unpair it, it can't be unpaired. This bcidump doesn't include the whole process, just include the unpair process.
Comment 2•10 years ago
|
||
Can this be reproduced on 1.3? Can someone else confirm reproduction on 1.4?
Keywords: qawanted
Updated•10 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
The issue DOES reproduce on the 1.4 Flame. The issue does not reproduce on the 1.3 Flame. 1.4 Environmental Variables: Device: Flame 1.4 Build ID: 20140609000201 Gaia: 8b239e41bbd85aa7b6a2c5d388e775ba7de6fb2b Gecko: e3f85877db29 Version: 30.0 (1.4) Firmware Version: v10G-2 1.3 Environmental Variables: Device: Flame 1.3 Build ID: 20140520094859 Gaia: a73235d23685e9898f40647cebd83b3fcbfd0117 Gecko: b637b0677e15318dcce703f0358b397e09b018af Version: 28.0 (1.3) Firmware Version: v10G-2 1.3 Environmental Variables: Device: Buri 1.3 Build ID: 20140607024002 Gaia: e049de79ff46fcab51f29a88d5869c5efb48fc3c Gecko: 90e7f697961a Version: 28.0 (1.3) MOZ Firmware Version: v1.2device.cfg
Keywords: qawanted
QA Contact: bmorgan
Comment 4•10 years ago
|
||
I can reproduce it using v1.4 flame(not 100%). I will take a look first.
Assignee: nobody → joliu
Updated•10 years ago
|
blocking-b2g: --- → 1.4?
Keywords: regression,
regressionwindow-wanted
Comment 5•10 years ago
|
||
When this bug is reproduced, I found that BluetoothAdapter::Unpair wasn't called at all. (The method that will be runned if gaia call defaultAdapter.unpair().)
(In reply to jocelyn [:jocelyn] from comment #5) > When this bug is reproduced, I found that BluetoothAdapter::Unpair wasn't > called at all. > (The method that will be runned if gaia call defaultAdapter.unpair().) Hmm... This is something like Bug 946092? Jocelyn, can you add logs as https://bugzilla.mozilla.org/show_bug.cgi?id=946092#c4 mentioned? I'm not sure they are the same case (as it used to be 100% on tablet), but maybe we can try it to narrow down the problem.
Comment 7•10 years ago
|
||
This can be easily reproduced when you tab the button close to the corner. (for example, at the buttom or close to the right) In that case, we will enter https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/js/bluetooth.js#L304 and close the dialog instead of requesting unpair to gecko. Tested on buri, nexus5, and Flame, both reproduced, not only on 1.4. bmorgan, could you verify that is this the case when you reproduce the bug? Shawn, this information is quite helpful, thanks!
Flags: needinfo?(bmorgan)
I really think gaia shall try to avoid this kind of design. It's easy to hit this bug at the edge of confirm button.
Comment 9•10 years ago
|
||
This is a gaia issue. A modal dialog should not be closed by clicking on places other than the buttons.
Comment 10•10 years ago
|
||
(In reply to jocelyn [:jocelyn] from comment #7) > This can be easily reproduced when you tab the button close to the corner. > (for example, at the buttom or close to the right) > In that case, we will enter > https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/js/bluetooth. > js#L304 > and close the dialog instead of requesting unpair to gecko. > Tested on buri, nexus5, and Flame, both reproduced, not only on 1.4. > > bmorgan, could you verify that is this the case when you reproduce the bug? > > Shawn, this information is quite helpful, thanks! bmorgan no longer works for us, so I'll flag qawanted to get someone to answer this.
Component: Bluetooth → Gaia::Bluetooth File Transfer
Flags: needinfo?(bmorgan)
Keywords: regressionwindow-wanted → qawanted
Assignee | ||
Comment 11•10 years ago
|
||
As comment 9, this is pretty wired. A modal dialog is able to be closed by clicking on places other than the buttons... I guess the issue is existed for a long time when the un-pair functionality landed in settings app.
Assignee: joliu → nobody
status-b2g-v1.3:
--- → affected
status-b2g-v1.3T:
--- → affected
status-b2g-v1.4:
--- → affected
status-b2g-v2.0:
--- → affected
status-b2g-v2.1:
--- → affected
Component: Gaia::Bluetooth File Transfer → Gaia::Settings
Summary: [Flame][v1.4][Bluetooth]Bluetooth devices can't be unpaired. → [Settings][Bluetooth] The un-pair devices dialog(modal) could be closed by clicking on places other than the buttons
(In reply to Ian Liu [:ianliu] from comment #11) > As comment 9, this is pretty wired. A modal dialog is able to be closed by > clicking on places other than the buttons... I guess the issue is existed > for a long time when the un-pair functionality landed in settings app. Ian, if you have time, can you also check Bug 946092? It's pretty bad on tablet for users, press 'confirm button' and close dialog, even user press exact 'confirm' button. I understand tablet is not our 1st priority, but somehow breaks very basic unpair function.
Assignee | ||
Comment 13•10 years ago
|
||
Shawn, I don't experience the issue on tablet. Does it have the same symptom? And do we use Gaia/master for tablet project now? Thanks.
(In reply to Ian Liu [:ianliu] from comment #13) > Shawn, I don't experience the issue on tablet. Does it have the same > symptom? And do we use Gaia/master for tablet project now? Thanks. Thanks! It looks like master fix Bug 946092.
Let's focus on the original bug, please ignore my comment on Comment 12.
Comment 16•10 years ago
|
||
Although this is a regression issue the repro rate seems low on the Flame. Hence backlog, please re-nom if seen again.
blocking-b2g: 1.4? → backlog
Comment 17•10 years ago
|
||
(In reply to Preeti Raghunath(:Preeti) from comment #16) > Although this is a regression issue the repro rate seems low on the Flame. > Hence backlog, please re-nom if seen again. This is wrong. A low repro rate where you have an unresponsive button to shut off bluetooth is poor UX. comment 11's analysis is also incorrect, because we already tested and confirmed that this does not reproduce on 1.3.
Comment 18•10 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #17) > (In reply to Preeti Raghunath(:Preeti) from comment #16) > > Although this is a regression issue the repro rate seems low on the Flame. > > Hence backlog, please re-nom if seen again. > > This is wrong. A low repro rate where you have an unresponsive button to > shut off bluetooth is poor UX. comment 11's analysis is also incorrect, > because we already tested and confirmed that this does not reproduce on 1.3. I missed the comment above this being 10% reproducible, so I'll move the flag here.
blocking-b2g: 1.4? → backlog
(In reply to Jason Smith [:jsmith] from comment #17) > (In reply to Preeti Raghunath(:Preeti) from comment #16) > > Although this is a regression issue the repro rate seems low on the Flame. > > Hence backlog, please re-nom if seen again. > > This is wrong. A low repro rate where you have an unresponsive button to > shut off bluetooth is poor UX. comment 11's analysis is also incorrect, > because we already tested and confirmed that this does not reproduce on 1.3. It depends on how you press the 'Confirm' button. If you press the edge of the button, you can hit this bug easily.
Assignee | ||
Comment 20•10 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #17) > (In reply to Preeti Raghunath(:Preeti) from comment #16) > > Although this is a regression issue the repro rate seems low on the Flame. > > Hence backlog, please re-nom if seen again. > > This is wrong. A low repro rate where you have an unresponsive button to > shut off bluetooth is poor UX. comment 11's analysis is also incorrect, > because we already tested and confirmed that this does not reproduce on 1.3. I'm able to reproduce it on 1.3/1.3t as following build version. I think the reproduced rate is depended on how your press the 'Confirm' button. Shawn is right as comment 19. And the code base is never changed before when the un-pair feature landed. (I believe the issue is also existed on 1.1/1.2.) === 1.3 on inari === Gaia 0ce948e378cab7ed3db20231281dd7ca2eb99779 Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/ee779e37aca1 BuildID 20140520024003 Version 28.0 ro.build.version.incremental=eng.cltbld.20140520.065121 ro.build.date=Tue May 20 06:51:35 EDT 2014 === 1.3t on tarako === Gaia df364e84fefa6f09c6a6828c21126441f424ef91 Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/d86296dc1da6 BuildID 20140608164003 Version 28.1 ro.build.version.incremental=eng.kaizhen.20140425.155902 ro.build.date=Fri Apr 25 15:59:09 CST 2014 Somehow, this is not a blocking issue. But it's really a poor UX issue since hard to click on 'Confirm' bottom. Especially, small resolution device, small height of the 'Confirm' button. Because the region of binding touch-div is smaller than human's finger while pressing on the button. In this case, a user is more easy to press on confirm dialog(trigger 'Close' dialog). In other words, it means a user cannot un-pair device sometimes. I think we have to fix it on master/2.0(recent build). And if the patch is safety enough, we might consider uplift the patch for 1.4/1.3/1.3t. Jason, do you agree?
Comment 21•10 years ago
|
||
Yeah, that makes sense to me. Let's get a patch here & get approval at least for 2.0.
Keywords: qawanted
Assignee | ||
Comment 22•10 years ago
|
||
Per comment 20, revise flags for tracking.
Assignee: nobody → iliu
Status: NEW → ASSIGNED
status-b2g-v1.3:
--- → affected
status-b2g-v1.3T:
--- → affected
Keywords: regression
Assignee | ||
Comment 23•10 years ago
|
||
Arthur, could you please help to review the pull request? Thanks.
Attachment #8438985 -
Flags: review?(arthur.chen)
Comment 24•10 years ago
|
||
Comment on attachment 8438985 [details] [review] pull request 20415 r=me, thanks!
Attachment #8438985 -
Flags: review?(arthur.chen) → review+
Assignee | ||
Comment 25•10 years ago
|
||
Thanks for Arthur's reviewing effort. Since the patch is landed, we can close the issue now. Gaia/master: aa125bd4f448c65c94fca678ead21f6e68d239fc
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•10 years ago
|
Assignee | ||
Comment 26•10 years ago
|
||
Comment on attachment 8438985 [details] [review] pull request 20415 NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings. [Approval Request Comment] Poor UX making a user feel hard to un-pair device. [Bug caused by] (feature/regressing bug #): Defect [User impact] if declined: Sometimes, a user will think he/she has to press the 'un-pair' button. In fact, he/she clicked on the dialog only.(trigger close dialog only) [Testing completed]: Manual. [Risk to taking this patch] (and alternatives if risky): Low. [String changes made]: None.
Attachment #8438985 -
Flags: approval-gaia-v2.0?(hochang)
Attachment #8438985 -
Flags: approval-gaia-v1.4?(hochang)
Attachment #8438985 -
Flags: approval-gaia-v1.3?(hochang)
Comment 27•10 years ago
|
||
Comment on attachment 8438985 [details] [review] pull request 20415 Its too late to get this landed on 1.3/1.4 , looks low risk enough to land on 2.0..approving.
Attachment #8438985 -
Flags: approval-gaia-v2.0?(hochang)
Attachment #8438985 -
Flags: approval-gaia-v2.0+
Attachment #8438985 -
Flags: approval-gaia-v1.4?(hochang)
Attachment #8438985 -
Flags: approval-gaia-v1.4-
Attachment #8438985 -
Flags: approval-gaia-v1.3?(hochang)
Attachment #8438985 -
Flags: approval-gaia-v1.3-
Assignee | ||
Comment 28•10 years ago
|
||
Gaia/v2.0: a6988c15b361938bea5976c846c147ecdc1121c0
Comment 30•10 years ago
|
||
This issue has been successfully verified on Flame 2.1, 2.0 See attachment:verify21.3gp Reproducing rate: 0/5 Flame 2.1 build: Gaia-Rev 38e17b0219cbc50a4ad6f51101898f89e513a552 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/8b92c4b8f59a Build-ID 20141205001201 Version 34.0 Flame 2.0 new build: Gaia-Rev 856863962362030174bae4e03d59c3ebbc182473 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/e40fe21e37f1 Build-ID 20141208000206 Version 32.0
Updated•10 years ago
|
Updated•9 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
You need to log in
before you can comment on or make changes to this bug.
Description
•