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.

Is this clicking only or clicking and tapping?

(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.

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

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.

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.

(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

New story required.

Temporarily reopening to add to Iteration #5.

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.

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.

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.

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?

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.