Strange post data from <input type=image...
<input type="image" name="CONFIRM" src="ecoupon-abschicken.gif" border="0" height="13"> This line produces for example(when you have clicked on that button): CONFIRM=&CONFIRM.x=7&CONFIRM.y=9 With netscape4.7 and mozilla, only CONFIRM.x=7&CONFIRM.y=9 is sent. I have found one form which seems not to work with dillo but with netscape. Unfortunately, that is a form for a transferal from a bank and it works fine with the demo account, so that is really hard to test. Does anyone know if that is a bug in dillo and/or how to fix that? Greetings Andreas Kemnade
On Thu, 22 May 2003, Andreas Kemnade wrote:
<input type="image" name="CONFIRM" src="ecoupon-abschicken.gif" border="0" height="13"> This line produces for example(when you have clicked on that button): CONFIRM=&CONFIRM.x=7&CONFIRM.y=9
With netscape4.7 and mozilla, only CONFIRM.x=7&CONFIRM.y=9 is sent. I have found one form which seems not to work with dillo but with netscape. Unfortunately, that is a form for a transferal from a bank and it works fine with the demo account, so that is really hard to test.
Does anyone know if that is a bug in dillo and/or how to fix that?
HTML 4.01 standard section 17.13.2 (Successful controls) tells: | A successful control is "valid" for submission. Every successful control | has its control name paired with its current value as part of the | submitted form data set. A successful control must be defined within a | FORM element and must have a control name. and | If a control doesn't have a current value when the form is submitted, | user agents are not required to treat it as a successful control. So the behaviour is *imho* undefined. It would be helpful, when someone could confirm that i've understood the standard correctly (or find out a correct browser behavior). Checking out other browsers behavior with input images having a value attribute would also be useful (i just don't have enough free time for this at moment, sorry). It may be possible to achieve compliance with other browsers using this patch: ================================================================= diff -pru -x CVS -x configure -x 'aclocal*' -x 'Makefile*' -x config.h.in cvs/dillo/src/html.c dillo/src/html.c --- cvs/dillo/src/html.c 2003-05-01 16:58:30.000000000 +0300 +++ dillo/src/html.c 2003-05-23 01:47:53.000000000 +0300 @@ -2900,7 +2993,8 @@ static void Html_submit_form(GtkWidget * break; case DILLO_HTML_INPUT_IMAGE: if (input->widget == submit) { - Html_append_input(DataStr, input->name, input->init_str); + if (input->init_str) + Html_append_input(DataStr, input->name, input->init_str); Html_append_clickpos(DataStr, input->name, click_x, click_y); } break; @@ -3123,7 +3217,8 @@ static void Html_tag_open_input(DilloHtm } Html_add_input(form, inp_type, widget, name, - (init_str) ? init_str : "", NULL, init_val); + (init_str || inp_type == DILLO_HTML_INPUT_IMAGE) + ? init_str : "", NULL, init_val); if (widget != NULL && inp_type != DILLO_HTML_INPUT_IMAGE) { if (inp_type == DILLO_HTML_INPUT_TEXT || ================================================================= I only checked, that it doesn't crash on first click on input image, so its mostly untested and may not help and/or be broken in some ways.
On Fri, 23 May 2003 02:19:47 +0300 (EEST) Madis Janson <madis@ats.cyber.ee> wrote:
So the behaviour is *imho* undefined. It would be helpful, when someone could confirm that i've understood the standard correctly (or find out a correct browser behavior). Checking out other browsers behavior with input images having a value attribute would also be useful (i just don't have enough free time for this at moment, sorry).
Very interesting: <input type="image" name= "CONFIRM" value="bla" src="ecoupon-abschicken.gif" border="0" height="13"> netscape 4.7 sends the same as without value and mozilla sends an additional CONFIRM=bla Greetings Andreas Kemnade
On Fri, 23 May 2003, Andreas Kemnade wrote:
On Fri, 23 May 2003 02:19:47 +0300 (EEST) Madis Janson <madis@ats.cyber.ee> wrote:
So the behaviour is *imho* undefined. It would be helpful, when someone could confirm that i've understood the standard correctly (or find out a correct browser behavior). Checking out other browsers behavior with input images having a value attribute would also be useful (i just don't have enough free time for this at moment, sorry).
Very interesting: <input type="image" name= "CONFIRM" value="bla" src="ecoupon-abschicken.gif" border="0" height="13">
netscape 4.7 sends the same as without value and mozilla sends an additional CONFIRM=bla
Then the patch should behave like mozilla. Did it fixed the problem?
On Fri, 23 May 2003 11:07:14 +0300 (EEST) Madis Janson <madis@ats.cyber.ee> wrote:
On Fri, 23 May 2003, Andreas Kemnade wrote:
On Fri, 23 May 2003 02:19:47 +0300 (EEST) Madis Janson <madis@ats.cyber.ee> wrote:
So the behaviour is *imho* undefined. It would be helpful, when someone could confirm that i've understood the standard correctly (or find out a correct browser behavior). Checking out other browsers behavior with input images having a value attribute would also be useful (i just don't have enough free time for this at moment, sorry).
Very interesting: <input type="image" name= "CONFIRM" value="bla" src="ecoupon-abschicken.gif" border="0" height="13">
netscape 4.7 sends the same as without value and mozilla sends an additional CONFIRM=bla
Then the patch should behave like mozilla. Did it fixed the problem?
No, it didn't fix the problem. But the patch did what it should (sent a form to netcat) Greetings Andreas Kemnade
participants (2)
-
Andreas Kemnade
-
Madis Janson