Closed Bug 903866 Opened 11 years ago Closed 11 years ago

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

Categories

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

Product:
Firefox for Metro Graveyard
Component:
Input
Version:
26 Branch
Platform:
x86
Windows 8.1
Type:
defect

Tracking

(firefox26+ fixed, firefox27 verified)

Status:
VERIFIED FIXED
Milestone:
Firefox 27
Tracking Flags:
Tracking Status
firefox26 + fixed
firefox27 --- verified

People

(Reporter: denninger.philipp, Assigned: sfoster)

References

Details

(Keywords: regression, Whiteboard: [preview] feature=defect c=tbd u=tbd p=3)

Attachments

(4 files)

forms.html
(deleted), text/html
Details
Bind urlbar-edit to the simpler textbox.xml#textbox binding
(deleted), patch
Details | Diff | Splinter Review
urlbar-edit as only UI
(deleted), patch
Details | Diff | Splinter Review
appbar-default-visible
(deleted), patch
mbrubeck
: review+
bajaj
: approval-mozilla-aurora+
Details | Diff | Splinter Review 
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.
OS: All → Windows 8
Hardware: All → x86
Blocks: metrov1defect&change
Summary: tablet keyboard (win8, 32bit) does not pop up when cursor is in a tiping field. → Defect - Tablet keyboard (win8, 32bit) does not pop up when cursor is in a tiping field.
Whiteboard: [preview-triage] feature=defect c=tbd u=tbd p=0
Component: General → Input
OS: Windows 8 → Windows 8 Metro
Summary: Defect - Tablet keyboard (win8, 32bit) does not pop up when cursor is in a tiping field. → Defect - Tablet keyboard (win8, 32bit) does not pop up when cursor is in a text field
Blocks: metrov1backlog
No longer blocks: metrov1defect&change
Would you mind telling us what kind of tablet your having problems on?
I think this may be a general problem with Atom tablets though I don't yet have proof of that.
Reporter sees it in Iconia w510.  I see it with my Dell Latitude 10.
Turns out the Acer Iconia W700 (which I'm having issues with) is actually a Core i5, not an Atom.
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.
Attached file forms.html (deleted) — 
Here are a few handy form inputs to test with. In testting/posting str please differentiate between urlbar edit issues and content issues.
Blocks: 905817
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
(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?
No longer blocks: 905817
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Defect - Tablet keyboard (win8, 32bit) does not pop up when cursor is in a text field → Defect - Soft keyboard does not display when the user taps the nav bar edit / text input(?)
(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.
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.
Keywords: regression, regressionwindow-wanted
(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
Likely bug 902713. I just need to figure out what I broke.
Blocks: MetroPreviewRelease
Summary: Defect - Soft keyboard does not display when the user taps the nav bar edit / text input(?) → [MP] Defect - Soft keyboard does not display when the user taps the nav bar edit / text input(?)
Whiteboard: [preview-triage] feature=defect c=tbd u=tbd p=0 → [preview] feature=defect c=tbd u=tbd p=0
Assignee: nobody → jmathies
(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.
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
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.
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.
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.
Keywords: regressionwindow-wanted
So the problem is focused HTML input is not accessbile. Does it happen on all platforms like can I observe it on desktop?
(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.
when I do firefox.exe -metrodesktop then I see ordinal Firefox, is it what I should see?
(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?
local one, do I need to fix my mozconfig
(In reply to alexander :surkov from comment #26)
> local one, do I need to fix my mozconfig

yes, add |--enable-metro|.
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.
Currently not working on this, if anyone else wants to pick it up feel free.
Assignee: jmathies → nobody
(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 ]
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 ]
Depends on: 914331
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
Flags: needinfo?(surkov.alexander)
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.
Flags: needinfo?(surkov.alexander)
(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?
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.
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
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?
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.
(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.
(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?
Alexander is digging into this one again.
Assignee: nobody → surkov.alexander
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.
Matt do you know who could help us find a tighter regression window? Does metro have any go-to person for QA?
Flags: needinfo?(mbrubeck)
(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.
(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).
Juan Becerra is the main Metro QA contact:  jbecerra@mozilla.com
QA Contact: jbecerra
Flags: needinfo?(mbrubeck)
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).
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?
Flags: needinfo?(sfoster)
I'm currently working on a patch that I hope will get us a reduced test case to isolate this issue.
Flags: needinfo?(sfoster)
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.
Attached patch urlbar-edit as only UI (deleted) — — Splinter Review 
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.
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
Attached patch appbar-default-visible (deleted) — — Splinter Review 
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.
Assignee: surkov.alexander → sfoster
Attachment #806889 - Flags: review?(mbrubeck)
Comment on attachment 806889 [details] [diff] [review]
appbar-default-visible

gah.  grar.  floggle
Attachment #806889 - Flags: review?(mbrubeck) → review+
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.
Blocks: metrov1it15
No longer blocks: metrov1backlog
Status: NEW → ASSIGNED
Priority: -- → P1
Whiteboard: [preview] feature=defect c=tbd u=tbd p=0 → [preview] feature=defect c=tbd u=tbd p=3
(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
https://hg.mozilla.org/mozilla-central/rev/8765eebbaa95
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 27
Keywords: verifyme
Hi Juan, this bug was the Aurora blocker for Metro Preview.  Can you verify that it is fixed.
Flags: needinfo?(jbecerra)
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.
Flags: needinfo?(jbecerra) → needinfo?(sfoster)
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 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.
Attachment #806889 - Flags: approval-mozilla-aurora?
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
Flags: needinfo?(sfoster)
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.
Attachment #806889 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Depends on: 920175
soft keyboard appears for me on a SurfacePro with latest Nightly build from 20131024
Status: RESOLVED → VERIFIED
status-firefox27: fixed → verified
Tracy can you or anyone else that has access to a tablet PC please verify that this is fixed on the latest beta?
Flags: needinfo?(twalker)
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) :-/
Flags: needinfo?(twalker)
nevermind previous comment...  this is metro.  checking it now.
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?
Keywords: verifyme
(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.
No longer depends on: 920175
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: