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.
Created attachment 9833 [details] key events test case
Confirmed text input key events are not being handled as at r15752. Thanks :-)
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.
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?
(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.
(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?
(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)
(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.
TSW ID: KPOY-6UAMMP
Created attachment 13071 [details] Updated testcase with tabbed nav turned on. Updated testcase with tabbed nav turned on <meta name="navigation" content="tabbed">
Attached testcase should pass after Zalan's patch: http://trac.webkit.org/projects/webkit/changeset/19423 Resolved. Thank you, James!
Bulk closing of all s60 platform bugs. Sorry for the noise!
re-purposing InTSW keyword for use by QtWebkit team