Bug 56054 – Input[type=number] should step by 1. by default

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: CSS

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

[Joel Parks]

increasing priority and severity as on Top List in RC.

[Joel Parks]

needed for both QtWebKit2.1 and QtWebKit2.1.x branches, hence should 'block' 39121.

[Benjamin Poulain]

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.

[Alexis Menard (darktears)]

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.

[Benjamin Poulain]

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.

[Joel Parks]

Fabrizio has a patch which will resolve this behavior on QtWebkit-2.1 and QtWebkit-2.1.x

[Fabrizio]

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.

[Fabrizio]

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.

[Roger Scott]

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

[Joel Parks]

this is top error for both QtWebkit 2.1.0 and QtWebkit 2.1.x

[Luiz Agostini]

(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.

[Benjamin Poulain]

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

[Fabrizio]

Created attachment 87762 [details]
fix style, add changelog

Yeah, this is taking some code from r72884 to address the problem on 2.1.x.

[Alexis Menard (darktears)]

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?

[Fabrizio]

Created attachment 87768 [details]
remove whitespace, add bug title in changelog

My bad, added rework.

[Luiz Agostini]

Cherry-picked into qtwebkit-2.1 with commit 5213e35e04f4e32ec8d9739b1481983dde536cea.