176868 - values of submitted POST-forms set to 1 for no reason

Status: VERIFIED FIXED

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

Description

[Jonathan P. Chapman]

Hi!

This is somewhat strange and I didn't see it on another page yet:
This page contains a small table with a form that will get email-addresses from
people that work in a seminar together with me and will have some reaction
placed into that table (address accepted - change despite (check for
spelling-errors anyway)?; email rejected - please check for spelling errors;
already entered email (read from cookie - enter anyway by clicking on the
button: even in this case (no email-form field present) the email-variable will
be set to 1); first visit - please enter email):
http://chapman.in-die-regierung.de/prosem/
The form bounds the paragraph that table is placed in (due to layout reasons I
did not place it into the actual table). Now what I noticed is that whatever I
enter into the email-field, the script will recieve a 1 (depending on the case
there are up to three hidden fields that will - if set - send a 1). I fixed some
minor syntax errors, but the error keeps persisting.
I checked the page with Mozilla 1.1 and MSIE 5 and no problems at all (script
fully reacting as expected) - as the error appeared in P 0.2 and also in this
night's 0.3 binary, I guess its not resolved yet.

Thank you for helping!

Comment 1

[Asa Dotzler [:asa]]

bugs with web content are overwhelmingly Mozilla bugs and not Phoenix bugs
(Phoenix is overwhelmingly chrome changes and very few if any layout or
networking, etc. changes) Checking with mozilla 1.1 is not sufficient. If you
checked the latest mozilla nightly build and don't see a problem then report it
to Phoenix. Otherwise assume it's mozilla. 

Comment 2

[Boris Zbarsky [:bzbarsky]]

So.. I enter an email address in that field, click the image input, the address
and the click coordinates are the only things I see being submitted to the server.

So what exactly is the bug?  How do I tell whether the behavior is correct?

Comment 3

[Jonathan P. Chapman]

Hi!

The page's in German - sorry, this could mascerade the error! If you visit it
again, you will see that the table will have changed (text only and a single
image input) - that is: The cookie set when recieving any email-input from the
form earlier was set and successfully read when you visit the site, now.
If you click the Button (="You already submitted an email address - enter
another email-address anyway"), you will get to the same page with the
"original" input form. You will also notice, that there's a "1" in the
email-formfield, even though there is no email-ff in that cookie-activated form!
That is because the "email"-variable is written into the ffs value=""-tag. (I
had placed an echo $email at several locations in that script so see wether it
is implicitely set somewhere, but its already set when the script is executed!)
As stated above I don't see any mistake in either the HTML-page nor in the
underlying PHP-script (it's rather simple anyway), so I assume it's Phoenix only
as neither Moz, nor MSIE or  Netscape 4.8, NS 3 or even 2 seem have problems
with that page at all (despite some JS-issues in NS 3, 2 that have no impact on
the form at all).
I am just downloading Moz's nightly trunk, so I can check what Asa stated -
whether that behavior is a Mozilla-Bug that is new since 1.1 or it still seems
to be a Phoenix only bug.
Well Boris, if you visit the page for the first time (or deleted the cookie)
that's all I expect the page to do. No hidden form field or else in the first
page. The other pages may have "override" and/or "aendern" (=change) set to 1 to
signal the script to display the initial page even if a cookie is found
(override) and/or that the email-address was considered misspelled and should be
changed - if "aendern" is set, it will use "alteemail" (=oldemail) to supply the
old email-address, so the row to replace can be identified.
In the effect, I didn't get anything but a 1 for any variable from Phoenix to
the script (getting careful, now :-)

Well, I checked with Moz, now, and it didn't have any problem, still, so it does
seem to be a Phoenix-only problem :-(

Anyway: I built a small test-page for you that will have English variables and
labeling, being based on exactly the same script and layout:
http://chapman.in-die-regierung.de/prosem/moz.php

I hope this will help! CU!

Comment 4

[Boris Zbarsky [:bzbarsky]]

OK.  So on both versions of the page, I put in an email, then I click the
button.  I get an error page saying the address is invalid and showing the
address in the textfield.

I load the page again.  There is no textfield on it.  I click the "enter again"
button.  I get the textfield, with nothing filled in in it.  Is that correct
behavior?

This is all with Mozilla build 2002-10-25-08.

I'm starting to get a sneaking suspicion that this is a satchel problem.  If you
disable all form autocomplete and prefill features in phoenix, does that fix the
problem?

Comment 5

[Jonathan P. Chapman]

Hi!

Well, to make things easier - I'll give a small overview, so things don't get
too confusing (I also added these numbers to the forms on the page and added the
source, too):
Form 1:
- First visit: Enter Email - no cookie present
Form 2:
- Got email and approved: Email valid - cookie is set - email-formfield
(containing the sent email-address) still present to allow corrections to the
email-address.
Form 3:
- Got email but address is invalid: No cookie setting this time -
email-formfield present - given email address in it.
Form 4:
- Loading the page with cookie set and no formfield-data being sent: No
formfield at all, this time - only the image to get to form 1.

Paths through the page are:
1 -> 2
1 -> 3 (as often as you like ;-) -> 2
4 -> 1 -> 2
4 -> 1 -> 3 (still as often as you like :-) -> 2
where if you ever saw a 2 should get to 4 whenever you reload or reenter

Okay, if you reload and there is no textfield at all, the cookie must have been
set - this happens, if the email-address is approved and inserted into the
database, only (has it been set earlier, maybe? - see the source: this is one
unit that cannot be split up by corrupt data)? - All other pages, whether
approving or disapproving have that formfield, so I'm not sure what path you
took - at least its none I expected. Actually, I didn't find a new address in
the database, so I guess you did not reach form #2 and no cookie should habe
been set. (btw: I added a field that allows me to identify addresses added by
the moz.php-page - so feel free to enter "correct" email-addresses, when testing
(correct addresses should have at least one letter, number, _ or - infront of a
@ - at least one letter (= a-z, 0-9, _, -) after the @, a . and at least two
letters beyond))
Ignoring that form 4 should not have shown up, behavior is right - if you click
on the image on the page without any text-field, you will get to form 1.
Actually, I'm not sure, whether you will be able to reproduce the error on
Mozilla: I didn't find any thread in the Mozilla-Bugzilla that seemed equal and
neither did it occur in the old or the current version of Moz. Try Phoenix, if
you have a build and you should see, what I mean :-/

Sorry about it, but I don't see where to turn the autocomplete off in Phoenix
(nor where to turn it on :-( ), so I can't check that out.

Once again: The error is totally odd: I don't see any reason at all, why $email
is set to 1 - neither in the PHP, nor in the HTML and the error does not
reproduce with any other browser (incl. Moz)! So if you are using P, you will
likely not see any other page but 3, whenever submitting!

Comment 6

[Jonathan P. Chapman]

Just a small update:
Today's 0.4 still has the bug :-(

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

looks like form submission to me

Comment 8

[Jonathan P. Chapman]

Hi!

Sorry, but I forgot so change this thread's status - the bug does no more appear
with P 0.4, so I assume it has been resolved somehow. (Maybe some other, better
researched bug caused it!?)

Thank you for your hard work!

Jonathan

Comment 9

[Vladimir Ermakov]

verifying