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

Status: RESOLVED FIXED

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

Description

[Lars Gregori]

<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)

Comment 1

[Aaron Kaluszka]

What x/y Sould it send if there are no dimension in the first place?

Comment 2

[Lars Gregori]

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
http://beidfarbig.de/mozilla_image_type2.php) 

Comment 3

[Lars Gregori]

* bug is a regression of bug 101596 *

Comment 4

[Aaron Kaluszka]

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.

Comment 5

[Lars Gregori]

Imagemapped Images and Image-Incapable User Agents 
http://www.w3.org/TR/NOTE-imagemap

...

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:

tstname.x=&tstname.y=

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
capabilities. 

...

Comment 6

[Russell Odom]

Confirming as per comment 5. Platform & OS -> All. 
Should the component be 'Form submission'?

Comment 7

[rods (gone)]

form submission

Comment 8

[John Keiser (jkeiser)]

Attachment: Patch

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
image.

Unless and until that happens, I don't see a reason to put this patch through
the paces.

Comment 9

[Vladimir Ermakov]

*** Bug 142877 has been marked as a duplicate of this bug. ***

Comment 10

[Boris Zbarsky [:bzbarsky]]

*** Bug 130918 has been marked as a duplicate of this bug. ***

Comment 11

[Boris Zbarsky [:bzbarsky]]

Aren't we submitting the image properly?  Which means we should revisit this
patch again?

Comment 12

[John Keiser (jkeiser)]

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.

Comment 13

[Mats Palmgren (inactive)]

*** Bug 216924 has been marked as a duplicate of this bug. ***

Comment 14

[Jim Stavast]

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

Comment 15

[Boris Zbarsky [:bzbarsky]]

Jim, is your testcase in standards mode or quirks mode?

Comment 16

[Jim Stavast]

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.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Jim, see http://www.mozilla.org/docs/web-developer/quirks/ 

Comment 18

[Jim Stavast]

I have tried several things but nothing seems to help.  Is what I describe below
correct?
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"
"http://www.w3.org/TR/html4/loose.dtd">  it fails ( Almost standar mode)

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

Am I missing something?

Comment 19

[Boris Zbarsky [:bzbarsky]]

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...

Comment 20

[Jim Stavast]

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
src="http://drought.shopsite.com/newtest/shopsite-images/en-US/_recalculate.gif"
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?? 

Comment 21

[Boris Zbarsky [:bzbarsky]]

> I modified it to include a height and width

Did you get a broken image icon after that?

Comment 22

[Jim Stavast]

No broken image displays just the text.

Comment 23

[Janick Bernet]

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. 

Comment 24

[Boris Zbarsky [:bzbarsky]]

Thank you for volunteering to implement this easy fix.

I'll review the patch once you post it.

Comment 25

[Janick Bernet]

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?

Comment 26

[Boris Zbarsky [:bzbarsky]]

Yep.  That's exactly the problem.  The replacement is just a normal text layout
object in the circumstances that trigger this bug...

Comment 27

[Janick Bernet]

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?

Comment 28

[Bob Firth]

*** Bug 218612 has been marked as a duplicate of this bug. ***

Comment 29

[Boris Zbarsky [:bzbarsky]]

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.

Comment 30

[Boris Zbarsky [:bzbarsky]]

*** Bug 231664 has been marked as a duplicate of this bug. ***

Comment 31

[Boris Zbarsky [:bzbarsky]]

See
http://lxr.mozilla.org/seamonkey/source/content/html/content/src/nsHTMLInputElement.cpp#2272

Comment 32

[Boris Zbarsky [:bzbarsky]]

Attachment: testcase

Comment 33

[Boris Zbarsky [:bzbarsky]]

Attachment: Same as jkeiser's patch, really...

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.

Comment 34

[Johnny Stenback (: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"),
xVal);
+    aFormSubmission->AddNameValuePair(this,
+				       nameToSubmit + NS_LITERAL_STRING("y"),
yVal);

r+sr=jst either way.

Comment 35

[Boris Zbarsky [:bzbarsky]]

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....

Comment 36

[Boris Zbarsky [:bzbarsky]]

*** Bug 239382 has been marked as a duplicate of this bug. ***