Hidden field with a value 0 does not submit sometimes

UNCONFIRMED
Unassigned

Status

()

Core
HTML: Form Submission
UNCONFIRMED
8 years ago
8 years ago

People

(Reporter: BEN, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Build Identifier: (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6

This happens to both Mac and X86. I have set a hidden field, I set the the value to 1 or 0 when a page populate. I can always get the value 1 by request.getParameter("recordexist") on server side in java, but if the value is zero, sometimes, not every time and not very often, I logged a null pointer error in the log. The field is alwways defined as
  <input type=hidden name=recordexist value="0">

Sometimes the following JSP throws out a null pointer error:
   int record_exists = request.getParameter("recordexist").charAt(0) - '0';


Reproducible: Couldn't Reproduce




My website servres tens thousands of pages a day. This error happens 1 - 2 times a day. Not often at all.
(Reporter)

Updated

8 years ago
Summary: Hidden field with one a value 0 does not submit sometimes → Hidden field with a value 0 does not submit sometimes

Updated

8 years ago
Component: General → HTML: Form Submission
Product: Firefox → Core
QA Contact: general → form-submission
(1) Check with simplest case first.
    action="file:///index.html" method=get, with value=1 and value=0
    What string is generated by Fx as qury string?
    What is difference between value=1 and value=0?
(2) Do you use POST method instead of GET method?
(3) Do you use enctype="multipart/form-data"
If POST and/or multipart/form-data, simple check is hard. Get HTTP log first.
> a. By NSPR logging
> https://developer.mozilla.org/en/HTTP_Logging
> set NSPR_LOG_MODULES=timestamp,nsHttp:5,nsHostResolver:5
> b. By add-on of LiveHTTPHeaders

> Sometimes the following JSP throws out a null pointer error:
>   int record_exists = request.getParameter("recordexist").charAt(0) - '0';

Form data was really sent from Fx when the error occurred?
Is your code torelant with uppercase name string? (name attribute of HTML was case insensitive, wasn't it?).
Is your code torelant with request.getParameter("recordexist") == undefined condition?
(Reporter)

Comment 2

8 years ago
More information:

It never happens to my counputer, the chances of happening is less than 0.1%,  I was not able to re-produce it.

The form tag does not have a ENCTYPE and ACTION attribute, so I suppose they are "application/x-www-form-urlencoded" and the page itself

All related reference of the field is with lower cases, I think that is not the problem.

In the last five days (April 1 to 5), one page was posted 7748 times based on the log, this error has happened 5 times, if there is a coding problem, it should have been more often.

I will log more information on the server side, any suggestion is appreciated. (I can use simple JSP code to log any information the request object can provide).


Thanks

Ben
Why no answer by you, who is the Web site/Web page developer, to my next question?
> Form data was really sent from Fx when the error occurred?
You can't answer this my question? If so, what is your evidence that problem you are looking is caused by Fx's flaw in code? (Here is B.M.O, is never support forum).
(Reporter)

Comment 4

8 years ago
The evidence is: I have logged all the null-pointer errors in my code, the browser is always FireFox 3.6. I knew the error is not normal, so I added verification code and checked when the error happens, it points to FireFox. Here is one entry:

2010-04-05 21:27:30,442 ERROR - myforms.jsp: record exist error, user_id = 288993, submitted=NULL, Page-no=8001001, Browser=Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6


Ben
(In reply to comment #2)
> so I suppose they are "application/x-www-form-urlencoded" and the page itself

method=POST?

(In reply to comment #4)
> The evidence is: I have logged all the null-pointer errors in my code, the
> browser is always FireFox 3.6.
> Here is one entry:
> 2010-04-05 21:27:30,442 ERROR - myforms.jsp: record exist error, user_id =
> 288993, submitted=NULL, Page-no=8001001, Browser=Mozilla/5.0 (Windows; U;
> Windows NT 6.1; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6

What does "submitted=NULL" mean?

If POST, and if submitted=NULL means posted data is null data(string of length=0), possibly Bug 547239(status1.9.2: .2-fixed) or Bug 548009(probably fixed by Bug 547239).  
> Bug 547239 Post body not preserved after HTTP 307 redirection, in Firefox 3.6
> Bug 548009 Reply a forum post or send a form fails and return to answer page
If your site uses redirect, bug 547239 may happen on Fx.
If user uses proxy, bug 548009 may happen on Fx.
bug 541815 and bug 547246 may be same problem.
(Reporter)

Comment 6

8 years ago
First let me clarify, I am not seeking support here, I just want to help. I have worked around this bug long time ago by checking if the string is null. I have been writing all kinds of programs using almost all languages from assembly to Perl for 20+years. I know what I am doing

I am not using Re-direction.

But I have never worked with proxy, so I don't know if it related to that. The problem is hundreds of my clients are using my site everyday and they access the same page many times (but the bug only happens very rarely) and I am not in the position to ask them to do things for me. I can only record whatever you need in the back-end, using JSP.

I confirm it is a POST method. I am running Tomcat 5.0.28.
(Reporter)

Comment 7

8 years ago
I have read  bug 547246, maybe it is the same problem. I will add more check value and see if it is the same. I will get back to you as soon as it is logged.

Ben
(In reply to comment #7)
> I have worked around this bug long time ago by checking if the string is null.

Roger.

> I have read bug 547246, maybe it is the same problem.

If bug 547246 looks nearest phenomenon to yours, see bug 547396, please.
(copy of Bug 547246 Comment #8)
> see bug 547396 (which is fixed by bug 547239 )

Following is copy of a part of bug 547239(report of regression. patch was landed by this bug). 
> In Firefox 3.6, post body not preserved after HTTP 307 redirection.
> Firefox 3.5.2 to 3.5.8(I verified that) do not have this issue and handle correctly.
It probably explains "browser is always FireFox 3.6" in your case.

> I am not using Re-direction.
> (but the bug only happens very rarely)

Following is copy of Bug 548009 Comment #7 by Boris Zbarsky(who wrote patch for Bug 547239).
> Yes, I realize that. There's a known bug in the 3.6 auto detect code;
> see comments in bug 547239.  Should be fixed in 3.6.2.
Bug 548009 seems to occur if user uses option of "automatically detect proxy settings".
I think Fx 3.6.0/1 users who use "automatically detect proxy settings" is not so many. I think it explains "happens very rarely" of your case. As Fx 3.6.3 is already released, watch for a while, please.
FYI.
Bug 542642 is another bug which is problem of Fx 3.6(probably .0/.1) when "automatically detect proxy settings" is used, which has [fixed by 547239] in Whiteboard: field.

(off-topic)
Developers, QA peoples(Quality Assuarance == report/problem analysis to help developers), Triage team(decision on priority etc.), and helpers for QA peoples/Triage team like me, have to process(==fight with) many many and many reports like bug 538892 from general user. If majority of bug reporters at B.M.O(bugzilla.mozilla.org) were professional like you(who can very quickly provide data by logging in his program code, who reads bugs if pointed, ...), QA work at B.M.O would be very easier than current...
You need to log in before you can comment on or make changes to this bug.