Created attachment 691910 [details] screenshot ## Environment : Unagi phone, build 2012-12-13 ## Repro : 1. go to news.google.com 2. long tap and open a link in a new tab 3. long tap and open a different link in a new tab 4. repeat 3. ## Expected : 1. dialog that has unresponsive script does not have an & sign ## Actual : 1. see screenshot. 2. l10n issue? ## Note :
This isn't an l10n issue, there's an '&' in the strings to denote an accesskey, which the gaia dialog apparently doesn't consume.
Triage: BB+,P2,C3 for incorrect display
Assignee: nobody → ben
blocking-basecamp: ? → +
Priority: -- → P2
Target Milestone: --- → B2G C3 (12dec-1jan)
Alex is the dialog still there?
Hum yes, until bug 820443 lands.
So given that it's gonna be disabled for the moment, I think we should block on bug 821980 before working on this. And so leave it out of C3.
Depends on: 821980
Target Milestone: B2G C3 (12dec-1jan) → ---
If we'd end up needing new strings for this, we should keep this on the radars. Not sure if we'd need or not, though.
Driver retriage: Not holding the release for this.
blocking-basecamp: + → -
Priority: P2 → P4
5 years ago
Duplicate of this bug: 841452
Could still reproduce this on today's pvt nightly v1.0.1 build and v1 train v1.0.1 Gecko: 4229cbbb556f7106351942628c21a64b3f77ae41 Gaia: c79e761bae4d92f329154c64159f4f5c8eb49c9e BuildID 20130415070202 Version 18.0 v1 Gecko: c6a7e6bdba0b7ee9ce0cddee1388ecfe20822e32 Gaia: baec473de45d4971b86a470b7580cd1444585a26 BuildID 20130415070205 Version 18.0
Summary: & in the dialog for unresponsive script → & in the dialog for unresponsive script (slow script dialog)
(In reply to Axel Hecht [:Pike] from comment #1) > This isn't an l10n issue, there's an '&' in the strings to denote an > accesskey, which the gaia dialog apparently doesn't consume. I've not heard of this before, what's the way this is intended be consumed? We can add a workaround in Gaia to trim leading ampersands from strings in that dialog if there's not a more useful way we can handle it.
Whiteboard: c=browser u=user
Frankly, I have no idea how the accesskeys are gotten out, and I bet it's even platform-dependent. nsIPrompt doesn't document that contract, I suggest that you find someone on a platform side. Maybe blassey remembers what they're doing for android?
On Android (and desktop), there are helper functions to clean these up. See: http://mxr.mozilla.org/mozilla-central/source/mobile/android/components/PromptService.js#509
Whiteboard: c=browser u=user → [sprintready]c=browser u=user
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.