Closed Bug 1193059 Opened 9 years ago Closed 9 years ago

[Settings][Bluetooth] Unpairing handset confirmation screen does not display relevant bluetooth information

Categories

(Firefox OS Graveyard :: Gaia::Bluetooth, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.5+, b2g-v2.2 unaffected, b2g-master verified)

VERIFIED FIXED
FxOS-S6 (04Sep)
blocking-b2g 2.5+
Tracking Status
b2g-v2.2 --- unaffected
b2g-master --- verified

People

(Reporter: onelson, Assigned: zbraniecki)

References

Details

(Keywords: regression, Whiteboard: [2.5-Daily-Testing], [Spark])

Attachments

(4 files)

Attached image 2015-08-10-17-35-22.png
Description:
When the user attempts to unpair from a paired bluetooth handset, they will observe a dialog prompt appear on screen that displays only the text 'Confirm' for it's description. This does not provide dynamic information to the user the operation they are performing, which is a poor user experience. Seems to be state dependent, as this issue is more likely occur on initial use of pairing bluetooth devices but has been observed to display an expected image. It seems that pairing to another phone and ending that pairing session will restore a more informed 'Confirm' dialog to every unpair activity.

Repro Steps:
1) Update a Aries to 20150810142756
2) Open Settings
3) Enable bluetooth
4) Connect/pair a handset
5) Observe paired handset on bluetooth settings page
6) Tap paired device and select to unpair
7) Observe unpair dialog screen

Actual:
Unpair bluetooth dialog prompt is generic and not telling of the function it's performing: "Confirm"

Expected:
Unpair bluetooth dialog prompt informs user of function performed by phone currently: "Are you sure you would like to unpair?"~


Environmental Variables:
------------------------------
Device: Aries 2.5
Build ID: 20150810142756
Gaia: fa89e03dc489e79baa0e74cb1d205260c7924caa
Gecko: cd45a38ded04
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Device: Flame 2.5
BuildID: 20150810030209
Gaia: 09dea2d5ff21cdb56da35fe4aa5bf4c90cf1da7f
Gecko: 0e269a1f1beb
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 42.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
**********************************

Issue DOES NOT REPRODUCE on 2.2 for flame devices
Results: Unpair bluetooth dialog prompt informs user that unpairing will lose connection of the device.

Device: Flame 2.2
BuildID: 20150810032504
Gaia: 102f1299e9eafe3760e1deb44d556b5c4f36b5af
Gecko: da29b5af4232
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
------------------------------

Repro frequency: 3/5
See attached: 
screenshot
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
[Blocking Requested - why for this release]:
noticeable regression missing text

requesting a window, note 3/5 reproduction rate
blocking-b2g: --- → 2.5?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
QA Contact: jmercado
The changes for Bug 1187668 seem to have caused this issue.

Central Regression Window:

Last Working 
Environmental Variables:
Device: Flame 2.5
BuildID: 20150808183811
Gaia: 0afa6429bf6a772289801600a84438cd7aa27b11
Gecko: fd63d8ed9d2e
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 42.0a1 (2.5) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

First Broken 
Environmental Variables:
Device: Flame 2.5
BuildID: 20150808193811
Gaia: 3e5271663e7ef26290c29a45d2e42c0d3c20fe04
Gecko: 24f4d8e5e24b
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 42.0a1 (2.5) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Last Working gaia / First Broken gecko - Issue does NOT occur
Gaia: 0afa6429bf6a772289801600a84438cd7aa27b11
Gecko: 24f4d8e5e24b

First Broken gaia / Last Working gecko - Issue DOES occur
Gaia: 3e5271663e7ef26290c29a45d2e42c0d3c20fe04
Gecko: fd63d8ed9d2e

Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/0afa6429bf6a772289801600a84438cd7aa27b11...3e5271663e7ef26290c29a45d2e42c0d3c20fe04
Blocks: 1187668
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Zibi, can you take a look at this please? This might have been caused by the landing for bug 1187668.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(gandalf)
[Triage] Blocked by the issue due to out of functionality. We should have it fix before v2.5 release.
blocking-b2g: 2.5? → 2.5+
Taking.

Oliver, can you attach a log? I don't have a bluetooth headset to test against, but I'll try to find out what's wrong from the log.
Assignee: nobody → gandalf
Flags: needinfo?(gandalf) → needinfo?(onelson)
Adding qawanted tag as I won't be able to attend to this issue.
Flags: needinfo?(onelson)
Keywords: qawanted
Attached file logcat
Attaching a logcat with gaia debug and bluetooth enabled reproducing the bug.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
Keywords: qawanted
Comment on attachment 8651309 [details] [review]
[gaia] zbraniecki:1193059-bring-back-unpair-msg-string > mozilla-b2g:master

Ahh! Now that's easy.

I accidentally removed two strings that are still in use. Logcat is super useful :)

Evelyn, once again, apologies for the regression. As far as I know it's the last one.
Attachment #8651309 - Flags: review?(ehung)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado)
Comment on attachment 8651309 [details] [review]
[gaia] zbraniecki:1193059-bring-back-unpair-msg-string > mozilla-b2g:master

No need to apologize, as a reviewer that was my miss too. Thank you for fixing it. :)
Attachment #8651309 - Flags: review?(ehung) → review+
Commit: https://github.com/zbraniecki/gaia/commit/609c4506a5b412234beb53a1f3dede6dd15cd0ee
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Sorry but this landing is not OK for strings.

-unpair-confirm = Unpair a connected device?\nYou are currently connected to this device. Unpairing will also disconnect from it.
+unpair-confirm = {{unpair-title}}\n{{unpair-msg}}

This string needs a new ID. Not sure if you prefer a new bug or follow-up in this one.
Flags: needinfo?(gandalf)
What us your rationale for that?
Flags: needinfo?(gandalf) → needinfo?(francesco.lodolo)
The string has completely changed, the ID is the same. As it is, we're going to pick up existing translation and nobody will notice.
Flags: needinfo?(francesco.lodolo)
The string has not changed a single letter. I (as an en-US localizer) modified only how I construct it. Other localizers can safely use the previous way or switch to follow mine or come up with something yet else.
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #15)
> The string has not changed a single letter. I (as an en-US localizer)
> modified only how I construct it. Other localizers can safely use the
> previous way or switch to follow mine or come up with something yet else.

I don't get it then: why did you change the en-US string in the first place? Do you consider it an irrelevant change that should not be picked up by localizations?
Yeah! Something like that.

Detailed explanation:

Before the patch in bug 1187668 the situation looked like this:

---------------
.properties:

string1 = X
string2 = Y

.js:

alert(string1 + '\n' + string2);

---------------

I moved those two strings to a new string that allowed localizers to construct a better message:

-----------------

.properties

string3 = X\nY

.js:

alert(string3)

------------------

But, I missed the fact that string1/string2 combo has been used elsewhere as two separate strings which cannot be combined. Hence this bug.
So now I knew that I have to bring back string1 and string2, but for the use case presented here I also want to keep string3.

Which would look like this:

---------------------

string1 = X
string2 = Y
string3 = X\nY

---------------------

And that would work, but would be redundant, because we know that those strings, at least in en-US are to be presented the same way. So instead I switched string3 to reference string1 and string 2:

---------------------

string1 = X
string2 = Y
string3 = {{string1}}\n{{string2}}

---------------------

This version is identical to the previous one, so if any localizer already translated string3, his translation is correct and there need to be no change.

I believe that string ID inflation should happen only when the previous translation of the en-US string becomes invalid translation of the new value of the en-US string. In this case, it remains fully valid, so I preserved the string ID.

Would you agree that it's ok for me not to inflate ID in that case?
Flags: needinfo?(francesco.lodolo)
I understand your point: the final result doesn't change, both "X\nY" and "{{string1}}\n{{string2}}" produce the same text in the end.

But, the reality is that there's no such thing as a "choice affecting en-US as a locale", because en-US is our reference language. If en-GB changes a string, that affects only en-GB. If en-US changes a string, that somehow affects every other locale.

In this specific case, one possible fall-out is for tools which try to check for missing variables, and will report this string as problematic. As long as l10n.js doesn't bother, that's a minor issue.

Personally I prefer to change string IDs in edge cases like this one, especially if they don't require extensive code changes. But I can live with it if you think that change is not useful.
Flags: needinfo?(francesco.lodolo)
> If en-US changes a string, that somehow affects every other locale.

I don't think I agree.

> In this specific case, one possible fall-out is for tools which try to check for missing variables, and will report this string as problematic.

Then I would say that our tools should be fine tuned.

> Personally I prefer to change string IDs in edge cases like this one, especially if they don't require extensive code changes. 

With L20n features, those changes will happen more often. I find the concept that any touch of en-US string requires ID inflation an artifact of the .properties approach of 1-1 matching between en-US and languages.
With L20n model, we are decoupling that. For example, I can imagine a scenario where you'd have this entity:

<foo "There are {{$number}} messages">

and we would decide to change en-US localization to:

<foo[$number == 0 ? 'zero' : 'other'] {
  zero: "There are no new messages",
  other: "There are {{$number}} messages"
}>

and I believe that it should *not* cause entity ID change because all the translations are valid, the social contract between the developer and localizer was not altered, and localizers should construct their entities independently from en-US.

The same of course goes the other way - if the en-US localizer will decide to switch from the zero/other form to a single string, it's also not a change that breaks the social contract and should not require marking of the entity as "modified" for localizers.

I believe it's worth discussing it more deeply so I'm going to post to tools - let's move the conversation there https://groups.google.com/d/msg/mozilla.tools.l10n/fDYQwikvky4/cpwv3cPABwAJ
Target Milestone: --- → FxOS-S6 (04Sep)
This bug has been verified as "pass" on the latest build of Flame KK 2.5 and Aires KK 2.5 by the STR in comment 0.

Actual results: Unpairing handset confirmation screen displays correct bluetooth information.
See attachment: verified_FlameKK_v2.5.3gp
Reproduce rate: 0/10


Device: Flame KK 2.5 (Pass)
Build ID               20150909150223
Gaia Revision          47459eead04385e22f967012b824f5abdddcfb7c
Gaia Date              2015-09-09 10:37:28
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/dd2a1d737a64d9a3f23714ec5cc623ec8933b51f
Gecko Version          43.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150909.185733
Firmware Date          Wed Sep  9 18:57:43 EDT 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Device: Aries KK 2.5 (Pass)
Build ID               20150909215153
Gaia Revision          47459eead04385e22f967012b824f5abdddcfb7c
Gaia Date              2015-09-09 10:37:28
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/dd2a1d737a64d9a3f23714ec5cc623ec8933b51f
Gecko Version          43.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150909.211310
Firmware Date          Wed Sep  9 21:13:17 UTC 2015
Bootloader             s1
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: