Bug 10221 – [S60] no key events for text input

• Component: DOM
• Status: CLOSED FIXED

[James Watts]

Seems like key events are not being fired for text input.  See attached URL -- on FF, typing in the text input will write the key code to the page.

Tested on N80 V3.0614.0.3.

[James Watts]

Created attachment 9833 [details]
key events test case

[Bradley Morrison]

Confirmed text input key events are not being handled as at r15752.

Thanks :-)

[David Carson]

The issue here is that there is some complex work being handled by the input box on the platform that is changing the letters as you type, similar to a FEP. 
Mobile phone users use an input mode known at T9. It maps the characters for each number on 9-pad to a word in the dictionary. Eg to enter the word 'monday', the user presses 6-6-6-3-2-9. Though, as you type it it does not start to become the word monday till the letter 2. What appears to the user is the following:
o
on
non
none
monda
monday
What would it mean to issue key events into the DOM with such a system? What would web page authors expect? Would they expect the the letters m-o-n-d-a-y, or would they expect what they see on the screen, o-n-n-e-a-y (ie the character that was shown for that key press). How would inform the user that the character for a previous key event has changed?
Keep in mind that this is only the English language, when mobile devices are used in other countries such as China, it is even more complex.

[James Watts]

I would expect that key press events would match the keys that were pressed by the user (0-9, #, *, or more simply the keys if you happen to have a qwerty device).  Ideally, the input mode would also be available via DOM (even more ideally, it would be settable for the current input), but I wouldn't expect that without DOM extensions.  In the absence of this, the JS can look at both the key event and the contents of the text box and decide what it thinks is the appropriate behavior.  

Understood that non-latin entry modes would bring their own complications, in this case the script would need to find another solution or disable whatever behavior it wanted to use -- I don't think the answer is to consider the text box "out of bounds" for scripts.

Of course, this is all predicated on scripts being written for mobile browsers.  Is the concern really that the browser is trying to protect itself from desktop pages?

[David Carson]

(In reply to comment #4)
> I would expect that key press events would match the keys that were pressed by
> the user (0-9, #, *, or more simply the keys if you happen to have a qwerty
> device).  

ok. IMHO, I think that this would be ok, as in my experience I have only seen
scripts that are triggered from the key events but do not manage the input text
using information from the key event. They query the input field for the text.
There is a technical issue in the Symbian platform as the input box hijacks the
keyboard and the application does not see any events while an input box has
focus. A workaround for this would be required.

> Ideally, the input mode would also be available via DOM (even more
> ideally, it would be settable for the current input), but I wouldn't expect
> that without DOM extensions.  In the absence of this, the JS can look at both
> the key event and the contents of the text box and decide what it thinks is the
> appropriate behavior.  

Yes. As long as existing web content is not broken by this behaviour.

> Understood that non-latin entry modes would bring their own complications, in
> this case the script would need to find another solution or disable whatever
> behavior it wanted to use -- I don't think the answer is to consider the text
> box "out of bounds" for scripts.

Definitly agree, the text box should not be out of bounds. Actually in the current
ToT development, the input boxes are no longer platform controls, but rather
are html controls. They are essentially editable HTML DIVs. It will be 
interesting to see how this is handled in the current Symbian ToT port going on.

> Of course, this is all predicated on scripts being written for mobile browsers.
>  Is the concern really that the browser is trying to protect itself from
> desktop pages?

The concern is that the mobile browser needs to provide a true web experience
and steps are taken in a way to ensure that the majority on existing web content
works and is usable on the mobile browser.

[James Watts]

(In reply to comment #5)
> The concern is that the mobile browser needs to provide a true web experience
> and steps are taken in a way to ensure that the majority on existing web
> content
> works and is usable on the mobile browser.

Fair enough.  Has forking behavior for mobile pages been considered?

[David Carson]

(In reply to comment #6)
> (In reply to comment #5)
> > The concern is that the mobile browser needs to provide a true web experience
> > and steps are taken in a way to ensure that the majority on existing web
> > content
> > works and is usable on the mobile browser.
> 
> Fair enough.  Has forking behavior for mobile pages been considered?
> 

Yes, there are thoughts around this. Currently, the thought is that a page that has the XHTML-MP DTD defined, then it is a mobile page. But there are also side effects of this, the content must be conformant to XHTML-MP. (strict XML)

[James Watts]

(In reply to comment #7)
> Yes, there are thoughts around this. Currently, the thought is that a page that
> has the XHTML-MP DTD defined, then it is a mobile page. But there are also side
> effects of this, the content must be conformant to XHTML-MP. (strict XML)
> 
And XHTML-MP doesn't support the script tag.  I've heard adding it has been discussed -- it might make sense given that there is a standard for mobile ecmascript, but no corresponding markup standard to deliver it.

What about setting a property in the DOM directly (document.declareMobileDoc() or similar) or adding another meta tag?  Opera looks at the stylesheet for the media="handheld" attribute to make some decisions like this, but this doesn't seem like a good solution for making scripting decisions.

[Krishna]

TSW ID: KPOY-6UAMMP

[Bradley Morrison]

Created attachment 13071 [details]
Updated testcase with tabbed nav turned on.

Updated testcase with tabbed nav turned on

 <meta name="navigation" content="tabbed">

[Bradley Morrison]

Attached testcase should pass after Zalan's patch:

http://trac.webkit.org/projects/webkit/changeset/19423

Resolved.

Thank you, James!

[Bradley Morrison]

Bulk closing of all s60 platform bugs. 

Sorry for the noise!

[Joel Parks]

re-purposing InTSW keyword for use by QtWebkit team