Closed Bug 1166917 Opened 9 years ago Closed 9 years ago

[System] 'Select' dialog window AND keyboard can be present on screen simultaneously if activated in close succession

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.1 unaffected, b2g-v2.2 wontfix, b2g-master fixed)

RESOLVED WONTFIX
Tracking Status
b2g-v2.1 --- unaffected
b2g-v2.2 --- wontfix
b2g-master --- fixed

People

(Reporter: onelson, Assigned: timdream)

References

()

Details

(Keywords: regression, Whiteboard: [3.0-Daily-Testing])

Attachments

(1 file)

Description:
If a user attempts to process a 'Select' dialog window (set of options that may be checked, consumes UI space) and spawn a keyboard from activating a text field, they may observe a state where both become on screen at the same time. The 'Select' dialog will contain itself to the space the keyboard does not occupy.
Multiple UI pages that offer the ability to see this occur:
* Email Manual Setup: SSL + any text field
* Clock: Create New alarm: Alarm name + Repeat
* Settings: Network Settings, Join Hidden Network: Security + Network name

Repro Steps:
1) Update a Flame to 20150520010202
2) Open the Clock app
3) Create new alarm
4) Tap the 'Repeat' select dialog button and immediately after tap the 'Alarm name' text field.
5) Observe UI

Actual:
'Select' UI dialog shows on screen the same time as a keyboard if summoned close together

Expected:
'Select' UI dialog or keyboard shows on screen, event is picked by priority between them


Environmental Variables:
----------------------------------

Device: Flame 3.0
Build ID: 20150520010202
Gaia: 600fd8249960b8256af9de67d9171025bb9a3ff3
Gecko: ac277e615f8f
Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67
Version: 41.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Device: Flame 2.2
BuildID: 20150520002502
Gaia: 63e9eeec3032318f8a240f80b6a184fa4b50b6e1
Gecko: a89755309dea
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
*****************************

Issue DOES NOT REPRO on 2.1 for flame devices:
Results: 'Select' UI dialog or keyboard shows on screen, event is picked by priority between them. On proper timing, attempting to enable both has the appearance of picking netiher (one attempted to open, then a subsequent tap 'outside' the activity closed it).

Device: Flame 2.1
BuildID: 20150520001201
Gaia: c80865cb0bf73f1b97defbc646083b404feb3ac4
Gecko: bf8615dd05d6
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 34.0 (2.1) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
----------------------------------


Repro frequency: 5/5 (timing based)
See attached: 
video- https://youtu.be/uBFTK-BiPyI
logcat
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: regression
Component: Gaia::System → Gaia::System::Window Mgmt
Requires quick inputs. NI Windows Management owner for blocking input on this bug.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga) → needinfo?(hcheng)
Alive, any ideas?
Flags: needinfo?(alive)
Looks like we are having two events at the same time from gecko? Is this because gecko does not swallow the continuous focus events anymore? Transfer NI to Tim.
Component: Gaia::System::Window Mgmt → Gaia::System::Input Mgmt
Flags: needinfo?(alive) → needinfo?(timdream)
Must be a regression during InputWindowManager work etc. We had some complex wiring between ValueSelector and KeyboardManager before that.

As the timing between events will be changed again in bug 1162360, let's address this after that.

I would advice not to block release on this because it's something recoverable and it would take a special timed gesture to trigger.
Assignee: nobody → timdream
Flags: needinfo?(timdream)
I can no longer reproduce this bug when I apply the first Gecko patch of bug 1162360.

Instead of dup'ing them I will set a dependency here, since bug 1162360 will not be reaching v2.2.
Depends on: 1162360
Actually, the two comments above kind of contradict to each other...
Do not nominate since this is a corner case
Flags: needinfo?(hcheng)
Please help me test the latest master with bug 1162360 included.
Keywords: qawanted
I could reproduce this on the reporters build but not on the latest Flame 3.0

The keyboard and "repeat" menu did not appear together on the screen.

Device: Flame 3.0(Full Flash)(KK)(319mb)
BuildID: 20150616010205
Gaia: 62ba52866f4e5ca9120dad5bfe62fc5df981dc39
Gecko: ce863f9d8864
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 41.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

------------------------

This still occurs on the latest Flame 2.2

The keyboard and "repeat" menu can appear together on the screen.

Device: Flame 2.2(Full Flash)(KK)(319mb)
BuildID: 20150616002505
Gaia: e7a0c6d5f4df04d45fb3f726efb9e8223600cb79
Gecko: 8045028bf400
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
(In reply to KTucker [:KTucker] from comment #9)
> I could reproduce this on the reporters build but not on the latest Flame 3.0

You could *NOT* I presume?

To fix this we would need to uplift bug 1162360, but I am not sure about the risk. Josh, as the release manager, could you make a decision here? If we decide not to fix it I will close this bug as WONTFIX. Thanks!
Flags: needinfo?(jocheng)
Hi Tim, Hi Kevin,
Since we have passed 2.2 CC and this is timing issue. I do not think we need this for 2.2 now unless same issue reported by Chipset/OEM on 2.2 device branch later.
Thanks!
Flags: needinfo?(jocheng)
Please reopen if there is a need for 2.2 branch.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: