903866 - [MP] Defect - Soft keyboard does not display when the user taps the nav bar edit / text input(?)

Status: VERIFIED FIXED

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

Description

[denninger.philipp]

User Agent: Mozilla/5.0 (Windows NT 6.2; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20130811030225

Steps to reproduce:

i'm working with a tablet pc (acer icona w510) with win8 32bit (not RT)...
starting nightly and tapped into a text entering field (url....and google search field)


Actual results:

nothing happened....
cursor showed up in the desired field, but the keyboard did not pop up!
in the desktop program window of firefox it is possible to activate the popup keyboard manually, but not in the metro version.


Expected results:

popup keyboard should show up every time the cursor is set to a text entering field by the first tap.
additionally there should be one exception: if external keyboard is attached to tablet, the popup keyboard should not show up.

Comment 1

[Jim Mathies [:jimm]]

Would you mind telling us what kind of tablet your having problems on?

Comment 2

[Asa Dotzler [:asa]]

I think this may be a general problem with Atom tablets though I don't yet have proof of that.

Comment 3

[Asa Dotzler [:asa]]

Reporter sees it in Iconia w510.  I see it with my Dell Latitude 10.

Comment 4

[Jonathan Wilde [:jwilde]]

Turns out the Acer Iconia W700 (which I'm having issues with) is actually a Core i5, not an Atom.

Comment 5

[Kamil Jozwiak [:kjozwiak]]

I had this happen to me on the Lenovo X1 Carbon. I was selecting text fields and the OSK wouldn't appear. Once I restarted Firefox Metro, the OSK started appearing without any issues when selecting text fields.

Will try to get some STR and attach them to this ticket. Doesn't occur 100% on my end at least.

Comment 6

[Jim Mathies [:jimm]]

Attachment: forms.html

Here are a few handy form inputs to test with. In testting/posting str please differentiate between urlbar edit issues and content issues.

Comment 7

[Sebastian Sbstn]

I have the same bug with all Firefox versions. The Touch Keyboard doesnt pop up when typing in a text field.
Hardware: Microsoft Surface Pro | Windows 8 Pro
Intel Core i5 (Ivy-Bridge)
4Gb Ram

Comment 8

[Jim Mathies [:jimm]]

(In reply to Sebastian Sbstn from comment #7)
> I have the same bug with all Firefox versions. The Touch Keyboard doesnt pop
> up when typing in a text field.
> Hardware: Microsoft Surface Pro | Windows 8 Pro
> Intel Core i5 (Ivy-Bridge)
> 4Gb Ram

Are you seeing this in page edits, or in the nav bar, or both?

Do you have a physical keyboard attached to the device?

Comment 11

[Sebastian Sbstn]

(In reply to Jim Mathies [:jimm] from comment #8)
> (In reply to Sebastian Sbstn from comment #7)
> > I have the same bug with all Firefox versions. The Touch Keyboard doesnt pop
> > up when typing in a text field.
> > Hardware: Microsoft Surface Pro | Windows 8 Pro
> > Intel Core i5 (Ivy-Bridge)
> > 4Gb Ram
> 
> Are you seeing this in page edits, or in the nav bar, or both?
> 
> Do you have a physical keyboard attached to the device?


I've tried the nav bar only. In metro mode i cant do anything cause there no keyboard is popping up.
yes i have a physical keyboard and this works.

Comment 12

[Matt Brubeck (:mbrubeck)]

I can reproduce this on a Samsung Series 7 Slate with no hardware keyboard.

I think this regressed between the 2013-08-10 and 2013-08-11 mozilla-central nightly builds:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c5946a8bcd5b&tochange=3d20597e0a07

It would be useful to verify this, and figure out which exact changeset caused the regression.

Comment 13

[Matt Brubeck (:mbrubeck)]

(In reply to Matt Brubeck (:mbrubeck) from comment #12)
> I think this regressed between the 2013-08-10 and 2013-08-11 mozilla-central
> nightly builds

Sorry, that was wrong.  The actual nightly regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?tochange=c5946a8bcd5b&fromchange=e33c2011643e

Comment 14

[Jim Mathies [:jimm]]

Likely bug 902713. I just need to figure out what I broke.

Comment 15

[Jim Mathies [:jimm]]

I think I see it - 

http://hg.mozilla.org/mozilla-central/rev/48879353a32c#l4.24

Comment 16

[Jim Mathies [:jimm]]

(In reply to Jim Mathies [:jimm] from comment #15)
> I think I see it - 
> 
> http://hg.mozilla.org/mozilla-central/rev/48879353a32c#l4.24

This wasn't the problem.

I'm still not sure what's going on here. Accessibility reports that the focused element is the document rather than the edit, so somewhere our focus setting is getting messed up.

Comment 17

[Jim Mathies [:jimm]]

confirmed this is the regression range - 

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e33c2011643e&tochange=c5946a8bcd5b

Comment 18

[dusten.jacobs]

Also having this issue on my Surface Pro, with (folded back) or without my touch keyboard cover attached. Touching input fields on websites automatically activates the soft touch keyboard, but not when tapping into the URL bar. I am able to manually activate the soft touch keyboard through settings - keyboard.

Hardware: Microsoft Surface Pro w/ Windows 8 Pro
Nightly Build Version: 26.0a1

Comment 19

[Jim Mathies [:jimm]]

Not sure why, but we start with the html input element here and always walk up to the root document accessible here - 

http://mxr.mozilla.org/mozilla-central/source/accessible/src/generic/DocAccessible.cpp#1276

I think mActiveItem should be getting set here - 

http://mxr.mozilla.org/mozilla-central/source/accessible/src/base/FocusManager.cpp#233

which uses the same routine GetAccessibleOrContainer. Instead mActiveItem is left as null.

Comment 20

[Jim Mathies [:jimm]]

Similarly here - 

http://mxr.mozilla.org/mozilla-central/source/accessible/src/base/FocusManager.cpp#247

FocusedDOMNode() returns the html input element, but GetAccessible() - 

http://mxr.mozilla.org/mozilla-central/source/accessible/src/generic/DocAccessible.cpp#528

doesn't find the element in its mNodeToAccessibleMap cache. That seem to be the root of the problem.

Comment 21

[Jim Mathies [:jimm]]

Maybe accessibility folks can help shed some light on this. I doubt it's a accessibility bug, but we're not getting expected behavior from that library for some reason.

Comment 22

[alexander :surkov (:asurkov)]

So the problem is focused HTML input is not accessbile. Does it happen on all platforms like can I observe it on desktop?

Comment 23

[Jim Mathies [:jimm]]

(In reply to alexander :surkov from comment #22)
> So the problem is focused HTML input is not accessbile. Does it happen on
> all platforms like can I observe it on desktop?

Yes it looks like this is reproducible when running the metro interface on desktop, both with mouse and touch input. You can load the interface using the command line param |firefox.exe -metrodesktop| in nightly, then open inspect.exe with the "watch focus" option. When you click or tap (on a touch input display) on the nav bar at the bottom, the focused control is the window for some reason.

Comment 24

[alexander :surkov (:asurkov)]

when I do firefox.exe -metrodesktop then I see ordinal Firefox, is it what I should see?

Comment 25

[Jim Mathies [:jimm]]

(In reply to alexander :surkov from comment #24)
> when I do firefox.exe -metrodesktop then I see ordinal Firefox, is it what I
> should see?

No you should see the metro interface in a single desktop window, much like an emulator. Are you working with a nightly or local build?

Comment 26

[alexander :surkov (:asurkov)]

local one, do I need to fix my mozconfig

Comment 27

[Jim Mathies [:jimm]]

(In reply to alexander :surkov from comment #26)
> local one, do I need to fix my mozconfig

yes, add |--enable-metro|.

Comment 28

[gilles.orsini]

same issue with my asus vivo tab smart (me400c, not RT), windows 8, firefox build  26.0a1 2013-08-28.
soft keyboard normally show up if i focus an input text into an html page, issue only in address bar.

Comment 30

[Jim Mathies [:jimm]]

Currently not working on this, if anyone else wants to pick it up feel free.

Comment 32

[alexander :surkov (:asurkov)]

(In reply to Jim Mathies [:jimm] from comment #23)
> (In reply to alexander :surkov from comment #22)
> > So the problem is focused HTML input is not accessbile. Does it happen on
> > all platforms like can I observe it on desktop?
> 
> Yes it looks like this is reproducible when running the metro interface on
> desktop, both with mouse and touch input. You can load the interface using
> the command line param |firefox.exe -metrodesktop| in nightly, then open
> inspect.exe with the "watch focus" option. When you click or tap (on a touch
> input display) on the nav bar at the bottom, the focused control is the
> window for some reason.

seems like working for me on nightly. When I click at 'Enter Search or Address" entry then I see

How found:	Focus [o:0xFFFFFFFFFFFFFFFC,c:0xFFFFFFFFFB3F36F8]
	hwnd=0x0000000000130476 32bit class="MozillaWindowClass" style=0x16CF0000 ex=0x100
ChildId:	0
Interfaces:	
Impl:	Remote native IAccessible
Name:	"Enter Search or Address"
Value:	[null]
Role:	editable text (0x2A)
State:	focused,focusable (0x100004)
Location:	{l:304, t:880, w:1059, h:20}
Selection:	
Description:	""
Kbshortcut:	""
DefAction:	"activate"
Help:	[null]
HelpTopic:	""
ChildCount:	0
Window:	0x130476
FirstChild:	[Error: hr=0xFFFFFFFF80004005 - Unspecified error]
LastChild:	[Error: hr=0xFFFFFFFF80004005 - Unspecified error]
Next:	[Error: hr=0xFFFFFFFF80004005 - Unspecified error]
Previous:	[Error: hr=0xFFFFFFFF80004005 - Unspecified error]
Left:	[Error: hr=0xFFFFFFFF80004001 - Not implemented]
Up:	[Error: hr=0xFFFFFFFF80004001 - Not implemented]
Right:	[Error: hr=0xFFFFFFFF80004001 - Not implemented]
Down:	[Error: hr=0xFFFFFFFF80004001 - Not implemented]
Other Props:	Object has no additional properties
Children:	Container has no children
Ancestors:	"Enter Search or Address" : combo box : collapsed,has popup
	none : tool bar : normal
	none : tool bar : normal
	"Nightly" : application : read only,sizeable,moveable,focusable
	"Nightly" : window : focused,sizeable,moveable,focusable
	"Desktop" : client : focusable
	"Desktop" : window : focusable
	[ No Parent ]

Comment 33

[Jim Mathies [:jimm]]

This isn't reproducible in all cases. Although I usually don't have much trouble getting it reproduce. Here's the inspect doc on my surface pro running in metrodesktop mode - 

How found:	Focus
Name:	"Nightly"
ControlType:	UIA_WindowControlTypeId (0xC370)
LocalizedControlType:	"window"
BoundingRectangle:	{l:11 t:45 r:1909 b:1013}
IsEnabled:	true
IsOffscreen:	false
IsKeyboardFocusable:	true
HasKeyboardFocus:	true
AccessKey:	""
ProcessId:	5256
RuntimeId:	[2A.D0578.2.80000001.D0578.FFFFFFFC.0]
ProviderDescription:	"[pid:5256,hwnd:0x0 Annotation:Microsoft: Annotation Proxy (unmanaged:uiautomationcore.dll); Main(parent link):Microsoft: MSAA Proxy (unmanaged:uiautomationcore.dll)]"
IsPassword:	false
HelpText:	""
LegacyIAccessible.ChildId:	0
LegacyIAccessible.Description:	""
LegacyIAccessible.Help:	""
LegacyIAccessible.KeyboardShortcut:	""
LegacyIAccessible.Name:	"Nightly"
LegacyIAccessible.Role:	application (0xE)
LegacyIAccessible.State:	focused,read only,sizeable,moveable,focusable (0x160044)
LegacyIAccessible.Value:	""
IsAnnotationPatternAvailable:	false
IsDragPatternAvailable:	false
IsDockPatternAvailable:	false
IsDropTargetPatternAvailable:	false
IsExpandCollapsePatternAvailable:	false
IsGridItemPatternAvailable:	false
IsGridPatternAvailable:	false
IsInvokePatternAvailable:	false
IsItemContainerPatternAvailable:	false
IsLegacyIAccessiblePatternAvailable:	true
IsMultipleViewPatternAvailable:	false
IsObjectModelPatternAvailable:	false
IsRangeValuePatternAvailable:	false
IsScrollItemPatternAvailable:	false
IsScrollPatternAvailable:	false
IsSelectionItemPatternAvailable:	false
IsSelectionPatternAvailable:	false
IsSpreadsheetItemPatternAvailable:	false
IsSpreadsheetPatternAvailable:	false
IsStylesPatternAvailable:	false
IsSynchronizedInputPatternAvailable:	false
IsTableItemPatternAvailable:	false
IsTablePatternAvailable:	false
IsTextChildPatternAvailable:	false
IsTextPatternAvailable:	false
IsTextPattern2Available:	false
IsTogglePatternAvailable:	false
IsTransformPatternAvailable:	false
IsTransform2PatternAvailable:	false
IsValuePatternAvailable:	false
IsVirtualizedItemPatternAvailable:	false
IsWindowPatternAvailable:	false
FirstChild:	"" 
LastChild:	"" tool bar
Next:	[null]
Previous:	"" title bar
Other Props:	Object has no additional properties
Children:	"" 
	"New Tab" text
	"Close Tab" button
	"New Tab" button
	"" 
	"" tool bar
Ancestors:	"Nightly" window
	"Desktop" 
	"Desktop" window
	[ No Parent ]

Comment 34

[Jim Mathies [:jimm]]

Here's the ally focus logging. This doesn't look right, the edit never receives focus. Alex can you diagnose anything from this?

mozilla::widget::winrt::MetroInput::OnPointerReleased
mozilla::widget::winrt::MetroInput::OnTapped
mozilla::widget::winrt::MetroInput::HandleSingleTap
MetroAppShell::MarkEventQueueForPurge
MetroAppShell::DispatchAllGeckoEvents

A11Y FOCUS: ; 45:09.635
  {
    Target: 0A2648B0; role: application, name: 'about:start';
    Target node: 0A4E7DE8, document
    Document: 0A2648B0, document node: 0A4E7DE8
    Document uri: about:start
  }

A11Y FOCUS: ; 45:09.641
  {
    Target: 09F95630, window
  }

A11Y FOCUS: ; 45:09.657
  {
    Target: 0A0BB1A8; role: chrome window, name: 'Nightly';
    Target node: 050BB3F0, document
    Document: 0A0BB1A8, document node: 050BB3F0
    Document uri: chrome://browser/content/browser.xul
  }
  sync notification processing

A11Y FOCUS: ; 45:09.672
  {
    Target: 050BB3F0, document
  }
  {
    A11y target: 0A0BB1A8; role: chrome window, name: 'Nightly';
    A11y target node: 050BB3F0, document
    Document: 0A0BB1A8, document node: 050BB3F0
    Document uri: chrome://browser/content/browser.xul
  }

A11Y FOCUS: ; 45:09.688
  {
    Target: 051ACB50, window
  }

A11Y FOCUS: ; 45:09.704
  {
    [not accessible] Target: 0996A288, input@id='', idx in parent: 1
    Document: 0A0BB1A8, document node: 050BB3F0
    Document uri: chrome://browser/content/browser.xul
  }
  sync notification processing

A11Y FOCUS: ; 45:09.704
  {
    Target: 0996A288, input@id='', idx in parent: 1
  }
  {
    A11y target: 0A0BB1A8; role: chrome window, name: 'Nightly';
    A11y target node: 050BB3F0, document
    Document: 0A0BB1A8, document node: 050BB3F0
    Document uri: chrome://browser/content/browser.xul
  }
  sync notification processing
  sync notification processing
### SelectionPrototype.js loaded
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
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=49214
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

A11Y FOCUS: ; 45:09.863
  {
    Target: 0A0BB1A8; role: chrome window, name: 'Nightly';
    Target node: 050BB3F0, document
    Document: 0A0BB1A8, document node: 050BB3F0
    Document uri: chrome://browser/content/browser.xul
  }
mozilla::widget::winrt::UIABridge::FocusChangeEvent

Comment 35

[alexander :surkov (:asurkov)]

from what I can tell the problem is entry is not accessible at all (neither its parent combobox/autocomplete). It'd be interesting to know why it doesn't get an accessible during tree creation time. If entry would have an accessible then I think we won't have any issue with focus.

Comment 36

[Jim Mathies [:jimm]]

(In reply to alexander :surkov from comment #35)
> from what I can tell the problem is entry is not accessible at all (neither
> its parent combobox/autocomplete). It'd be interesting to know why it
> doesn't get an accessible during tree creation time. If entry would have an
> accessible then I think we won't have any issue with focus.

Any idea what might cause that? Is there something front end script might be doing to get in the way?

Comment 37

[alexander :surkov (:asurkov)]

I would guess there's some layout miscommunication with accessibility. I'd start from 'tree' logging but I doubt it will show anything interesting; then I would set a breakpoint at tree creation (nsAccessibilitySerivice::GetOrCreateAccessible) and see why input or its whole parent subtree is rejected. For example if it doesn't have frames then it should mean we need extra hook to layout to notify a11y. It's hard to make a good guess since I don't know how metro version is different from desktop one.

Comment 38

[Stefan Seidel]

Interesting find on my Sony Ultrabook which has a keyboard but can be folded together for tablet mode:

- starting Nightly in "tablet mode" will produce the correct behaviour of triggering the software keyboard when the URL bar is touched.
  - if I slide the display up so that the keyboard is visible, no software keyboard comes up (correctly, as there is a physical keyboard)
  - I can slide it back to tablet mode and the software keyboard will come up again

but:
- when I start with the physical keyboard visible, no software keyboard will appear upon touching the URL bar (which is correct), but it will also NOT pop up when I switch to tablet mode, so it seems the physical keyboard state is never updated

Comment 39

[Asa Dotzler [:asa]]

This is a significant testing blocker.  We have to fix this for Aurora. What can we do here to get this moving?  Alexander, are you able to get set up with Metro and investigate this further? Did I correctly read that this could be a layout issue? Should we bring in someone from layout?

Comment 40

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

I suggest stripping back our urlbar binding right back to a textbox - at which point it (hopefully) works, and progressively adding stuff back in. And if it still doesn't work we've got a simpler test case to go digging into the internals with. 

The switch between physical keyboard and soft keyboard (where a physical keyboard is attached) should be like mouse/touch input - we need to be able to detect what we have and also switch modes on the fly.

Comment 41

[alexander :surkov (:asurkov)]

(In reply to Asa Dotzler [:asa] from comment #39)
> Alexander, are you able to get set up
> with Metro and investigate this further? 

I could but I hoped to get some help in debugging. If we knew what is broken then I would help with a fix.

> Did I correctly read that this
> could be a layout issue? Should we bring in someone from layout?

I'd rather say a layout feature, something that they do special for metro. But before getting an attention from layout folks it makes sense to figure out why that input is not accessible.

Comment 42

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to comment #34)

> A11Y FOCUS: ; 45:09.704
>   {
>     [not accessible] Target: 0996A288, input@id='', idx in parent: 1
>     Document: 0A0BB1A8, document node: 050BB3F0
>     Document uri: chrome://browser/content/browser.xul
>   }
>   sync notification processing
> 
> A11Y FOCUS: ; 45:09.704
>   {
>     Target: 0996A288, input@id='', idx in parent: 1
>   }
>   {
>     A11y target: 0A0BB1A8; role: chrome window, name: 'Nightly';
>     A11y target node: 050BB3F0, document
>     Document: 0A0BB1A8, document node: 050BB3F0
>     Document uri: chrome://browser/content/browser.xul
>   }

Looks like two duplicate focus events, one with an accessible and one without or am I reading the log wrong?

Comment 43

[David Bolter [:davidb] (NeedInfo me for attention)]

Alexander is digging into this one again.

Comment 44

[alexander :surkov (:asurkov)]

a minimal testcase is wanted. regardless of seeming simplicity of metro its XUL UI contains huge amount of elements and lot of mutation happens. So having no simpler test case it's hard to understand what's going there.

Comment 45

[David Bolter [:davidb] (NeedInfo me for attention)]

Matt do you know who could help us find a tighter regression window? Does metro have any go-to person for QA?

Comment 46

[Jim Mathies [:jimm]]

(In reply to David Bolter [:davidb] from comment #45)
> Matt do you know who could help us find a tighter regression window? Does
> metro have any go-to person for QA?

regression window is in comment 17. Not sure it helps much, we landed a big patch that ripped a huge xul panel out of chrome and moved it into a tab. There were some other landings obviously but nothing in accessibility afaict.

Comment 47

[alexander :surkov (:asurkov)]

(In reply to Jim Mathies [:jimm] from comment #46)
> (In reply to David Bolter [:davidb] from comment #45)
> > Matt do you know who could help us find a tighter regression window? Does
> > metro have any go-to person for QA?
> 
> regression window is in comment 17. Not sure it helps much, we landed a big
> patch that ripped a huge xul panel out of chrome and moved it into a tab.
> There were some other landings obviously but nothing in accessibility afaict.

so it sounds like that work just revealed deeply hidden a11y problems. So it especially makes sense to try to reduce it to simple test case (like remove everything but that url bar).

Comment 48

[Marco Mucci [:MarcoM]]

Juan Becerra is the main Metro QA contact:  [e-mail]

Comment 49

[juan becerra [:juanb]]

I will try to find a regression range. This problem has been around since August and it affects all tablets I have tried without a hardware keyboard, like the Iconia W3 or the Surface Pro (when you remove the keyboard).

Comment 50

[David Bolter [:davidb] (NeedInfo me for attention)]

Thanks Juan!

We also need a front-ender to help reduce the test case (as per comment 40 and comment 47). Sam is this something you or someone on your team could do?

Comment 51

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

I'm currently working on a patch that I hope will get us a reduced test case to isolate this issue.

Comment 52

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

Attachment: Bind urlbar-edit to the simpler textbox.xml#textbox binding

This patch just binds the urlbar input field (#urlbar-edit, in browser.xul) to the generic textbox.xml#textbox binding. This breaks normal url entry for the browser, but we're only interested in whether the urlbar gets focus and that focus correctly triggers the soft-keyboard. For me, on my X1 Carbon (attached physical keyboard) using touch to place focus I still get no soft keyboard with this patch. I think that rules out anything funky we are doing in Metro's XBL bindings. 

The textbox binding is a box around an html:input. We can further edit browser.xul to just inline some of that if necessary. Let me know how it looks.

Comment 53

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

Attachment: urlbar-edit as only UI

Here's the browser chrome reduced down to just the html:input field inside the window -> stack. This works - the soft keyboard is brought up when you place focus in the input. There are no uncaught exceptions logged. As far as possible, I've only removed chrome UI here, all the event handling should be intact. So, somewhere in between this and our complete chrome is the culprit - unless it working is just a side-effect of something I broke along the way. I'll proceed with adding it back in progressively to track it down.

Comment 54

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

Status update on this: 

I stripped back our chrome to a single html:input and verified we get proper focus and soft-keyboard behavior. Now I'm adding stuff back and looking at that regression range to figure out where we break it. So far I have the urlbar binding and contextual appbar back in with no soft-keyboard breakage. As soon as I've fingered a culprit I'll post a patch on here and we can discuss fixing it - if its not something missing on the front-end I can address myself

Comment 55

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

Attachment: appbar-default-visible

It turns out that we have rules that hide the navbar contents if there is no 'visible' attribute on the navbar element. Although the urlbar-edit field becomes visible, there must be a timing issue with how and when accessibility goes looking for accessible/focusable nodes. The result is bustage without the initial visible attribute, and happiness with it. 

We could turn the CSS logic inside out but I think having the explicit initial state works just as well.

Comment 56

[Matt Brubeck (:mbrubeck)]

Comment on attachment 806889 [details] [diff] [review]
appbar-default-visible

gah.  grar.  floggle

Comment 57

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

This patch landed on fx-team: https://hg.mozilla.org/integration/fx-team/rev/8765eebbaa95

:surkov, I'm working on a reduced test case so your team can take something away from this. I'll likely create a new bug for that, will link it here when I have it.

Comment 58

[alexander :surkov (:asurkov)]

(In reply to Sam Foster [:sfoster] from comment #57)
> This patch landed on fx-team:
> https://hg.mozilla.org/integration/fx-team/rev/8765eebbaa95
> 
> :surkov, I'm working on a reduced test case so your team can take something
> away from this. I'll likely create a new bug for that, will link it here
> when I have it.

sure, thank you

Comment 59

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/8765eebbaa95

Comment 60

[Marco Mucci [:MarcoM]]

Hi Juan, this bug was the Aurora blocker for Metro Preview.  Can you verify that it is fixed.

Comment 61

[juan becerra [:juanb]]

Tested on 2013-09-20 with the latest nightly on an Acer Iconia W3 (no hardware keyboard) and a Dell XPS 12 (laptop with touch screen).

On the Iconia W3 I can now get the software keyboard to come up when I tap in the location bar. When I do this the URL is pre-selected and the keyboard comes up, and I can start typing right away. This is similar to what IE does.

On the laptop when I tap the URL a similar thing happens. If I then start typing with the hardware keyboard, the sfk disappears.

One problem I noticed is that I cannot longer get a context menu on text fields. For example in the forms.html example, when you tap on any of the text fields and try to "select all" (with long tap) the context menu does not come up. This is not a regression from this fix, however, as it happens with builds prior to this.

Other skb functionality on desktop works as before and consistent with IE.

Comment 62

[Asa Dotzler [:asa]]

Are we still trying to get this fix into  Aurora before our first Aurora updates go out? If not, can we get it in the first update to Aurora?

Comment 63

[Matt Brubeck (:mbrubeck)]

Comment on attachment 806889 [details] [diff] [review]
appbar-default-visible

[Approval Request Comment]
Bug caused by (feature/regressing bug #): unknown (see regression range above)
User impact if declined: Metro users on tablets cannot type in the navbar
Testing completed (on m-c, etc.): verified by QA in nightly
Risk to taking this patch (and alternatives if risky): Very low risk.  One-line Metro-only change.
String or IDL/UUID changes made by this patch: None.

Comment 64

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

Juan, I can confirm the long-tap for context menu regression and also that it existed prior to this patch landing. I've filed bug 918937

Comment 65

[bhavana bajaj [:bajaj]]

Comment on attachment 806889 [details] [diff] [review]
appbar-default-visible

Given QA verification, approving this low risk patch to resolve this for our users in the first aurora update that they get.

Please land asap on aurora branch.

Comment 66

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/0ff4dcd55258

Comment 67

[Tracy Walker [:tracy]]

soft keyboard appears for me on a SurfacePro with latest Nightly build from 20131024

Comment 68

[Bogdan Maris, Desktop Test Engineering]

Tracy can you or anyone else that has access to a tablet PC please verify that this is fixed on the latest beta?

Comment 69

[Tracy Walker [:tracy]]

sorry, for the delay, this does not work for me on latest 26beta on same device from comment 67.  (then tried latest Nightly and it doesn't work either) :-/

Comment 70

[Tracy Walker [:tracy]]

nevermind previous comment...  this is metro.  checking it now.

Comment 71

[Tracy Walker [:tracy]]

the only version I am able to verify this is on Nightly.  I can't get a metro fx enabled on beta or aurora. am I missing something?

Comment 72

[Jim Mathies [:jimm]]

(In reply to [:tracy] Tracy Walker - QA Mentor from comment #71)
> the only version I am able to verify this is on Nightly.  I can't get a
> metro fx enabled on beta or aurora. am I missing something?

Thanks, confirming on nightly is sufficient.