Created attachment 85238 [details] t.html Bug transferred from RC ID:ou1cimx1#751894 Comments copied from RC: ************************************************************************************ Preconditions Deviceshould be flash with SEAP Variant and the four way HW key must be used forselecting the card number or Expiry or CSC code. Steps to reproduce 1) Switch on the device with valid sim card 2) Select Ovi store from the first home screen orGo to Menu > Ovi store 3) Select Apps or Games or Audio Video orPersonalization category 4) Select Best sellers and then click on any appsor games or video you want to purchase 5) The Item screen is open and now select buy 6) The payment screen is shown and the paymentoptions is Credit card bill 7) Select the Card type and put the Card detailslike Name, Card number, Expiry, CSC code with four way HW key 8) When Select the Card number with four way HW key scrolling up and down shows the junk characters Actual results Junk numbers or Characters are shown in Credit card billing information through scrolling four way HW key Expected result TheFour HW key scrolling must not show the junk characters as the user will trywith that as a first option rather than using touch Results from reference testing NA Additional information (e.g. SW + HW info) SW : 021.002 HW : B3, 3000 --- Chris Richardson (chrisric), 2011-03-07 16:45:53 To CP for analysis. Looks like the navi key support is somehow changing the text format in to scientific e-notation? --- Mikko Rossi (e0078616), 2011-03-08 14:26:02 Assigning to Lauri Taipale for analysis. --- Lauri Taipale (e0103146), 2011-03-09 13:32:15 This looks like a WebKit issue related to empty HTML5 number input html element (<input type="number" ...>) behavior. If an empty number input element is focused and then either up or down arrow key is pressed (on the HW keyboard) then the focused number input element is filled with an seemingly arbitrary value. If a valid number is entered before pressing up or down, the value of the number is increased or decreased, respectively. The issue can be reproduced on Taika 021.003 either by using the Ovi Store client as described in the related Failure or with the wrtlite test application available from cp_tools.sis package by loading the attached t.html test page (see attached number_input_wrtlite.png). is also visible on the latest Windows version of the Chrome browser, although on Chrome the number that is displayed in the empty input element is different (see attached number_input_chrome.png). can NOT be reproduced on the Symbian Browser application, as pressing the HW cursor keys activates the virtual "mouse cursor" overriding the number input element's behavior.
Created attachment 85239 [details] number input chrome
Created attachment 85240 [details] number_input_wrtlite
Created attachment 85241 [details] junk numbers in store payment
increasing priority and severity as on Top List in RC.
needed for both QtWebKit2.1 and QtWebKit2.1.x branches, hence should 'block' 39121.
Given the look of the bug, this is unlikely a WebKit bug. Credit-card numbers should be transfered and used as text literal, not as number. The specification of input[type=number]: http://dev.w3.org/html5/spec/Overview.html#number-state mentions "The step scale factor is 1. The default step is 1 (allowing only integers, unless the min attribute has a non-integer value)." So it looks like the step is wrong currently. I assign that to myself for now, I'll try to have a look soon, otherwise I'll reset the assignee. I will not implement the expected behavior defined though: "TheFour HW key scrolling must not show the junk characters as the user will trywith that as a first option rather than using touch". Scrolling with those keys is not really a behavior to define in WebKit, you can defined that in the engine or the widget.
I don't think this is blocking 2.1.0 and 2.1.x. There is probably something wrong with the step but for credit card numbers the code for the input element should use text and not integer. You can use Javascript to get the key events.
This is working with trunk. That might have been fixed by https://bugs.webkit.org/show_bug.cgi?id=42076 or a patch before that. My advice is to fix this in your widget by intercepting key events, and call preventDefault(). Even if you got trunk, the behavior you would get is not useful for a credit card number input.
Fabrizio has a patch which will resolve this behavior on QtWebkit-2.1 and QtWebkit-2.1.x
Created attachment 87240 [details] patch for qtwebkit 2.1.0 and 2.1.x Proposed fix for 2.1.0 and 2.1.x. Trunk reviewers, please ignore this.
This is blocking: Bug 39121: [Qt] Tracker bug for release critical bugs for QtWebKit 2.1 release But I was not able to modify (permissions?) the "Blocks:" field in this report.
Trunk reviewers, please ignore this. Fabrizio's fix for qtwebkit 2.1.0 and 2.1.x. passed my Desk check review see "patch for qtwebkit 2.1.0 and 2.1.x" Needed for S60 9.2
this is top error for both QtWebkit 2.1.0 and QtWebkit 2.1.x
(In reply to comment #13) > this is top error for both QtWebkit 2.1.0 and QtWebkit 2.1.x This bug needs a rubber stamp and a change log to be cherry picked.
Comment on attachment 87240 [details] patch for qtwebkit 2.1.0 and 2.1.x View in context: https://bugs.webkit.org/attachment.cgi?id=87240&action=review Is this a backport? From which patch? > WebCore/html/HTMLInputElement.cpp:2843 > + if(!isfinite(current)) { coding style
Created attachment 87762 [details] fix style, add changelog Yeah, this is taking some code from r72884 to address the problem on 2.1.x.
Comment on attachment 87762 [details] fix style, add changelog View in context: https://bugs.webkit.org/attachment.cgi?id=87762&action=review Nitpicking... > WebCore/ChangeLog:4 > + Where is the title? > WebCore/html/HTMLInputElement.cpp:2842 > + Why? > WebCore/html/HTMLInputElement.cpp:2848 > + Why?
Created attachment 87768 [details] remove whitespace, add bug title in changelog My bad, added rework.
Cherry-picked into qtwebkit-2.1 with commit 5213e35e04f4e32ec8d9739b1481983dde536cea.