941489 - [B2G][Helix][Browser][ChenHoulai] The inputmethod can not be pop after press home button in the 'Clear browsing history' dialog surface of browser.

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Browser, defect, P2)

Description

[lecky]

User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; aff-kingsoft-ciba)

Steps to reproduce:

【Detail Description*】：
   The inputmethod can not be pop after press home button in the 'Clear browsing history' dialog surface of browser.
【Repro Steps*】：
    1、Enter into the browser app.
    2、Enter into the settings surface of browser.
    3、Click the 'Clear browsing history' button.
    4、After the 'Clear browsing history' dialog is showed, do not click 'Cancel' or 'Ok', click the home button to return to homescreen.
    5、Enter into the Notes, Clock, Contacts apps.
【Expect Result*】：
    5、The inputmethod can be pop normally.
【Real Result*】：
    5、The inputmethod can not be pop normally.
【Test Count*】：5
【Found Count*】：5
【Gaia commit ID*】: ca94f480808a6a9d6cbb9116833a40f67ca55422
【Gecko commit ID*】: 6922cdcfa9606b399d0fc195550fd76c819ad500
【Log*】：NA
【Network environment】：
【Resume operation】：
【Carrier】：

Comment 1

[lecky]

Attachment: 941489.3gp

Comment 2

[Beatriz Rodríguez [:brg]]

I cannot reproduce this bug with version 1.2, unagi, Gecko-d77ba08.Gaia-1b67b55
I do not think this is an easy scenario to reproduce. IMHO not critical.

Comment 3

[Luke Chang [:lchang] (inactive)]

Attachment: Pull Request 14203

This issue is caused because the browser app doesn't run as OOP (out-of-process) and its confirm dialog will block "MutationObserver" event from system app. Unfortunately, the keyboard manager needs that event to determine when to show/hide the keyboard app. The patch I attached is to trigger that event handler manually when it needed.

I will set "review" flag once this bug is set to be hd+.

Comment 4

[Wayne Chang [:wchang]]

Let's take this on HD as requested by partner

Comment 5

[Luke Chang [:lchang] (inactive)]

After discussing with Rudy, we found the root cause of this bug is that we should not use alert/confirm which will block UI behavior in the non-OOP process. I noticed that this issue doesn't appear on v1.2 branch and found out the reason is that we've already changed to use our custom confirm dialog instead of confirm() function in Bug 814436. For this reason, I will drop my patch in comment 3 and uplift the commit from Bug 814436 instead to fix this issue.

Comment 6

[Luke Chang [:lchang] (inactive)]

Uplifted: 2eb14d5de28b5f12ddcc50ffc4e0b74932bd4192
v1.1.0hd: 5b4af0ffaae2956241842f9f146f15347dae3ad0