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)
Tracking
(blocking-b2g:2.5+, b2g-v2.2 unaffected, b2g-master verified)
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)
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
Reporter | ||
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Comment 1•9 years ago
|
||
[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)
Keywords: regressionwindow-wanted
Updated•9 years ago
|
QA Contact: jmercado
Comment 2•9 years ago
|
||
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)
Keywords: regressionwindow-wanted
Comment 3•9 years ago
|
||
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)
Comment 4•9 years ago
|
||
[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+
Assignee | ||
Comment 5•9 years ago
|
||
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)
Reporter | ||
Comment 6•9 years ago
|
||
Adding qawanted tag as I won't be able to attend to this issue.
Flags: needinfo?(onelson)
Keywords: qawanted
Comment 7•9 years ago
|
||
Attaching a logcat with gaia debug and bluetooth enabled reproducing the bug.
Updated•9 years ago
|
Comment 8•9 years ago
|
||
Assignee | ||
Comment 9•9 years ago
|
||
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)
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado)
Comment 10•9 years ago
|
||
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+
Assignee | ||
Comment 11•9 years ago
|
||
Commit: https://github.com/zbraniecki/gaia/commit/609c4506a5b412234beb53a1f3dede6dd15cd0ee
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Comment 12•9 years ago
|
||
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)
Assignee | ||
Comment 13•9 years ago
|
||
What us your rationale for that?
Flags: needinfo?(gandalf) → needinfo?(francesco.lodolo)
Comment 14•9 years ago
|
||
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)
Assignee | ||
Comment 15•9 years ago
|
||
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.
Comment 16•9 years ago
|
||
(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?
Assignee | ||
Comment 17•9 years ago
|
||
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)
Comment 18•9 years ago
|
||
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)
Assignee | ||
Comment 19•9 years ago
|
||
> 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
Updated•9 years ago
|
Target Milestone: --- → FxOS-S6 (04Sep)
Comment 20•9 years ago
|
||
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+]
Comment 21•9 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•