1124830 - [Windows Management][Keyboard] Bringing up a contextual (long press) menu does not dismiss the keyboard in some apps; creating menu overlap and blocking view of some menu options.

Status: RESOLVED DUPLICATE of bug 1127660

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Joshua Mitchell (Inactive)]

Attachment: logcat_20150122_1108.txt

Summary (title) Field:
[Windows Management][Keyboard] Bringing up a contextual (long press) menu does not dismiss the keyboard in some apps; creating menu overlap and blocking view of some menu options.

Description: When opening a contextual menu while the keyboard is up will not dismiss the keyboard causing the lower menu options to be obstructed. This works properly in some places such as Messages app (with an active thread you can have the keyboard up and long-press a sent/received message to bring up a contextual menu that will dismiss the keyboard as it pops up)

This occurs in: Browser, Marketplace
This functions properly in: MMS

Repro Steps: (example)
1) Update a Flame to 20150122010203
2) Launch Browser
3) Navigate to Google.com
4) Click in the page's search box to bring up the keyboard
5) Long press on the Google image (to bring up image contextual menu (save/share image)

Actual:
Bringing up the contextual menu does not dismiss the keyboard. Menu options are overlapped by keyboard; obscuring the view of the options.

Expected:
Opening a contextual menu will dismiss the keyboard

Environmental Variables:
Device: Flame 3.0
Build ID: 20150122010203
Gaia: 917b6c36717fddc6e71ffc1ec249633c8044c93c
Gecko: 34e2d2bd7ec4
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Repro frequency: 8/8
See attached: logcat, video: http://youtu.be/gI_E2HMn06M
------------------------------------------------------------------------------------

This issue reproduces in 2.2 (v18d-1), 2.2 (v18d), 2.1 (v18d-1)

Device: Flame 2.2 (KK - Nightly - Full Flash)
Build ID: 20150122002808
Gaia: e4f9b5da3751798f9cc5d95f302c30722cc11fca
Gecko: 4a90da67661e
Gonk: e7c90613521145db090dd24147afd5ceb5703190
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 (KK - Nightly - Full Flash)
Build ID: 20150122002808
Gaia: e4f9b5da3751798f9cc5d95f302c30722cc11fca
Gecko: 4a90da67661e
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0a2 (2.2)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0


Device: Flame 2.1 (KK - Nightly - Full Flash)
Build ID: 20150120001202
Gaia: 77c57eb8a985d5cbd34a597fb1b978ba6e205af6
Gecko: f05d0a2d2378
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 34.0 (2.1)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
-----------------------------------------------------------------------------------------

This partially repros in 2.0 
Notes: Most long-press contextual windows do not exist in 2.0 however in Browser there is a long-press menu for the google image. That menu only has the 'save image' option but instead of appearing underneath the keyboard the contextual menu appears on top (higher up the screen) of the keyboard and because there is only one option + cancel it is clearly visible. 

Device: Flame 2.0 (KK - Nightly - Full Flash)
Build ID: 20150120000224
Gaia: 736933b25ded904f0cb935a0d48f1f3cf91d33ad
Gecko: 6ff30f9ba931
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 32.0 (2.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 1

[Peter Bylenga [:PBylenga]]

Not going to nominate to block, not a regression and easily recoverable.  Nominating as a polish bug since it's still a poor UX.

Comment 2

[Hermes Cheng (inactive after July 27, 2015)]

Alive, do you know who can take a look?

Comment 3

[(inactive after 6/18) Alive Kuo [:alive]]

Switch component. We should get the input state change here and if we don't it's a bug.

Comment 4

[John Lu [:mnjul][Please NI or I'll miss]]

Well...

OptionMenu, i.e. the shared context menu module used by Messages app, explicits blurs any activeElement, and the comments there read like they've tried to work around this very issue [1]. In contrast we don't have a similar mechanism in BrowserContextMenu used for Browser/Marketplace.

I think we have two options to go with:
1. Replicate the OptionMenu behavior to BrowserContextMenu; change nothing to input management.
2. In window management, we listen to mozbrowsercontextmenu for any AppWindow, and when such event fires, we send a message to input management and inputWindowManager will hide the showing inputWindow, if any.

I think option 2 is more "correct" but I guess it might also be more prone to introduce regressions. As it affects System app design/architecture I'd like to hear your feedback.

Alive, what do you think?

[1] https://github.com/mozilla-b2g/gaia/blob/master/shared/js/option_menu.js#L190-L191

Comment 5

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to John Lu [:mnjul] [MoCoTPE] from comment #4)
> Well...
> 
> OptionMenu, i.e. the shared context menu module used by Messages app,
> explicits blurs any activeElement, and the comments there read like they've
> tried to work around this very issue [1]. In contrast we don't have a
> similar mechanism in BrowserContextMenu used for Browser/Marketplace.
> 
> I think we have two options to go with:
> 1. Replicate the OptionMenu behavior to BrowserContextMenu; change nothing
> to input management.
> 2. In window management, we listen to mozbrowsercontextmenu for any
> AppWindow, and when such event fires, we send a message to input management
> and inputWindowManager will hide the showing inputWindow, if any.
> 
> I think option 2 is more "correct" but I guess it might also be more prone
> to introduce regressions. As it affects System app design/architecture I'd
> like to hear your feedback.
> 
> Alive, what do you think?
> 
> [1]
> https://github.com/mozilla-b2g/gaia/blob/master/shared/js/option_menu.
> js#L190-L191

I tend to blur the current appWindow when its browserContextMenu is shown.
i.e., call this.app.blur() in BrowserContextMenu when its opened.

The reason is we will not introduce too many custom events for input window manager and only rely on the input-contextchange event from gecko for more consistency.

Could you make this change? Thanks.

Comment 6

[John Lu [:mnjul][Please NI or I'll miss]]

Sure, on me.

Comment 7

[(inactive after 6/18) Alive Kuo [:alive]]

Okay, George had already fixed it I think.
https://bugzilla.mozilla.org/show_bug.cgi?id=1127660

\O/

Comment 8

[John Lu [:mnjul][Please NI or I'll miss]]

Yay !

Let me mark the duplication and de-assign myself.

Comment 9

[Hermes Cheng (inactive after July 27, 2015)]

The problem still exists on my flame v2.2. Could you please check?

Comment 10

[John Lu [:mnjul][Please NI or I'll miss]]

(In reply to Hermes Cheng[:hermescheng] from comment #9)
> The problem still exists on my flame v2.2. Could you please check?

Hermes, bug 1127660 landed on master after 2.2 was branched out so it's natural you could still reproduce this on 2.2. We can request for uplifting if we need to fix the bug in 2.2.

Comment 11

[Joshua Mitchell (Inactive)]

This is why when you Dupe one bug to another, it is best to compare the data on both and transfer any missing information to the 'live' bug. This bug already lists 2.2 (as well as 2.1 and 2.0) as affected but it was 'left off' of the other bug. I'll add that information to it now.

Comment 12

[John Lu [:mnjul][Please NI or I'll miss]]

Thanks Joshua, I'll take extra notice next time.