Messing around with the iPhone

By on July 5, 2007 12:50 am

Well, the plan was to go through every type of input object, button, and image in Safari on my shiny new iPhone and make notes about what functions were available, how event handling works, and any other fun little goodies that came along. I started out with the good old text input box, and after an hour or two of executing functions in all sorts of different orders and being seriously freaked out a couple of times, I’m worried about the pretty severe limitations of one of the most basic widgets of the web browser:

  • When the input does not have “virtual keyboard” focus, calling its focus function calls its onfocus function, but does not give the input “virtual keyboard” focus
  • When the input does not have “virtual keyboard” focus, but you’ve called its focus function, calling its blur function will call its onblur function. When the input does have “virtual keyboard” focus, calling its blur function does absolutely nothing (which breaks some scripts that prevent input by blurring on focus).
  • When the input does not have “virtual keyboard” focus, calling its select function does nothing, until you scroll or zoom in on the page, at which point it calls both its onfocus and onblur functions. When the input does have “virtual keyboard” focus, calling its select function does absolutely nothing.
  • Calling its click function calls its onclick function as expected.
  • Selecting an input box fires: onfocus, onmouseover, onmousedown, onmouseup, onclick, and sometimes onmousemove
  • Selecting the next item on the page fires: onblur, and (conditionally) onchange, but still no key events.
  • Clicking the “Done” button in the “virtual keyboard” fires: onblur, and (conditionally) onchange, but still no key events.
  • The only key that registers any key events is the return key.

Comments

  • Once the virtual keyboard “Go” button is pressed, have you found a way to get the virtual keyboard to type in the same text box it was just typing in before “Go” was pressed? Your results above do not sound encouraging. I have also found that doing an input.focus() or input.select() does not seem to get the virtual keyboard to type in the box even though it is still open.

  • There is no way to force the virtual keyboard to pop up that I have been able to find. One of the fun things I did was to call every single function attached to the input node, and none of them had any impact on the virtual keyboard.

  • Ahh, I see what you were asking. A quick summary for anyone that doesn’t want to go through that Google thread:

    If you have an input box outside of a form, there is a button on the bottom right that says “return”. If you have an input box inside of a form, the same button says “Go”.

    If the input box is outside of a form, the button sends a key event (a newline character). If the input box is inside of a form, it also sends an onsubmit event. If you use this event to try to clear out the input box using input.value = “”, the virtual keyboard stays on the screen, but typing does absolutely nothing. The link that James posted has a hack to clear the input box while allowing your typing to continue.

    iPhone’s Safari is surprisingly buggy.

  • Pingback: Raju Bitter » OpenLaszlo und das iPhone()

  • Try to call input.focus() as the result of a XHR asynchronous request… the control immediately loses the focus and a blur event is fired before the virtual keyboard appears.

    I agree, form controls in iPhone have many bugs, I think they all are related with the virtual keyboard, the source code is new not present in desktop Safari and so not enough tested.