939248 - Get the 'autofocus' attribute working on <input type=number> without the style hack

Status: NEW

(Core :: Layout, defect)

Description

[Jonathan Watt [:jwatt]]

The 'autofocus' attribute doesn't currently work on <input type=number> without a style hack...or not completely. Focus is correctly redirected from the number control to its anonymous text control child, and if the user types their input will appear as expected. The issue is that the cursor doesn't start flashing, so the user has no way to know that the number control has focus and that's where their typing will go. The cursor refuses to appear even if the control is clicked. It only appears if focus is switched away from the control and then back again (e.g. if say the window loses and then regains it).

So far I've managed to figure out the following:

When the nsAutoFocusEvent event is run the correct nsEditor (thde one for the anonymous text control) does get focus, and calls PresShell::SetCaretEnabled with what appears to be the needed arguments:

  PresShell::SetCaretEnabled
  _ZThn336_N9PresShell15SetCaretEnabledEb
  nsTextInputSelectionImpl::SetCaretEnabled
  _ZThn16_N24nsTextInputSelectionImpl15SetCaretEnabledEb(
  nsEditor::InitializeSelection
  nsEditor::OnFocus
  nsEditorEventListener::Focus
  nsEditorEventListener::HandleEvent
  nsEventListenerManager::HandleEventSubType
  nsEventListenerManager::HandleEventInternal
  nsEventListenerManager::HandleEvent
  nsEventTargetChainItem::HandleEvent
  nsEventTargetChainItem::HandleEventTargetChain
  nsEventDispatcher::Dispatch
  FocusBlurEvent::Run
  nsContentUtils::AddScriptRunner
  nsFocusManager::SendFocusOrBlurEvent
  nsFocusManager::Focus
  nsFocusManager::SetFocusInner
  nsFocusManager::SetFocus
  nsGenericHTMLElement::Focus
  mozilla::dom::HTMLInputElement::Focus
  mozilla::dom::HTMLInputElement::Focus
  nsAutoFocusEvent::Run

Under that call nsCaret::StartBlinking() is called, and the timer starts and fires regularly. nsCaret::DrawCaret() is called, with the expected aInvalidate==true, but when we enter the big |else| in that method we keep returning at the mLastContent null check. As a result we never make the DrawAtPositionWithHint() call at the end of the method with mDrawn set to true.

When we should be setting mLastContent seems to be when we call DrawAtPositionWithHint() when mDrawn is set to false. The reason for that is because |userinterface->mUserModify == NS_STYLE_USER_MODIFY_READ_ONLY| evaluates to true and we return early.

Checking the above for a simple <input type=text autofocus> shows that in that case |userinterface->mUserModify == NS_STYLE_USER_MODIFY_READ_ONLY| evaluates to false.

So the problem seems to be that the computed value for -moz-user-modify for the <div> child of the anonymous text control is 'read-only'. And then somehow if you tab away from the window and back again it's set to the expected value of 'read-write'. I've been trying to debug exactly why this is for quite some time now with little headway, so for now I'm going to stick with the hack.