10221 2006-08-02 14:48:37 -0700 [S60] no key events for text input 2011-03-21 11:52:25 -0700 1 1 1 Unclassified WebKit DOM 420+ S60 Hardware S60 3rd edition CLOSED FIXED http://www.jameswatts.com/test/inputkeyevents.html GoogleBug, PlatformOnly P2 Normal --- 1 jwatts webkit-unassigned dacarson franklin.davis jwatts S60webkit oldest_to_newest 51481 0 jwatts 2006-08-02 14:48:37 -0700 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. 51482 1 9833 jwatts 2006-08-02 14:49:03 -0700 Created attachment 9833 key events test case 51556 2 bradley.morrison 2006-08-03 08:00:20 -0700 Confirmed text input key events are not being handled as at r15752. Thanks :-) 51581 3 dacarson 2006-08-03 10:17:32 -0700 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. 51602 4 jwatts 2006-08-03 11:18:57 -0700 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? 51605 5 dacarson 2006-08-03 11:35:15 -0700 (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. 51609 6 jwatts 2006-08-03 11:54:42 -0700 (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? 51618 7 dacarson 2006-08-03 12:47:26 -0700 (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) 51775 8 jwatts 2006-08-04 09:30:56 -0700 (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. 54498 9 krishnamurty.podipireddy 2006-10-05 10:34:23 -0700 TSW ID: KPOY-6UAMMP 25147 10 13071 bradley.morrison 2007-02-08 15:54:57 -0800 Created attachment 13071 Updated testcase with tabbed nav turned on. Updated testcase with tabbed nav turned on <meta name="navigation" content="tabbed"> 25148 11 bradley.morrison 2007-02-08 15:57:12 -0800 Attached testcase should pass after Zalan's patch: http://trac.webkit.org/projects/webkit/changeset/19423 Resolved. Thank you, James! 76924 12 bradley.morrison 2008-04-09 11:39:36 -0700 Bulk closing of all s60 platform bugs. Sorry for the noise! 370544 13 joel.parks 2011-03-21 11:52:25 -0700 re-purposing InTSW keyword for use by QtWebkit team 9833 2006-08-02 14:49:03 -0700 2007-02-08 15:54:57 -0800 key events test case inputkeyevents.html text/html 637 jwatts PGh0bWw+IAogIDxoZWFkPiAKICA8c3R5bGUgbWVkaWE9InNjcmVlbiwgaGFuZGhlbGQiIHR5cGU9 InRleHQvY3NzIj4KICAgICAgICBib2R5IHsKICAgICAgICAgIGZvbnQtZmFtaWx5OiBhcmlhbDsK ICAgICAgICAgIHBhZGRpbmc6IDJweDsKICAgICAgICAgIG1hcmdpbjogMDsKICAgICAgICB9CiAg PC9zdHlsZT4KICA8c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCI+CiAgICBmdW5jdGlvbiBo YW5kbGVrZXkoZXZlbnQpIHsKICAgICAgaWYgKGV2ZW50LmtleUNvZGUpIHsKICAgICAgICBkb2N1 bWVudC5nZXRFbGVtZW50QnlJZCgicmVzdWx0cyIpLmlubmVySFRNTCA9IGV2ZW50LmtleUNvZGUg KyAiIjsKICAgICAgfQogICAgfQogIDwvc2NyaXB0PgogIDwvaGVhZD4KICA8Ym9keSBvbmxvYWQ9 ImluaXQoKSI+CiAgICBlbnRlciB0ZXh0Ojxici8+CiAgICA8aW5wdXQgdHlwZT0idGV4dCIgaWQ9 InRlc3RfdHh0IiB2YWx1ZT0iIiBvbmtleXByZXNzPSJyZXR1cm4gaGFuZGxla2V5KGV2ZW50KSIg b25rZXlkb3duPSJyZXR1cm4gaGFuZGxla2V5KGV2ZW50KSIgdmFsdWU9IiIgb25rZXl1cD0icmV0 dXJuIGhhbmRsZWtleShldmVudCkiIC8+CiAgICA8ZGl2IGlkPSJyZXN1bHRzIi8+CiAgPC9ib2R5 Pgo8L2h0bWw+Cg== 13071 2007-02-08 15:54:57 -0800 2007-02-08 15:54:57 -0800 Updated testcase with tabbed nav turned on. inputkeyevents-tabbednav.html text/html 681 bradley.morrison PGh0bWw+IAogIDxoZWFkPiAKICA8c3R5bGUgbWVkaWE9InNjcmVlbiwgaGFuZGhlbGQiIHR5cGU9 InRleHQvY3NzIj4KICAgICAgICBib2R5IHsKICAgICAgICAgIGZvbnQtZmFtaWx5OiBhcmlhbDsK ICAgICAgICAgIHBhZGRpbmc6IDJweDsKICAgICAgICAgIG1hcmdpbjogMDsKICAgICAgICB9CiAg PC9zdHlsZT4KICA8c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCI+CiAgICBmdW5jdGlvbiBo YW5kbGVrZXkoZXZlbnQpIHsKICAgICAgaWYgKGV2ZW50LmtleUNvZGUpIHsKICAgICAgICBkb2N1 bWVudC5nZXRFbGVtZW50QnlJZCgicmVzdWx0cyIpLmlubmVySFRNTCA9IGV2ZW50LmtleUNvZGUg KyAiIjsKICAgICAgfQogICAgfQogIDwvc2NyaXB0PgogIDxtZXRhIG5hbWU9Im5hdmlnYXRpb24i IGNvbnRlbnQ9InRhYmJlZCI+CiAgPC9oZWFkPgogIDxib2R5IG9ubG9hZD0iaW5pdCgpIj4KICAg IGVudGVyIHRleHQ6PGJyLz4KICAgIDxpbnB1dCB0eXBlPSJ0ZXh0IiBpZD0idGVzdF90eHQiIHZh bHVlPSIiIG9ua2V5cHJlc3M9InJldHVybiBoYW5kbGVrZXkoZXZlbnQpIiBvbmtleWRvd249InJl dHVybiBoYW5kbGVrZXkoZXZlbnQpIiB2YWx1ZT0iIiBvbmtleXVwPSJyZXR1cm4gaGFuZGxla2V5 KGV2ZW50KSIgLz4KICAgIDxkaXYgaWQ9InJlc3VsdHMiLz4KICA8L2JvZHk+CjwvaHRtbD4K