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)

ARM
Gonk (Firefox OS)
defect
Not set
normal

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
Tracking Status
b2g-v1.3 --- affected
b2g-v1.3T --- affected
b2g-v1.4 --- affected
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: greatwall2686, Assigned: iliu)

References

Details

(Whiteboard: torch)

Attachments

(4 files)

Attached file bluetooth unpair.rar
* 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.)
Attached file unpair hcidump.7z
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.
Can this be reproduced on 1.3? Can someone else confirm reproduction on 1.4?
Keywords: qawanted
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
I can reproduce it using v1.4 flame(not 100%).
I will take a look first.
Assignee: nobody → joliu
blocking-b2g: --- → 1.4?
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.
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.
This is a gaia issue. A modal dialog should not be closed by clicking on places other than the buttons.
(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)
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
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.
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.
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
(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.
blocking-b2g: backlog → 1.4?
(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.
(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?
Yeah, that makes sense to me. Let's get a patch here & get approval at least for 2.0.
Keywords: qawanted
Per comment 20, revise flags for tracking.
Assignee: nobody → iliu
Status: NEW → ASSIGNED
Keywords: regression
Attached file pull request 20415
Arthur, could you please help to review the pull request? Thanks.
Attachment #8438985 - Flags: review?(arthur.chen)
Comment on attachment 8438985 [details] [review]
pull request 20415

r=me, thanks!
Attachment #8438985 - Flags: review?(arthur.chen) → review+
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
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 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-
Gaia/v2.0:  a6988c15b361938bea5976c846c147ecdc1121c0
Attached video verify21.3gp
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
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: