Closed Bug 576267 Opened 14 years ago Closed 14 years ago

User interface overrides underlying HTML

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: osavill, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6
Build Identifier: 

In exploring ways to give the user a promo code apply button I came across a potentially serious bug. I was using the Apply button to reload the current page and found that the HTML source and FireFox's UI were at odds with each other. So I've distilled it down to this:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <title>Very short snippet from a much larger orders page</title>
    <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-15">
  </head>
  <body>
    <form  enctype="application/x-www-form-urlencoded" method="post" name="checkoutForm" id="checkoutForm" action="tryForms.php">
      <input type="text" value="<?php echo($_POST['var1']); ?>" name="var1">
      <input type="submit" value="Apply">
    </form>
  </body>
</html>

So run this code up and you'll get the form. Now enter a value, say "33" and press the "Apply" button. Now enter "55" into the entry box. Now press the "Reload current page" Navigation Toolbar button.

Result: the page still shows "55" in the entry box, but the page HTML is "<input type="text" value="33" name="var1">"

This is very bad, no other browser I have tried does this and it basically screws and further form processing since, if there was one, pressing a "Next" button passes "55" to the checkout script as well. Moreover any DOM / Javascript processing in the original order page, like the above, correctly uses the value "33" so anything like totals are now messed up, as are any postage calculations and the like. Anyone discovering this bug may well be able to order any number of products for the price of just one!

I beleive this <i>may</i> be related to Bug 382787.

Reproducible: Always
> Result: the page still shows "55" in the entry box, but the page HTML is
> "<input type="text" value="33" name="var1">"

Yes, this is expected behavior when doing a reload: the current user-entered values (which may not match the current default values) are preserved.

In fact, the situation is exactly what it was before the reload: the default value is 33 but the currently entered value is 55.

> Moreover any DOM / Javascript processing in the original order page, like the
> above, correctly uses the value "33"

Uh... why is it using the default value and not the currently entered value?  Sounds like it would also get confused if the user just typed something in the control, without the reload!

This looks invalid to me, but maybe I'm missing something?
Please don't close this issue quite yet. I'll need to add some JavaScript to this sample page and a submit button and re-run the tests. I think what I am saying is that although the value displayed is 55, and I see your reasoning for this, if you you access the document.checkoutForm.var1.value it's still 33. I'll double check this and re-post here. I can't say for sure since I found this at work and I am now at home.
> if you you access the document.checkoutForm.var1.value it's still 33

If that happens, that would be a bug, yes.  Let me know what you find.
Ok, so here is the revised code:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <title></title>
    <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-15">
    <script language="javascript" type="text/javascript">
    function alertVar()
    {
       // Alert appears non functional at the moment in Firefox, a half shaded but blank box appears instead. Had noticed on other sites as well and assumed it was a site defect, but I guess not. I am running Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6
       alert("<p>DOM value is: " + document.forms.checkoutForm.var1.value + "</p>");
    }
    </script>
  </head>
  <body onload="//javascript:alertVar();">
    <?php
      if (isset($_POST['quants']))
      {
         $quantities = $_POST['quants'];
      }
      $quantity1 = $quantities[0];
      $quantity2 = $quantities[1];
    ?>
    <form  enctype="application/x-www-form-urlencoded" method="post" name="checkoutForm" id="checkoutForm" action="tryForms.php">
      <input type="text" value="<?php echo($quantity1); ?>" name="quants[]" id="quant1");
      <input type="text" value="<?php echo($quantity2); ?>" name="quants[]" id="quant2");
      <input type="submit" value="Apply">
    </form>
  </body>
  <script language="javascript" type="text/javascript">
    document.write("<p>DOM value is: " + document.forms.checkoutForm.quant1.value + "</p>");
    document.write("POSTed quantity is: " + <?php echo($quantity1); ?>);
  </script>
</html>

Steps:
Enter 77 into the first entry box
Click "Apply"
Enter 55 into the first entry box
Click "Reload current page" button in URL bar

Result: both 55 and 77 are written to the output.

It appears that the UI is updated and the forms .value fields are as well, but when the page is refreshed the current UI value us not sent over the wire,  indeed the popup dialog kind of implies this "Firefox must send information that will repeat any action". 

So this may not be a "bug" just a feature that has to be accommodated. Other browsers I have tried replace the current UI value, i.e. 55, with whatever was sent previously, i.e. 77, so this problem never shows itself. This is also my current work around, use JavaScript to over write the UI and form DOM values with whatever came in over the wire. I may get to work on a better solution in time!
Severity: major → normal
> It appears that the UI is updated and the forms .value fields are as well, but
> when the page is refreshed the current UI value us not sent over the wire, 

Right, because you're not _submitting_, you're _reloading_.  That is, loading exactly what you're looking at right now, but doing it again.

Sounds like everything is working as it should.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.