ImageButton control fails to capture click event when alternate textis displayed

[Benjamin Gavin]

Hi all,
I recently stumbled upon a bug in the ASP.NET framework handling of
ImageButton based postbacks. The issues derives from the fact that IE
and Mozilla [don't know about Opera, Safari, etc] handle the case of a
missing [or blocked] image file differently. In both cases, the setup
for the problem is:

1. Create a form with an ImageButton whose ImageURL is invalid, specify
an AlternateText value
2. Submit the form through that ImageButton

We'll start with IE's solution:

IE creates a "dummy" broken image which contains the alternate text.
This "seems" to work, only insomuch as is sends the coordinates of where
you click on the "dummy" image, which may or may not have any relation
to the coordinates on the actual image [for instance if I was clicking
the image to have different areas perform different functions]. This
"works" in the sense that the ImageButton event is fired, but the
underlying coordinates that are sent are meaningless because they don't
relate in any way to the actual image that should have normally been
displayed.

Now Mozilla's solution:

Mozilla creates a PostBack event, and includes the relevant field.x and
field.y POST variables, but leaves them both empty [since it can't
determine where on the image the user clicked because there was no
image]. This causes a problem because while ASP.NET captures the fact
that there was a PostBack, it does not properly link the PostBack event
to the control which caused it to happen [in this case "field"]. In the
end, the Click event for that ImageButton is not fired at all.

I consider this a bug in ASP.NET's handling of ImageButton postbacks,
and while in my case it was brought on by the fact that the image is
missing [we are mid-development and don't have all the images prepped
yet], but it would be equally true if the user had turned off image
support in their browser [how does IE handle this scenario?] or if the
user was using a text-only browser of some kind. Is there a reason that
the PostBack is not processed by the ASP.NET engine even though the
requisite fields are included in the POST data?

Thanks!
Ben

 

[Benjamin Gavin]

Over two weeks and not a single response? Is this something that is
being looked into or is there a fix in the pipeline? I'd rather not
"roll my own fix" if I can avoid it...

Thanks!
Ben

 

[bruce barker]

it is a .net bug. they should be setting a value attribute which netscape
will post (though ie doesn't - ie bug), then when posted without an image it
acts as a normal submit button.

no telling how fast (or if) MS will fix this, open a bug report. you may
want to write your own submit button.

-- bruce (sqlwork.com)

Over two weeks and not a single response? Is this something that is
being looked into or is there a fix in the pipeline? I'd rather not
"roll my own fix" if I can avoid it...

Thanks!
Ben

Hi all,
I recently stumbled upon a bug in the ASP.NET framework handling of
ImageButton based postbacks. The issues derives from the fact that IE
and Mozilla [don't know about Opera, Safari, etc] handle the case of a
missing [or blocked] image file differently. In both cases, the setup
for the problem is:

1. Create a form with an ImageButton whose ImageURL is invalid, specify
an AlternateText value
2. Submit the form through that ImageButton

We'll start with IE's solution:

IE creates a "dummy" broken image which contains the alternate text.
This "seems" to work, only insomuch as is sends the coordinates of where
you click on the "dummy" image, which may or may not have any relation
to the coordinates on the actual image [for instance if I was clicking
the image to have different areas perform different functions]. This
"works" in the sense that the ImageButton event is fired, but the
underlying coordinates that are sent are meaningless because they don't
relate in any way to the actual image that should have normally been
displayed.

Now Mozilla's solution:

Mozilla creates a PostBack event, and includes the relevant field.x and
field.y POST variables, but leaves them both empty [since it can't
determine where on the image the user clicked because there was no
image]. This causes a problem because while ASP.NET captures the fact
that there was a PostBack, it does not properly link the PostBack event
to the control which caused it to happen [in this case "field"]. In the
end, the Click event for that ImageButton is not fired at all.

I consider this a bug in ASP.NET's handling of ImageButton postbacks,
and while in my case it was brought on by the fact that the image is
missing [we are mid-development and don't have all the images prepped
yet], but it would be equally true if the user had turned off image
support in their browser [how does IE handle this scenario?] or if the
user was using a text-only browser of some kind. Is there a reason that
the PostBack is not processed by the ASP.NET engine even though the
requisite fields are included in the POST data?

Thanks!
Ben

 

[Alex Homer]

One interesting test you could do is look at the values in the Request.Form
collection (turn on racing for the page). It may be the fault of the browser
and not ASP.NET - if the browser doesn't send back the (correct)
co-ordinates, ASP.NET has no chance of giving you the right answer...

On a similar topic, try specifying a width and height for the image that is
different to the actual image size and try different browsers. You'll see
that some don't actually resize the image (HTML rules say that they should
not) while some do. If the image has been resized, or cannot be displayed,
how does the browser know what size it actually should be or where the mouse
pointer is in relative pixels (and therefore work out the coordinates)
anyway?