Regression: Form#setParameter should fail when <input> maxlength causes a silent truncation in Firefox

Bug #591858 reported by Stephane Mikaty (eCircle AG)
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
TestPlan
New
Undecided
Unassigned

Bug Description

- Web.Session.Type=Selenium
- A web page contains the following input field:

<label>Email:</label><input size="31" name="uemail" type="text" value="" maxlength="50" /></div>

- The input field is being set using the following code (100% testplan API):

  //prepare form and do request
  Form req = getCurrentResponseState().getForm( "default" );
                req.setParameter("uemail", <some string larger than 50 characters>); <<< silent truncation in firefox

- When the uemail value we try to set is larger than maxlength, firefox truncates the value actually
set in the form *silently* to maxlength.
- When the truncation happens, req.setParameter returns without error. -> Unexpected

Expected: req.setParameter should fail when the value seen in the firefox form after calling setParameter is different from the value passed to setParameter.

This used to be in place, I made sure of that since I already had this issue with Firefox and not returning an error makes it extremely difficult to diagnose test failures. At the very least, silent truncation should cause an error by default. If for one reason or another the caller does not want or need this check, then making it switchable is the way to go. But 99% of the time, people would want to know if the browser is screwing around. 99% of the time, the caller will want the side-effect of calling setParameter to actually set the parameter to the provided value. That was one of the reason for having the TestPlan layer above Selenium in the first place, so that users have a harness of sanity when dealing with strange browser behaviours.

Revision history for this message
edA-qa (eda-qa) wrote :

I don't know if this is truly regression, since there is no way the code could have done it correctly before.

Firefox silently truncates values set in JavaScript and Paste. A typical user may also not know their values are being truncated.

Simply reading the value back out afterwards also does not work since JavaScript may have already modified the value.

What method could we use to detect this error unambiguously?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.