Closed Bug 1129315 Opened 10 years ago Closed 10 years ago

Newly installed keyboard app from Marketplace has no input permission if the app process was preallocated

Categories

(Core :: Permission Manager, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla39
blocking-b2g 2.2+
Tracking Status
firefox37 --- wontfix
firefox38 --- wontfix
firefox39 --- fixed
b2g-v2.2 --- verified
b2g-master --- verified

People

(Reporter: timdream, Assigned: kk1fff)

References

()

Details

(Keywords: regression, verifyme)

Attachments

(2 files)

+++ This bug was initially created as a clone of Bug #1124265 +++ See bug 1124265 comment 16 (reproducible information copied below), regressionwindow-wanted to find the root cause: ==== Observed behavior: No keyboard is displayed after switching to 3rd party keyboard. User will have NO keyboard displayed anywhere until they disable the 3rd party keyboard in Settings. See video: https://www.youtube.com/watch?v=a-RrhcVUSX4 Tested on bug occurs on: Device: Flame 2.2 (shallow flash) BuildID: 20150124133137 Gaia: 0518f4581a0925c0b703d730ef289ab15cbd1216 Gecko: c6aa604a7967 Version: 37.0a2 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 Device: Flame 2.2 (full flash) BuildID: 20150202002507 Gaia: d6141fa3208f224393269e17c39d1fe53b7e6a05 Gecko: be206fa2fb60 Version: 37.0a2 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 Device: Flame 3.0 (shallow flash) BuildID: 20150202042034 Gaia: 4171327fce4803c52b2fae8071b114a70a3a68a7 Gecko: 3bf7ed413e87 Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
Whiteboard: [FT:System-Platform]
QA Contact: jmercado
A regression window cannot be found for this issue. It cannot be checked without the fix to bug 1124265 but the bug occurs in all builds since that fix is in and does not occur in the build before bug 1124265 occurred. Last Build with bug 1124265 (Cannot check this issue) Environmental Variables: Device: Flame 3.0 BuildID: 20150122174920 Gaia: cba2f0bf49b882e0044c3cc583de8fcf83d2ffa4 Gecko: 494632b9afed Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 First Build after bug 1124265 (This issue DOES reproduce) Environmental Variables: Device: Flame 3.0 BuildID: 20150123090837 Gaia: 2535321f1bd55e68fd52291b193693a8995f8e62 Gecko: 542118f3e9bd Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 Last build before bug 1124265 (Issue does NOT occur) Environmental Variables: Device: Flame 2.2 BuildID: 20141111042605 Gaia: 6af3a8a833eb8bb651e8b188cb3f3c3a43bb4184 Gecko: c60fc2c11c0e Gonk: Could not pull gonk. Did you shallow Flash? Version: 36.0a1 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Assignee: nobody → timdream
Status: NEW → ASSIGNED
Sigh. I can verify the newly installed app will receive the input permission when I reboot the phone. I still convinced this is a Gecko issue but it's going to be hard to find the root cause hiding underneath the regression range of bug 1124265.
Hi KTucker, I need some special help here. Would it be possible if we could lock down the Gaia version and try to find the regressed Gecko version? We should use a Gaia version that is not affected by bug 1124265 and find the regressed Gecko within the range of builds that is affected by it. Specifically: Gaia version to lock down: either before (20141111042605; 6af3a8a833eb8bb651e8b188cb3f3c3a43bb4184) or after (20150123090837; 2535321f1bd55e68fd52291b193693a8995f8e62). Gecko range: c60fc2c11c0e ... 494632b9afed (20141111042605 ... 20150122174920). That should enable us to find the regressed patch. Thanks!
Flags: needinfo?(ktucker)
The regression window still cannot be found this way. If gaia and gecko are separated too far the build will not load at all. using the gaia from build (first build that fixed bug 1124265): Environmental Variables: Device: Flame 3.0 BuildID: 20150123090837 Gaia: 2535321f1bd55e68fd52291b193693a8995f8e62 Gecko: 542118f3e9bd Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 Build won't load: Environmental Variables: Device: Flame 3.0 BuildID: 20150112200033 Gaia: 2535321f1bd55e68fd52291b193693a8995f8e62 Gecko: 3d846527576f Gonk: Could not pull gonk. Did you shallow Flash? Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 Broken Environmental Variables: Device: Flame 3.0 BuildID: 20150113052538 Gaia: 2535321f1bd55e68fd52291b193693a8995f8e62 Gecko: a5700bec72e1 Gonk: Could not pull gonk. Did you shallow Flash? Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Thanks for the help. I really need to find the regression range. I will try to see if I can download any build affected by bug 1124265 but find a way to workaround the bug in all these builds in Gaia to find the Gecko issue.
I am having trouble launch Marketplace app in BuildID 20150101010206. It shows a white screen with an useless [x]. We should probably debug directly here....
Update: After talking to Cervantes, he ask me to try the following STR to isolate where the problem is, and after successfully reproducing this, we suspect this is a permission bug or a Nuwa bug: With "Console Enabled" in Settings and working, reproduced STR: 1. Tap Marketplace 2. Search "LOL" 3. Install "LOL Keyboard" 4. Enable the "\o/" layout when prompt 5. Tap rocket bar, English layout will show up 6. long press the "En" key 7. Select "\o/" layout Actual behavior: 8. "\o/" layout does not show up, and with following JavaScript error: W/LOL Keyboard( 1667): [JavaScript Error: "TypeError: window.navigator.mozInputMethod is undefined" {file: "app://{b62b0750-ec4f-4ee5-b003-92c17df19718}/js/main.js" line: 7}] Unreproduced STR: 0. Use |adb shell b2g-ps| to find the pid of Preallocated App Process and use |adb shell kill (PID)| to kill it. 1. Tap Marketplace 2. Search "LOL" 3. Install "LOL Keyboard" 4. Enable the "\o/" layout when prompt 5. Tap rocket bar, English layout will show up 6. long press the "En" key 7. Select "\o/" layout Expected behavior: 8. "\o/" layout does show up.
Assignee: timdream → nobody
Status: ASSIGNED → NEW
Component: DOM: Device Interfaces → Permission Manager
Whiteboard: [FT:System-Platform]
BTW this bug does not show up if the app is pushed with WebIDE or App Manager.
Summary: Newly installed keyboard app from Marketplace has no input permission → Newly installed keyboard app from Marketplace has no input permission if the app process was preallocated
Do you have any suggestions for next steps here, Tim?
Flags: needinfo?(timdream)
(In reply to Andrew Overholt [:overholt] from comment #9) > Do you have any suggestions for next steps here, Tim? Debug into Gecko and/or B2G please? I am not entirely sure how Gecko work is distributed though.
Flags: needinfo?(timdream)
Okay, I don't know about the Gecko or Gonk sides of this but I'm sure whoever does will be happy to help.
Thinker, is this a bug your team could work on? Thanks!
Flags: needinfo?(tlee)
Hi Patrick, According to comment 7, can you please check if this is a nuwa relevant issue?
Flags: needinfo?(tlee) → needinfo?(kk1fff)
The problem occurs because we prevent nuwa from receiving broadcast messages after it is frozen, and the permission update can't be passed to app processes which are created from preallocated process after a new input method is installed.
Flags: needinfo?(kk1fff)
Assignee: nobody → kk1fff
Attachment #8574551 - Flags: review?(josh)
Attachment #8574551 - Attachment description: Patch: update permissions after being forked from nuwa. → Patch: update permissions after a content process is forked from nuwa.
Comment on attachment 8574551 [details] [diff] [review] Patch: update permissions after a content process is forked from nuwa. Review of attachment 8574551 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/ipc/ContentChild.cpp @@ +537,5 @@ > + MOZ_ASSERT(permManager, "Unable to get permission manager"); > + nsresult rv = permManager->RefreshPermission(); > + if (NS_FAILED(rv)) { > + MOZ_ASSERT(false, "Failed updating permission in child process"); > + } I was going to ask why we can't just instantiate the nsIPermissionManager service here and rely on the old code that was changed nsPermissionManager::Init. I assume this is necessary because the forked process already has the permission manager initialized?
Attachment #8574551 - Flags: review?(josh) → review+
(In reply to Josh Matthews [:jdm] from comment #16) > I was going to ask why we can't just instantiate the nsIPermissionManager > service here and rely on the old code that was changed > nsPermissionManager::Init. I assume this is necessary because the forked > process already has the permission manager initialized? nsPermissionManager has been initialized in Nuwa before forking. I think that some preload script triggered loading of nsPermissionManager.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
Comment on attachment 8574551 [details] [diff] [review] Patch: update permissions after a content process is forked from nuwa. NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings. [Approval Request Comment] Bug caused by (feature/regressing bug #): 970307 User impact if declined: unable to get update permission when a new app installed. Testing completed: Risk to taking this patch (and alternatives if risky): should be low String or UUID changes made by this patch: nsIPermissionManager's UUID
Attachment #8574551 - Flags: approval-mozilla-b2g37?
Attachment #8574551 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
This issue is verified fixed on the lates Nightly Flame 3.0 build. Setting verifyme to check this issue when 2.2 nightly has this change available Actual Results: Newly installed keyboards correctly show when chosen. Environmental Variables: Device: Flame 3.0 KK (Full Flash) (319 MB) BuildID: 20150316010202 Gaia: 4868c56c0a3b7a1e51d55b24457e44a7709ea1ae Gecko: 436686833af0 Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b Version: 39.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: verifyme
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
This bug has been successfully verified on latest Flame v2.2. See attachment: verified_v2.2.mp4 Reproduce rate: 0/5 STR: 0. With "Console enabled" in Settings and working. 1. Open Marketplace app. 2. Search "LOL"(or "keyboard"). 3. Install "LOL Keyboard" (or Korean keyboard,or Thai keyboard). 4. Enable the "\o/" layout when prompt (or select "\o/" in Settings/Keyboards/Select Keyboards). 5. Open Messages and create a new message (or rocket bar), English layout will show up. 6. Long press the "En" key. 7. Select "\o/" layout. **New installed keyboards(LOL Keyboard,Korean keyboard,Thai keyboard) show up correctly. Flame 2.2 (Pass): Build ID 20150316162504 Gaia Revision d0e09d5e6367e558824f9cbf691da99cedf63037 Gaia Date 2015-03-16 17:14:22 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/793d61bb0bd4 Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150316.195035 Firmware Date Mon Mar 16 19:50:48 EDT 2015 Bootloader L1TC000118D0
Attached video verified_v2.2.mp4 (deleted) —
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: