Bug 56054

Summary: Input[type=number] should step by 1. by default
Product: WebKit Reporter: grace.cheng
Component: CSSAssignee: Nobody <webkit-unassigned>
Severity: Blocker CC: benjamin, cmarcelo, fabrizio.machado, grace.cheng, joel.parks, laszlo.gombos, luiz, menard, roger.scott
Priority: P1 Keywords: Qt, QtTriaged
Version: 528+ (Nightly build)   
Hardware: S60 Hardware   
OS: All   
Description Flags
number input chrome
junk numbers in store payment
patch for qtwebkit 2.1.0 and 2.1.x
fix style, add changelog
remove whitespace, add bug title in changelog none

Description grace.cheng 2011-03-09 14:43:30 PST
Created attachment 85238 [details]

Bug transferred from RC ID:ou1cimx1#751894 
Comments copied from RC:
 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

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.
Comment 1 grace.cheng 2011-03-09 14:44:36 PST
Created attachment 85239 [details]
number input chrome
Comment 2 grace.cheng 2011-03-09 14:44:58 PST
Created attachment 85240 [details]
Comment 3 grace.cheng 2011-03-09 14:45:12 PST
Created attachment 85241 [details]
junk numbers in store payment
Comment 4 Joel Parks 2011-03-15 11:39:06 PDT
increasing priority and severity as on Top List in RC.
Comment 5 Joel Parks 2011-03-16 05:18:53 PDT
needed for both QtWebKit2.1 and QtWebKit2.1.x branches, hence should 'block' 39121.
Comment 6 Benjamin Poulain 2011-03-16 05:47:30 PDT
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.
Comment 7 Alexis Menard (darktears) 2011-03-16 06:19:39 PDT
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.
Comment 8 Benjamin Poulain 2011-03-16 10:28:50 PDT
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.
Comment 9 Joel Parks 2011-03-28 11:54:22 PDT
Fabrizio has a patch which will resolve this behavior on QtWebkit-2.1 and QtWebkit-2.1.x
Comment 10 Fabrizio 2011-03-28 16:57:19 PDT
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.
Comment 11 Fabrizio 2011-03-28 17:01:38 PDT
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.
Comment 12 Roger Scott 2011-03-29 11:21:57 PDT
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
Comment 13 Joel Parks 2011-03-29 11:26:49 PDT
this is top error for both QtWebkit 2.1.0 and QtWebkit 2.1.x
Comment 14 Luiz Agostini 2011-03-30 07:18:47 PDT
(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 15 Benjamin Poulain 2011-03-31 08:59:49 PDT
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
Comment 16 Fabrizio 2011-03-31 10:47:51 PDT
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 17 Alexis Menard (darktears) 2011-03-31 10:55:17 PDT
Comment on attachment 87762 [details]
fix style, add changelog

View in context: https://bugs.webkit.org/attachment.cgi?id=87762&action=review


> WebCore/ChangeLog:4
> +

Where is the title?

> WebCore/html/HTMLInputElement.cpp:2842
> +


> WebCore/html/HTMLInputElement.cpp:2848
> +

Comment 18 Fabrizio 2011-03-31 11:02:53 PDT
Created attachment 87768 [details]
remove whitespace, add bug title in changelog

My bad, added rework.
Comment 19 Luiz Agostini 2011-03-31 11:29:55 PDT
Cherry-picked into qtwebkit-2.1 with commit 5213e35e04f4e32ec8d9739b1481983dde536cea.