Closed Bug 801045 Opened 12 years ago Closed 12 years ago

Can't enter numbers

Categories

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

x86_64
Linux
defect

Tracking

(blocking-basecamp:+)

VERIFIED FIXED
blocking-basecamp +

People

(Reporter: gwagner, Assigned: gwagner)

References

Details

(Keywords: otoro, regression, unagi, Whiteboard: [dogfooding-blocker])

Attachments

(1 file)

Nothing happens when I press the button that should switch to the numbers keyboard when I try to enter a password for wifi.
blocking-basecamp: --- → ?
The error I see: E/GeckoConsole( 2036): [JavaScript Error: "TypeError: Keyboards[_baseLayoutName] is undefined" {file: "app://keyboard.gaiamobile.org/js/controller.js" line: 243}]
Summary: Can't enter numbers for wifi password → Can't enter numbers
blocking-basecamp: ? → +
Argh a make reset-gaia solved it for me.
I haven't seen this on otoro, nor unagi. Renoming based on Comment 2.
blocking-basecamp: + → ?
It works for me now. Please reopen it shows up again.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Hi. I'm running into this when building Firefox OS for the first time for Otoro. Doing make reset-gaia (within the gaia dir) does not fix it for me. I filed over in github before I saw this issue. https://github.com/mozilla-b2g/gaia/issues/5800 I'm not sure if I missed a step in the build process (something related to language settings?) but at least one other on github is seeing it so maybe we should re-open?
I am seeing this on a latest build with a reset-gaia
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Rudy, I believe you know this code best. Any idea what's going on here?
Assignee: nobody → rlu
Keywords: unagi
This appears on the daily unagi build. Marking blocking and P1 critical.
Severity: normal → critical
blocking-basecamp: ? → +
Priority: -- → P1
Whiteboard: [dogfooding-blocker]
Is the same error message appearing in logcat?
Whiteboard: [dogfooding-blocker]
I can also reproduce it again on otoro. make reset-gaia introduces this bug ./flash.sh fixes it for me. Maybe related is this message during booting: E/GeckoConsole( 106): [JavaScript Error: "uncaught exception: 2147500033"]
Oy ... this WFM in a clean flash with 8595e313fc21 and gaia 74e25211c14db3ca590b7eb7bb64495bc7af2b62. What versions are people seeing this bug on?
Note, I'm testing with an eng build. Let me try user.
I am on: gaia: 85c50bd9767552284ee1abb5bda620bd3723e4fb gecko: 1ec4bdea9de7c0567810fd09cb55b02304b3186d I was seeing E/GeckoConsole( 2036): [JavaScript Error: "TypeError: Keyboards[_baseLayoutName] is undefined" {file: "app://keyboard.gaiamobile.org/js/controller.js" line: 243}] I dont think E/GeckoConsole( 106): [JavaScript Error: "uncaught exception: 2147500033"] is related
> I dont think > E/GeckoConsole( 106): [JavaScript Error: "uncaught exception: 2147500033"] > is related Although I may be wrong, if I remember that was something to do with stale settings updates
Marking this as a dogfooding blocker. We need to know if this is a regression, if it's present in today's stable unagi builds (after we get mozilla-aurora builds in bug 801793) to confirm that we'll still block for this.
Whiteboard: [dogfooding-blocker]
I can reproduce this with a "user" build, same revisions.
diff -ru says the eng bits and the user bits in webapps/keyboard are the same ...
I/GeckoDump( 106): Base layout: "", layout name: "alternateLayout" E/GeckoConsole( 106): [JavaScript Error: "TypeError: Keyboards[_baseLayoutName] is undefined" {file: "app://keyboard.gaiamobile.org/js/controller.js" line: 258}]
In an eng build I/GeckoDump( 106): Base layout: "en", layout name: "alternateLayout" so it appears that us not detecting "en" is causing this. Let's see where that comes from ...
Bisection failed because I ceased to be able to reproduce the bug on newer csets. Looks like an older commit dirties out/ in a way that makes the bug go away. ARGH!!!
Indeed, I can no longer repro with tip in a user build.
rm -rf out/target/product/otoro/data/local/ out/target/product/otoro/system/b2g/ allows me to repro again.
There are only 'skip'ped commits left to test. The first bad commit could be any of: b0e2104c2804c20c7ccd9f69cfa853a2403a256f b385122f1a4fb845330b0b31f5db90906e04bd2d We cannot bisect more!
Gregor is investigating.
Assignee: rlu → anygregor
So the problem is that the keyboard app doesn't have the privilege to access the settings API to get the current locale. However, during the installation step I see that the permission is added for the keyboard app. When we check the permission we don't find an entry for it and hit the Gaia workaround hack: https://mxr.mozilla.org/mozilla-central/source/extensions/cookie/nsPermissionManager.cpp#1030
The keyboard app has localId 13 but when we do the lookup for the keyboard app we do it with the localID from the system app 18. That can't work.
Attached file Workaround in Keyboard app. (deleted) —
The root cause of this issue is Keyboard app. could not get layout settings due to permission issue. We are still investigating permission issue and this workaround would make us be able to input numbers even if the layout settings is not available.
Attachment #671722 - Flags: review?(timdream+bugs)
Getting dogfooding up and running is top priority. Tim, please stop anything else you are doing to do the review.
Comment on attachment 671722 [details] Workaround in Keyboard app. r+ with following modification. Instead of changing the order, please do try { this.updateSettings(); } catch (e) {} The comment can stay.
Attachment #671722 - Flags: review?(timdream+bugs) → review+
Hi Tim, The pull request has been updated to address the review comment. Please help have a review again. Thank you.
I await the patch with bated breath, and will immediately retest when it lands! :)
(In reply to Chris Jones [:cjones] [:warhammer] from comment #34) > I await the patch with bated breath, and will immediately retest when it > lands! :) Merged. https://github.com/mozilla-b2g/gaia/pull/5827
Cjones, what's the outcome of your testing?
WFM. Gregor/Rudy/Tim, please file a followup for a "real fix".
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Depends on: 802237
Verified fix on 10-16-2012 daily unagi build. inputting numbers work again.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: