944215 - OSK not appearing on the first tap under Navigation App Bar (also not dismissing)

Status: VERIFIED FIXED

(Firefox for Metro Graveyard :: Input, defect, P2)

Description

[Kamil Jozwiak [:kjozwiak]]

Attachment: OSK issues with the navigation app bar

When tapping on the navigation app bar, the OSK will not appear the first time around. It will only appear when you tap on the navigation app bar the second time around. Once the OSK slides in, tapping on the awesome screen will not dismiss the OSK. (had to press ESC to dismiss it)

- Attached a short video to illustrate the issue

Steps to reproduce the issue:

1) Open Firefox Metro
2) Once opened, tap on the navigation app bar and you'll notice that the OSK doesn't appear the first time around
3) Tap on the navigation app bar the second time around and the OSK should slide in from the bottom
4) Once the OSK is visible, try tapping anywhere on the awesome screen and you'll notice that the OSK will not be dismissed

Current Behavior:

- Tapping on the navigation app bar the first time around doesn't slide in the OSK. Once the OSK is visible, tapping on the screen doesn't dismiss the OSK

Expected Behavior:

- As a user, I expect the OSK to appear the first time around when tapping on the navigation app bar. Once the OSK is visible, tapping website should dismiss the OSK.

Comment 1

[Jim Mathies [:jimm]]

This doesn't appear to be widget related. MetroInput flushes pointer input prior to the call from windows seeking the focused element. The element accessibility returns isn't editable. We get a focus changed event much later.

mozilla::widget::winrt::MetroInput::OnPointerEntered
mozilla::widget::winrt::MetroInput::OnPointerPressed
mozilla::widget::winrt::MetroInput::OnPointerMoved
mozilla::widget::winrt::MetroInput::OnPointerReleased
mozilla::widget::winrt::MetroInput::OnTapped
mozilla::widget::winrt::MetroInput::HandleTap
MetroAppShell::MarkEventQueueForPurge
MetroAppShell::DispatchAllGeckoEvents
mozilla::widget::winrt::UIABridge::get_ProviderOptions
UIABridge::GetPropertyValue: idProp=UIA_NativeWindowHandlePropertyId
mozilla::widget::winrt::UIABridge::Navigate
UIABridge::Navigate NavigateDirection_Parent
mozilla::widget::winrt::UIABridge::get_ProviderOptions
mozilla::widget::winrt::UIABridge::get_ProviderOptions
mozilla::widget::winrt::UIABridge::Navigate
UIABridge::Navigate NavigateDirection_Parent
mozilla::widget::winrt::UIABridge::GetFocus
Focus element flags: editable:0 focusable:1 readonly:1

^^ focused element info returned by a11y

mozilla::widget::winrt::UIATextElement::ClearFocus
UIABridge::GetPropertyValue: idProp=UIA_IsControlElementPropertyId
UIABridge::GetPropertyValue: idProp=UIA_NativeWindowHandlePropertyId
mozilla::widget::winrt::UIABridge::get_BoundingRectangle
UIABridge::GetPropertyValue: idProp=UIA_ControlTypePropertyId
UIABridge::GetPropertyValue: idProp=49209
UIABridge: Unhandled property
UIABridge::GetPropertyValue: idProp=49232
UIABridge: Unhandled property
mozilla::widget::winrt::UIABridge::GetPatternProvider
UIABridge::GetPatternProvider=10014
mozilla::widget::winrt::UIABridge::GetPatternProvider
UIABridge::GetPatternProvider=10029
UIABridge::GetPropertyValue: idProp=UIA_IsPasswordPropertyId
mozilla::widget::winrt::MetroInput::OnPointerExited
### SelectionPrototype.js loaded
mozilla::widget::winrt::UIABridge::FocusChangeEvent
Focus element flags: editable:1 focusable:1 readonly:0

^^ delayed focus change event to the nav bar edit

Comment 2

[Jim Mathies [:jimm]]

We had a bug like this a while back, some sort of missing xul property. Anyone remember what that was?

Comment 3

[Sam Foster [:sfoster] (he/him)]

That was bug 903866, which hinged on a missing "visible" attribute on the appbar.

Comment 4

[Kamil Jozwiak [:kjozwiak]]

I will try finding the regression window when I get home tonight

Comment 5

[Kamil Jozwiak [:kjozwiak]]

Hi Jim,

Here's the regression window, please let me know if you need anything else.

Working Correctly:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-11-25-03-02-01-mozilla-central/
- Taping on the Navigation App Bar several times and always receive the OSK the first time around

Working Correctly:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-11-26-03-02-01-mozilla-central/
- Taping on the Navigation App Bar several times and always receive the OSK the first time around

Not Working:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-11-27-03-02-01-mozilla-central/
- Receive the OSK on the second tap rather than the first tap

Not working:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-11-28-03-02-01-mozilla-central/
- Receive the OSK on the second tap rather than the first tap

Comment 6

[Matt Brubeck (:mbrubeck)]

Pushes in the regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=53d55d2d0a25&tochange=6ecf0c4dfcbe

Maybe a regression from bug 940952 or bug 943451.

Comment 7

[Matt Brubeck (:mbrubeck)]

Or maybe bug 840855.  There are several other possible candidates in that range too, but these are the only ones that jumped out at me.

Comment 8

[Jim Mathies [:jimm]]

(In reply to Matt Brubeck (:mbrubeck) from comment #7)
> Or maybe bug 840855.  There are several other possible candidates in that
> range too, but these are the only ones that jumped out at me.

That looks like the right suspect.

Comment 9

[Jim Mathies [:jimm]]

(In reply to Jim Mathies [:jimm] from comment #8)
> (In reply to Matt Brubeck (:mbrubeck) from comment #7)
> > Or maybe bug 840855.  There are several other possible candidates in that
> > range too, but these are the only ones that jumped out at me.
> 
> That looks like the right suspect.

huh, maybe not. I backed this out and can still reproduce.

Comment 10

[Jim Mathies [:jimm]]

Attachment: fix v.1

This brings back the logic in bug 840855 but with some improvements: Instead of remaining in the state where we don't dispatch native events (which can cause lock ups when we happen to get caught in a js modal loop, the cause of bug 840855) only filter those events until MetroInput tells MetroAppShell that the events it wanted purged are.

Also, when we call NS_ProcessPendingEvents, don't do it with a 0 timeout. NS_ProcessPendingEvents will break out too early sometimes with this set. It will normally break out when the queue is completely empty, which is the desired behavior. 50msec is more than enough time to get things cleared in this particular case (waiting on OnTapped events to dispatch) while protecting this logic from weird cases where there may be an endless stream of gecko events to deal with.

Comment 12

[Brian R. Bondy [:bbondy]]

Comment on attachment 8348267 [details] [diff] [review]
fix v.1

Review of attachment 8348267 [details] [diff] [review]:
-----------------------------------------------------------------

::: widget/windows/winrt/MetroAppShell.cpp
@@ +27,5 @@
>  
>  // ProcessNextNativeEvent message wait timeout, see bug 907410.
>  #define MSG_WAIT_TIMEOUT 250
> +// MetroInput will occasionally ask us to flush all input so that the dom is
> +// up to date. This is the maximum amount of time we'll agree to spend in 

nit: trailing whitespace

Comment 13

[Jim Mathies [:jimm]]

https://hg.mozilla.org/integration/fx-team/rev/3081a09d97a7

Comment 14

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/3081a09d97a7

Comment 15

[Jim Mathies [:jimm]]

Comment on attachment 8348267 [details] [diff] [review]
fix v.1

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 840855
User impact if declined: buggy soft keyboard support
Testing completed (on m-c, etc.): yes
Risk to taking this patch (and alternatives if risky): low
String or IDL/UUID changes made by this patch: none

Comment 16

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/7a111c6c9aee

Comment 17

[u279076]

Kamil, please verify this is fixed now in Firefox 28 and 29.

Comment 18

[Rodrigo Silveira [:rsilveira] [:rodms]]

This fix regressed bug 840855 :(

Comment 19

[Kamil Jozwiak [:kjozwiak]]

Went through the following defect for iteration #20 with some issues. Used the following builds:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-12-28-03-02-04-mozilla-central/
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-12-28-00-40-02-mozilla-aurora/

Used the below test cases against about:start & several different websites:

- Went through the original test case from comment #0 without any issues
- Ensured taping the URL bar under the Navigation App Bar slides the OSK into view on the first tap
- Ensured that taping on the screen will dismiss the OSK every single time if its visible
- Ensured that using the physical keyboard dismisses the OSK every single time if its visible
- Ensured that you can dismiss the OSK by sliding the Navigation App Bar from view (both up/down directions)
- Ensured that you can dismiss the OSK by pressing "ESC" on the physical keyboard
- Ensured that you can dismiss the OSK using the "dismiss button" under the OSK itself
- Ensured that all of the above test cases worked with filled view
- Ensured that all of the above test cases worked with snapped view

Issues:

Looks like this is still an issue with both Aurora (Firefox 29)/Nightly (Firefox 29) while in filled view. If you move Firefox Metro into filled view, taping on the URL bar under the Navigation App Bar will not always appear. Added STR below:

Steps to reproduce the issue:

1) Open Firefox Nightly/Aurora
2) If it's a fresh install, tap the "About Us" tile under "Bookmarks"
3) Once the website has completely loaded, tap on the URL bar a few times (the OSK should be appearing every single time)
4) Slide in the desktop from the left side and snap it (in Windows 8.1, the screen should be 50/50)
5) Tap on the URL bar once again while in filled view (Should notice that the OSK won't appear when taping on the URL bar)

If you move Firefox Metro back into full view, the OSK will appear every single time when taping on the URL bar. It doesn't always happen either, so Step #3 - #5 might have to be repeated a few times. (I usually can reproduce the problem on the first or second attempt)

Comment 20

[Kamil Jozwiak [:kjozwiak]]

Attachment: OSK not at times while in filled view

Attached a quick video to illustrate the issue. Notice that taping on the URL bar under the Navigation App Bar doesn't slide in the OSK into view while Firefox Metro is in filled view.

Comment 21

[u279076]

(In reply to Kamil Jozwiak [:kjozwiak] from comment #20)
> Created attachment 8351684 [details]
> OSK not at times while in filled view

This is bug 956102. Aside from that, is this fixed for you?

Comment 22

[Kamil Jozwiak [:kjozwiak]]

Yup, went through the issue again using the test cases from comment #0 & comment #19 without any issues other than Bug 956102. Used the following builds:

- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-01-07-03-02-02-mozilla-central/
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-01-07-00-40-03-mozilla-aurora/

Comment 23

[Manuela Muntean [Away]]

Verified as fixed for iteration #22, with both latest Nightly and Aurora on Surface pro 2 with Windows 8.1 64-bit.