833305 - Story - Sporadic soft keyboard display when taping form input / address bar text edit

Status: RESOLVED FIXED

(Tracking Graveyard :: Metro Operations, defect, P2)

Description

[Jim Mathies [:jimm]]

STR:

1) click a form input, bing home page works well

expected: soft keyboard comes up
result: sometimes it comes up, sometimes it doesn't

In the debugger, I see the keyboard being displayed and hidden in quick succession, so I think we might have a focus related issue in front end code.

Comment 1

[Asa Dotzler [:asa]]

Is this clicking only or clicking and tapping?

Comment 2

[Jim Mathies [:jimm]]

(In reply to Asa Dotzler [:asa] from comment #1)
> Is this clicking only or clicking and tapping?

Tapping. (The mouse doesn't bring up the sk.) This bug is still present in currently nightly.

Comment 3

[Marco Mucci [:MarcoM]]

Hey Asa, which story should this work item be related to?

Comment 4

[Jim Mathies [:jimm]]

I did some debugging on this earlier in the week. I think the problem here is that we rely on accessible observer events to update focus state in our uia bridge down in widget. Unfortunately the observers fire off the refresh timer, so they can come delayed, after the last input event has been sent. For example:

mozilla::widget::winrt::MetroInput::OnPointerEntered
mozilla::widget::winrt::MetroInput::OnPointerPressed
MetroWidget::GetDPI
mozilla::widget::winrt::MetroInput::OnPointerReleased
mozilla::widget::winrt::MetroInput::OnTapped
UIABridge::GetFocus focus=0
UIATextElement::get_BoundingRectangle 0.000000 0.000000 0.000000 0.000000
mozilla::widget::winrt::UIATextElement::get_IsReadOnly
mozilla::widget::winrt::MetroInput::OnPointerExited
Bridge: EVENT_FOCUS
Bridge: Focus element flags: 1 1 0
Bridge: focus item can be focused
mozilla::widget::winrt::UIABridge::SetFocusInternal
mozilla::widget::winrt::UIABridge::SetFocus
mozilla::widget::winrt::UIATextElement::SetFocusInternal
mozilla::widget::winrt::UIATextElement::SetFocus

What we probably have to do here is query the accessible tree in realtime when windows asks us about it. Starting with the call to UIABridge::GetFocus, which queries for the focused IRawElementProviderFragment. Internally accessible should be up to date at this point.

Comment 5

[Jim Mathies [:jimm]]

There is a relatively easy work around for now - use a slow double tab on text inputs. The first tap will fail but will test the appropriate focus information in the bridge, the second will make windows re-query for the new focus information stored in the bridge.

Comment 6

[Jim Mathies [:jimm]]

(In reply to Jim Mathies [:jimm] from comment #5)
> There is a relatively easy work around for now - use a slow double tab on
> text inputs. The first tap will fail but will test the appropriate focus
> information in the bridge, the second will make windows re-query for the new
> focus information stored in the bridge.

s/test/store

Comment 8

[Marco Mucci [:MarcoM]]

New story required.

Comment 9

[Marco Mucci [:MarcoM]]

Temporarily reopening to add to Iteration #5.

Comment 10

[Kamil Jozwiak [:kjozwiak]]

Went through the following "Defect" for iteration #7 and ran into the same issue. Used the following build:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-05-28-03-09-42-mozilla-central/

I reproduced the issue several times when going through google.com. Sometimes the OSK doesn't appear once you tap on the "search" field. Happened a few times at bing.com but it seems to be occurring a lot more with Google (for me at least)

Its A LOT better then it was before, and the OSK appears at least 95% of the time on my end but there are still some issues.

Comment 11

[Kamil Jozwiak [:kjozwiak]]

Went through the following "Defect" for iteration #8 and ran into some issues. Used the following build:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-06-16-03-11-39-mozilla-central/

When going through this "Defect", the OSK is still sporadically appearing at times. Attempted this in both Bing/Google/DuckDuckGo and reproduced the problem.

Will mark this as passed for iteration #8 as Bug 863676 covers the issue and no new issues have been found.

Comment 12

[Kamil Jozwiak [:kjozwiak]]

Went through the following "Defect" for iteration #9 and ran into some issues. Used the following build:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-07-03-03-13-23-mozilla-central/

Same issues are occurring as described in comment 10 & comment 11

Will mark this as passed for iteration #9 as Bug 863676 covers the issue and no new issues have been found.

Comment 13

[Jim Mathies [:jimm]]

I'm tempted to resolve this as a dupe to story bug 855297. I reopened so qa folks don't have to keep validating a story that isn't actually fixed. Marco, thoughts?

Comment 14

[Marco Mucci [:MarcoM]]

I removed the open dependency because it's already covered in Bug 855297.  I'll remove this from the testing spreadsheet so it is no longer tested moving forward.  Testing will focus on Bug 855297 when it is completed in the future.