Closed Bug 174056 Opened 23 years ago Closed 20 years ago

When paying bills online, form truncates decimal places.

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED EXPIRED
Milestone:
Future

People

(Reporter: benyjr, Assigned: alexsavulov)

References

(
URL
)

Details

Attachments

(2 files)

payment input screen
30.96 KB, text/html
Details
verifies the details of the bill payment
16.65 KB, text/html
Details
User-Agent: Mozilla/4.79 [en] (X11; U; Linux 2.4.18-0.13 i686) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 While trying to pay bills while logged on at the above URL, the final confirmation screen shows an incorrect amount to be transferred. Regardless of the amount I enter, the decimal values are always changed to 00. Reproducible: Always Steps to Reproduce: This requires a web-enabled banking account with TD Canada Trust in order to reproduce it. 1) Log into the above URL. 2) From the menu on the left side, select PAY BILLS (accounts must be set up before attempting to reproduce the bug). 3) Select the Payee, click "Pay Selected Payee(s)" 4) Enter a monitary value with a non-zero decimal value (for example 75.44) 5) Click on "NEXT" Actual Results: The following confirmation screen shows the value I requested has a 00 decimal value (in this example $75.00 instead of $75.44 as I had requested). Expected Results: The confirmation screen should have stated that I intended to transfer $75.44 to the desired account. I am using RedHat 7.2 on an i386 system. Mozilla 1.1 installed from RPM packages downloaded directly from mozilla.org
This is just one of many form handling bugs I have been encountering in Mozilla.
are you sure this is not the intended behavior? does it truncate with other browsers (NS4/opera)? you might also try a newer build (1.2b should be released soon)
No, that is not the intended form behavior. Form works properly with NS 4.79 (ie. $75.44 remains as $75.44) Form works properly with Konqueror 2.2.2 If 1.2b is available in RPM format, I'll try it.
since we cannot access such pages we would need the source of that form that cause problems. rounding problems? we don't have code that rounds values in an input. see if there is some javascript that does. please save that HTML that contains the form and attach it in this report. thx!
Attaching a copy of the HTML text will take some time. The page that is generated is plastered with personal information about my account. I don't want to post that in a public forum (sorry, I need that cash to stay in my account, even if it is Canadian $$$ 8^) ). On the other hand, if I go through and overwrite everything that may be confidential the page may not be of any use for bugfixing. I have verified that this bug does not exist in Phoenix 0.3. Would it be safe to assume then, that this bug is therefore already fixed in Mozilla? Beny
ah, maybe you can only extract only the form markup (between the <form and </form> tags) and the javascript needed, but if there is a lot of personal information and is too big of a hassle to remove it, then is ok, don't post that. maybe you could take a look at the javascript there if it does some kind of special magic and prepare a reduce testcase. About your question: Phoenix is using Mozilla trunk code so it should perform form submission the same way. if you read the Phoenix FAQ, the developers state that Phoenix releases are always using code pulled one day before the release.
Priority: -- → P3
Target Milestone: --- → Future
Benyjr, are you still experiencing this problem? Can you provide a copy of the page source so that someone can work this issue?
Attached file payment input screen —
This screen is the bill paying input screen. Personal information has been replaced with XXXX's, hopefully I haven't left anything that can be used to get into my account.
This screen takes the amount you want to pay with and re-displays it for verification. It is on this screen that you notice the decimal value is now 00 instead of the actual value inputted. The dollar value is untouched.
The bug still exists in Mozilla 1.3. It does not exist in Mozilla Firebird 0.6
WORKSFORME.. I used mozdev-project livehttpheaders to check what mozilla posted: redrawIndicator=false&processBillIndicator0=true&Amt0=1.77&Month0=06&Day0=04&Year0=2003&accountSelection0=C-341106466&Frequency0=One+Time&C0=1271562339&accessCard0=842079854&count=1&selected=C842079854P1271562339%2C ^^^^ Then I looked attachment 2 [details] [diff] [review], and I saw your amount in the screenshot: Amount: $1.34 Take from my account on: Jun 04, 2003 From: FULL SERVE ACCOUNT - XXXXXXX Reporter, can you please verify this with a new mozilla build (1.4rc2) and a newly created mozilla profile.
If someone will provide me with i386 RPM's for RedHat 7.X of Mozilla 1.4 RC2, then yes, I will verify if the bugs still exist. Thanks.
This 1.4 rpm seems to be compiled for RH8. I'm running 7.x, there are too many dependency issues here to install the RPM you have provided the link to. Cannot yet verify the resolution of this bug. Beny
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 Installed Mozilla 1.4 from RPM files downloaded from Mozilla.org The bug still exists, but now in a different form. On the payment screen, entering a value with decimal places (eg. 7.25 or even 1.00) yields the following error: Please call TD Canada Trust at 1-866-222-3456 to report the problem. [java.lang.NullPointerException] (Server ID: 46z : 1057634069071 ) Entering a positive, whole number value I have the following relevant packages installed: mozilla-chat-1.4-0.7.3 mozilla-psm-1.4-0.7.3 mozilla-nss-1.4-0.7.3 mozilla-mail-1.4-0.7.3 mozilla-1.4-0.7.3 mozilla-js-debugger-1.4-0.7.3 mozilla-bonobo-0.3.0-0.dag.rh80 mozilla-nspr-1.4-0.7.3 mozilla-dom-inspector-1.4-0.7.3 j2re-1.4.2-beta I have ruled out the java plugin as the root cause since Mozilla Firebird is using the exact same plugin, with no problems.
Reporter, please attach the page generating the error. File, Save Page As, choose "Web Page, complete" compress the file, and folder created and attach here. Thanks
benyjr: is this still a problem with a recent build (1.7 or 1.8b)? (and if you do save the page, please don't you save-as-web-page-complete -- it mangles the HTML/JS).
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → EXPIRED
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: