Closed Bug 944215 Opened 6 years ago Closed 6 years ago

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

Categories

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

x86_64
Windows 8.1
defect

Tracking

(firefox28 verified, firefox29 verified)

VERIFIED FIXED
Firefox 28
Tracking Status
firefox28 --- verified
firefox29 --- verified

People

(Reporter: kjozwiak, Assigned: jimm)

References

()

Details

(Keywords: regression, Whiteboard: [beta28] [defect] p=1)

Attachments

(3 files)

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.
Whiteboard: feature=defect c=firefox_app_bar_and_autocomplete u=metro_firefox_user p=0 → [triage] feature=defect c=firefox_app_bar_and_autocomplete u=metro_firefox_user p=0
Whiteboard: [triage] feature=defect c=firefox_app_bar_and_autocomplete u=metro_firefox_user p=0 → [release28] feature=defect c=firefox_app_bar_and_autocomplete u=metro_firefox_user p=0
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
We had a bug like this a while back, some sort of missing xul property. Anyone remember what that was?
That was bug 903866, which hinged on a missing "visible" attribute on the appbar.
Whiteboard: [release28] feature=defect c=firefox_app_bar_and_autocomplete u=metro_firefox_user p=0 → [beta28] feature=defect c=firefox_app_bar_and_autocomplete u=metro_firefox_user p=0
I will try finding the regression window when I get home tonight
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
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.
(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.
Assignee: nobody → jmathies
Whiteboard: [beta28] feature=defect c=firefox_app_bar_and_autocomplete u=metro_firefox_user p=0 → [beta28] feature=defect c=firefox_app_bar_and_autocomplete u=metro_firefox_user p=1
Blocks: metrov1it21
No longer blocks: metrov1backlog
Status: NEW → ASSIGNED
Priority: -- → P2
QA Contact: jbecerra
(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.
Attached patch fix v.1Splinter Review
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.
Attachment #8348267 - Flags: review?(netzen)
Blocks: 950832
Duplicate of this bug: 950944
Blocks: 929862
No longer blocks: 929862
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
Attachment #8348267 - Flags: review?(netzen) → review+
https://hg.mozilla.org/mozilla-central/rev/3081a09d97a7
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
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
Attachment #8348267 - Flags: approval-mozilla-aurora?
Attachment #8348267 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Target Milestone: Firefox 29 → Firefox 28
Kamil, please verify this is fixed now in Firefox 28 and 29.
Flags: needinfo?(kamiljoz)
This fix regressed bug 840855 :(
Depends on: 952324
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)
Status: RESOLVED → REOPENED
Flags: needinfo?(kamiljoz)
Resolution: FIXED → ---
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.
Blocks: metrov1it22
No longer blocks: metrov1it21
Blocks: 956102
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Summary: Defect - OSK not appearing on the first tap under Navigation App Bar (also not dismissing) → OSK not appearing on the first tap under Navigation App Bar (also not dismissing)
Whiteboard: [beta28] feature=defect c=firefox_app_bar_and_autocomplete u=metro_firefox_user p=1 → [beta28] [defect] p=1
(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?
Verified as fixed for iteration #22, with both latest Nightly and Aurora on Surface pro 2 with Windows 8.1 64-bit.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.