Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

image type submit buttons not handled correctly #2814

Closed
jshepler opened this Issue Oct 22, 2011 · 12 comments

Comments

Projects
None yet
3 participants

The code at line 4779 (1.0rc2) only generates a single hidden input element for image inputs instead of correctly generating two: name.x and name.y

Apparently asp.net requires values to be set on those fields in order to determine the image button caused the postback. I set the values of both fields to "0" and asp.net was appeased.

Being that jQM is targeting touch-based devices, I would assume you could do the same instead of trying to determine what exact pixel of the image was "clicked"? Or maybe determine the middle pixel?

Contributor

toddparker commented Oct 28, 2011

Now that's a bizarre issue. We'll take a look.

Member

jaspermdegroot commented May 27, 2012

@toddparker

I believe input type="image" was invented for image maps, which explains why both x and y are required.
Anyway, since we already established that this type is kinda useless for JQM enhanced buttons and removed the example from that page I suggest to close this issue.
Still can use it with data-role="none"

While I would agree that these image "buttons" should not be enhanced visually, it is still a valid element to trigger form submissions. It's part of the HTML standard and should be supported by anything that is going to alter the normal POST functionality of a browser.

Member

jaspermdegroot commented May 29, 2012

@jshepler - I agree with that. That's what I meant by using it with data-role="none".
By doing so the button widget won't be used, so the button will not be visually enhanced and also that hidden input element won't be generated.
So, unless I miss something here, the normal post functionality isn't altered.

Contributor

toddparker commented May 29, 2012

I know people used to use the input type=Image for image-based buttons back in the old days but this might still have a use for some people. Allowing these to work as expected (show the image) is the way to go.

I agree that we should just leave image inputs alone via data-role="none" as @ugomobi suggested. Since this is a somewhat larger changes, this should land for 1.2 but not be picked over to 1.1.1.

Member

jaspermdegroot commented May 29, 2012

@toddparker - Ok, I will remove input type="image" from the types that are auto initialized.

Unless I'm missing something, we're talking about how JQM handles form submissions (altering the normal POST functionality using ajax). Since jQuery's .serialize() doesn't include submit buttons, JQM attaches a click handler to these buttons to inject hidden form fields. It's already doing this (line v1.1.0, line 5467), presumably because server-side code routinely needs to know what control triggered the post. JQM handles the situation correctly, except for input type="image" elements, which need two hidden form fields instead of one, as per the HTML spec.

I don't understand how "work as expected (show the image)" equates to removing it from the initSelector, which will result in the element not having the click handler to inject the hidden form fields and therefore not getting the enhanced navigation like the other submit buttons.

I agree it should be ignored for the visual enhancements, but adding a little bit of code so this element generates two hidden form fields is pretty trivial. What am I not getting?

Member

jaspermdegroot commented May 29, 2012

@Wilto

Can you give this a look?

It seems to me that you still can use the Ajax form handling since that is not part of the button widget. Only point is that if you want the x and y coordinates to be included in the string you have to add hidden inputs to your markup yourself.
Am I correct?

Ha, I'm an idiot, sorry.. Don't know why I thought removing the element from the button widget would stop it from triggering JQM's navigation.

How about moving the click handler out of the widget? It doesn't exactly fit here anyways - from the perspective that the widget is for visual enhancements. Maybe put it into $.mobile._registerInternalEvents(), where the form submission and other click handlers are set.

Contributor

toddparker commented May 29, 2012

Yes, this just removes the button styling, the AJAX nav is a separate concern. We'll give the event bindings a look but this is a much bigger change for us to make. Thanks for your help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment