Closed Bug 833305 Opened 8 years ago Closed 7 years ago

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

Categories

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

x86_64
Windows 8.1
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jimm, Assigned: jimm)

References

()

Details

(Whiteboard: [forms] feature=story c=Content_features u=metro_firefox_user p=8)

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.
Assignee: jmathies → nobody
Whiteboard: [metro-mvp?]
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.
Whiteboard: [metro-mvp?]
Blocks: 831941
Blocks: 843812
No longer blocks: metrov1triage
Priority: -- → P1
Whiteboard: feature=work
No longer blocks: 831941
No longer blocks: 843812
Hey Asa, which story should this work item be related to?
Flags: needinfo?(asa)
Blocks: 831982
Summary: Sporadic soft keyboard display when taping form input / address bar text edit → Work - Sporadic soft keyboard display when taping form input / address bar text edit
Flags: needinfo?(asa)
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
Duplicate of this bug: 852048
Whiteboard: feature=work → [forms] feature=work
Whiteboard: [forms] feature=work → [forms] feature=work p=10
Whiteboard: [forms] feature=work p=10 → [forms] feature=work p=8
Assignee: nobody → jmathies
New story required.
Blocks: 831565
No longer blocks: 831982
Flags: needinfo?(asa)
Priority: P1 → P2
QA Contact: jbecerra
Summary: Work - Sporadic soft keyboard display when taping form input / address bar text edit → Story - Sporadic soft keyboard display when taping form input / address bar text edit
Whiteboard: [forms] feature=work p=8 → feature=story c=Content_features u=metro_firefox_user p=8
Depends on: 855232
Assignee: jmathies → nobody
Component: Input → Metro Operations
Product: Firefox for Metro → Tracking
Version: Trunk → ---
Blocks: 831982
Whiteboard: feature=story c=Content_features u=metro_firefox_user p=8 → [forms] feature=story c=Content_features u=metro_firefox_user p=8
No longer blocks: 831982
Depends on: skb
Priority: P2 → P3
Priority: P3 → P2
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Temporarily reopening to add to Iteration #5.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: nobody → jmathies
Blocks: metrov1it5
No longer blocks: metrov1backlog
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Flags: needinfo?(asa)
Depends on: 877170
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.
Status: RESOLVED → REOPENED
Depends on: 863676
Resolution: FIXED → ---
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?
No longer depends on: 863676
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.
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
OS: Windows 8 Metro → Windows 8.1
Product: Tracking → Tracking Graveyard
You need to log in before you can comment on or make changes to this bug.