Turning on selectioncaret.noneditable pref to true and set style of all elements of keyboard to -moz-user-select: none. STR: 1. tap on rocketbar and keyboard shows 2. type some text and long press it to launch copy paste bubble 3. long-press any key of keyboard Actual: keyboard hide and selection area disappear Expect: keyboard would not hide and selection area remains This bug cannot be reproduced in sms/contact app , so I guess it's only for rocket bar.

When turn on selectioncaret.noneditable, step 3 would receive an inputmethod-contextchange from mozChromeEvent only in rocketbar case.

Correct myself, this bug can be reproduced event when selectioncaret.noneditable pref is off. (In reply to George Duan [:gduan] [:喬智] from comment #0) > Turning on selectioncaret.noneditable pref to true and set style of all > elements of keyboard to -moz-user-select: none. > > STR: > 1. tap on rocketbar and keyboard shows > 2. type some text and long press it to launch copy paste bubble > 3. long-press any key of keyboard > > Actual: > keyboard hide and selection area disappear > > Expect: > keyboard would not hide and selection area remains > > This bug cannot be reproduced in sms/contact app , so I guess it's only for > rocket bar.

Remove Text Selection since this could be reproduced when selectioncaret off. CJ, please help to check this is gecko issue or not.

This repros with 2.2 Flame with 1GB or 319MB, and does NOT repro with 2.1 on 1GB or 319MB. (RAM can matter because we launch keyboard OOP when RAM is >= 512MB). I tend to think it's probably one of my InputManagement patches. I'll do a quick investigation.

(In reply to John Lu [:mnjul] [MoCoTPE] from comment #4) > I tend to think it's probably one of my InputManagement patches. I'll do a > quick investigation. Turns out it's not -- I checked out a98a6c44a03613aed97858510b197245c36f1ec2 (the commit before input-window) and could still repro the bug; with latest Gecko.

I suspect this is due to my InputMethod API changes. Let's get a regression window first.

clear ni first to wait for the regression window result

To do a regression-window we need more specific STR - namely what flash method are you using

George can you also tell in which file I should add the changes in comment 0, specifically: -moz-user-select: none

Hi Joshua and Jayme, As in comment 2, we figured that text-selection is irrelevant in this bug so you don't need to change any file/flag. The bug is reproducible from PVT shallow-flash Gaia+Gecko on Flame with v188; Reproducible on Flame 1GB and Flame 319MB. A text-selection-irrelevant STR: 1. Focus on Rocketbar; Keyboard should be brought up. (Dismiss the permission warning and focus again, if needed) 2. Long press any key on the keyboard. Don't release finger yet. Expected: 3. The keyboard should not slide down and hide. As long as you're still pressing your finger against the keyboard you see the key pop-up. Actual: 3. The keyboard slide down and hide. (and you can release your finger now...) Flashed build on master: Gaia-Rev c5bad6d78c5fe168e3bb894fc5cb70902c9b19b1 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/8c02f3280d0c Build-ID 20141123160201 And this does NOT repro on 2.1 (1G or 319): Gaia-Rev afdfa629be209dd53a1b7b6d6c95eab7077ffcd9 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/3d2d47bfe3ff Build-ID 20141123161201

Possibly broken by Bug 1092888 - Morris can you take a look please. Mozilla-inbound Regression Window Last Working Environmental Variables: Device: Flame 2.2 BuildID: 20141117225125 Gaia: ae3a84acaab80a5b35d5542d63e68462273c8a1b Gecko: 5ee39194ac67 Gonk: Could not pull gonk. Did you shallow Flash? Version: 36.0a1 (2.2) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 First Broken Environmental Variables: Device: Flame 2.2 BuildID: 20141117233625 Gaia: ae3a84acaab80a5b35d5542d63e68462273c8a1b Gecko: 6dbd7d78e775 Gonk: Could not pull gonk. Did you shallow Flash? Version: 36.0a1 (2.2) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Last Working gaia / First Broken gecko - Issue DOES occur Gaia: ae3a84acaab80a5b35d5542d63e68462273c8a1b Gecko: 6dbd7d78e775 First Broken gaia / Last Working gecko - Issue does NOT occur Gaia: ae3a84acaab80a5b35d5542d63e68462273c8a1b Gecko: 5ee39194ac67 Gecko Pushlog: hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5ee39194ac67&tochange=6dbd7d78e775

I'll handle this.

Hi Morris, this patch don't apply cleanly: patching file layout/base/SelectionCarets.cpp Hunk #1 FAILED at 540 1 out of 1 hunks FAILED -- saving rejects to file layout/base/SelectionCarets.cpp.rej patch failed, unable to continue (try -v) could you take a look, thanks!

Rebased.

I've rebased patch. Please check-in again. Thanks.

Verified the issue is fixed on Flame 2.2 The keyboard doesn't disappear when long-tapping a keyboard letter in the rocketbar highlighted text Flame 2.2 Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash) BuildID: 20141204040202 Gaia: 984e6d79aa799d2695f9ca132dfdc1665a56c019 Gecko: a9fc46355661 Gonk: 48835395daa6a49b281db62c50805bd6ca24077e Version: 37.0a1 (2.2 Master) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Clearing the blocking nom for 2.2? as this is already fixed/verified on that branch per the status flag