Closed Bug 122238 Opened 22 years ago Closed 20 years ago

input type="image" doesn't send x/y (image doesn't exist; width and height not set)


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






(Reporter: bugzilla.worldwide, Assigned: bzbarsky)





(2 files, 1 obsolete file)

<input border="0" src="doesntexist" name="Go1" type="image" />
<input border="0" src="doesntexist" name="Go2" type="image" width="170"
height="76" />
<input border="0" src="doesntexist" name="Go3" type="image">

Go2 works fine, cause width and height are set... but Go1 and Go3 doesn't send x
and y position. (Go3 isn't XHTML formated)
What x/y Sould it send if there are no dimension in the first place?
couldn't it send 0 ?

width and height aren't legal attributs for input element, so I've used css
style and set width/height - this works (see 

Severity: major → normal
* bug is a regression of bug 101596 *
Yes, CSS works.. but with absolutely no height/width definition I still don't
see why it should send 0,0.  There are literally no dimensions to the image, so
it sends none.  If you can find the spec that says that they should be sent,
I'll confirm.
Imagemapped Images and Image-Incapable User Agents


Processing TYPE=image Elements by Image-Incapable Agents 

"If a user agent incapable of processing images (for whatever reason) submits a
FORM via the TYPE="image" input element, then the encoded string from the
TYPE="image" element should take the (URL encoded) form:


That is, there should be no coordinate data passed to the server (the coordinate
data are null strings). The server resource processing the FORM data can use the
presence of "tstname.x" and "tstsname.y" NAMEs, and the absence of coordinate
data VALUEs, to infer that the user agent is not capable of processing images,
but that the user did select the TYPE="image" input element. If possible, the
server resource can then return a FORM more appropriate to the user agent's

Confirming as per comment 5. Platform & OS -> All. 
Should the component be 'Form submission'?
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
form submission
Assignee: rods → jkeiser
Component: HTML Form Controls → Form Submission
Attached patch Patch (obsolete) — Splinter Review
Here's a patch for posterity's sake; the problem here is, when width/height
aren't set we're displaying the words "Submit Image" for input type=image,
which makes this a lot more difficult.	Those don't even try to submit the

Unless and until that happens, I don't see a reason to put this patch through
the paces.
Target Milestone: --- → Future
Priority: -- → P5
*** Bug 142877 has been marked as a duplicate of this bug. ***
*** Bug 130918 has been marked as a duplicate of this bug. ***
Aren't we submitting the image properly?  Which means we should revisit this
patch again?
It's the images that are just "Submit Query" (since x/y=0) that don't submit
properly.  They are just links, they don't submit the form.
*** Bug 216924 has been marked as a duplicate of this bug. ***
Per Mats Palmgren's suggestion we tried hardcoding image width and height on an
(missing) image that had the problem  and we still didn't get back the x/y
coordinates of the image so it still didn't work.  (comments from test described
in bug 216924)
Jim Stavast
Jim, is your testcase in standards mode or quirks mode?
I don't know what you mean by "standards mode or quirks mode".  The test site
that I setup is running a shipping version of our ShopSite web store software. 
My Mozilla browser is just the default install, I don't think I made any special
changes to anything when I installed it.
I have tried several things but nothing seems to help.  Is what I describe below
If the document has no DOCTYPE definition it fails  (quirks mode on?)

If the document has the DOCTYPE <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN">. or the 
DOCTYPE <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"">  it fails ( Almost standar mode)

If the document has the DOCTYPE <!DOCTYPE HTML> it fails (standard mode)

Am I missing something?
Jim, is your image replaced with just the alt text, or with a broken image icon 
followed by the alt text in those cases?  In quirks mode with size set, we 
should be showing the broken image icon followed by alt text, and sending the 
coords... In standards mode, or with no size set, we can't really send coords, 
since coords make no sense when the inline alt text simply replaces the image...
There is no broken image just the alt text.  The size is not set because the
size is determined by the image and we don't know what the image size will be
because the store owner can change the image itself and we have no idea how big
they will make it. 
Here is the source for one of the buttons that can't be submitted if the image
is missing.  It is in a form with several other submit buttons and various
hidden input fields.
<input type=image
align="bottom" border="0" name="Recalculate" alt="Recalculate"
onClick="return(CheckIt(7,0));" >

I modified it to include a height and width and I also remove the onClick but it
still doesn't work.  The browser knows that the text has been clicked because
even without the onClick it does a refresh of the screen it just doesn't do the
submit.  Clicking elsewhere on the page causes no action so it must know that
that particular text has been clicked on.  I'm not the programmer but I believe
he said we are looking for the name of the button being returned and it isn't
returned at all(with or without x/y coordinates).  In  Netscape 4 and IE a
broken image is shown.  How do they process the button without the image?? 
> I modified it to include a height and width

Did you get a broken image icon after that?
No broken image displays just the text.
Looks like this problem still exists and was not addressed so far. Why? It would
not be hard to solve. Just submit Name.x=0&Name.y=0 or whatever position the
user clicked in the image button replacement. To argue that it has not dimension
is nonsense 'cause the replacement *has* dimensions. So you could just submit,
where the user clicked the replacement.

I don't know what the specs say. I doubt they prohibit to submit coordinates.
But from a developer point of view it would be just stupid to always have to
check two parameters, namels the one with coordinats (.x) and the one without,
just for the case that the users disabled images and uses mozilla. 
Thank you for volunteering to implement this easy fix.

I'll review the patch once you post it.
Assignee: john → jabernet
Ok. I read through the text and I think you were working on it lately. I just
hadd a look at when the bug was reported and that there was a patch which has
just not been implemented. Seems not exactly to be like that.

I still cannot imagine that it is so hard to change behaviour from submitting
only the name to submitting the name plus the coordinates. As far as I
understand, its because the image-replacement is not the same class as the
image-button, right?
Yep.  That's exactly the problem.  The replacement is just a normal text layout
object in the circumstances that trigger this bug...
Some solutions I could imagine:

 - Subclass the class for an image-button and from the class used to show the
replacement, so you get the visual behaviour for displaying and the submitting
behaviour (just an abstract explenation)

 - add an attribute to that text-replacement which marks it as a special
replacement so it can be handled differently than normal text

 - replace it with dummy transparten image-button which lays over/under the text

I think the last solution would be the easies to implement, although maybe not
the cleanest one. 

Also what I'm asking myself, why does the input with a speciefied width work,
and why does that one without it not? Whats the difference here?
*** Bug 218612 has been marked as a duplicate of this bug. ***
When you have a specified size, and are in quirks mode, we do
"backwards-compatible" replacement.  That is, the image frame itself draws the
alt text.  The alt text is cropped to the specified size, of course.  This is to
keep from "breaking" the so-called "layout" of pages that can't handle images
being replaced by alt text.

If you have no size or are in standards mode, we just create a text frame.

The right fix is probably to find why the text object submits at all (presumably
the event is handled by the DOM node in that case) and to change that code to
send  the string as described in comment 5.
*** Bug 231664 has been marked as a duplicate of this bug. ***
Attached file testcase
I can't believe I missed the earlier patch posted in this bug....

Note that comment 12 is not correct as far as I can tell.
Attachment #77420 - Attachment is obsolete: true
Attachment #139545 - Flags: superreview?(jst)
Attachment #139545 - Flags: review?(jst)
Comment on attachment 139545 [details] [diff] [review]
Same as jkeiser's patch, really...

+    if (!name.IsEmpty()) {
+      aFormSubmission->AddNameValuePair(this,
+					 name + NS_LITERAL_STRING(".x"), xVal);
+      aFormSubmission->AddNameValuePair(this,
+					 name + NS_LITERAL_STRING(".y"), yVal);
+    } else {
+      // If the Image Element has no name, simply return x and y
+      // to Nav and IE compatability.
+      aFormSubmission->AddNameValuePair(this, NS_LITERAL_STRING("x"), xVal);
+      aFormSubmission->AddNameValuePair(this, NS_LITERAL_STRING("y"), yVal);

How about something like this in stead:

+    const nsAString& nameToSubmit = name + name.IsEmpty() ?
+      EmptyString() : NS_LITERAL_STRING(".");
+    aFormSubmission->AddNameValuePair(this,
+				       nameToSubmit + NS_LITERAL_STRING("x"),
+    aFormSubmission->AddNameValuePair(this,
+				       nameToSubmit + NS_LITERAL_STRING("y"),

r+sr=jst either way.
Attachment #139545 - Flags: superreview?(jst)
Attachment #139545 - Flags: superreview+
Attachment #139545 - Flags: review?(jst)
Attachment #139545 - Flags: review+
If I do that, it may well run into the bug 70083 issues (incorrectly
concatenates stuff).  So I'm leaving the code as in that patch.

Fix checked in.  I still don't know why jkeiser thought this was the wrong way
to go....
Closed: 20 years ago
Resolution: --- → FIXED
Resolution: FIXED → ---
Assignee: jabernet → bz-vacation
Closed: 20 years ago20 years ago
Priority: P5 → P3
Resolution: --- → FIXED
Target Milestone: Future → mozilla1.7alpha
*** Bug 239382 has been marked as a duplicate of this bug. ***
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.