New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot attach change-eventlistener on selectmenu wigdet #7363

Closed
ottoville opened this Issue May 4, 2014 · 5 comments

Comments

Projects
None yet
4 participants
@ottoville

See jsfiddle http://jsfiddle.net/eg4Av/
Tested on Google Chrome and IE11.

If attached event with jQuery's 'on' instead of native 'addEventListener', then it works
http://jsfiddle.net/eg4Av/1/

To see correct behaviour, have to turn off the wigdet:
http://jsfiddle.net/eg4Av/2/

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof May 4, 2014

Contributor

I think this strikes at the very heart of our design :) We cover native elements in divs and links so that the user's actions never actually fall upon the native widget. This means that sometimes we have to trigger native events (like change) on the widget's behalf. We trigger with jQuery's .trigger() which does not produce a native event.

Contributor

gabrielschulhof commented May 4, 2014

I think this strikes at the very heart of our design :) We cover native elements in divs and links so that the user's actions never actually fall upon the native widget. This means that sometimes we have to trigger native events (like change) on the widget's behalf. We trigger with jQuery's .trigger() which does not produce a native event.

@gabrielschulhof gabrielschulhof added this to the 1.5 - 2.0 milestone May 4, 2014

@jaspermdegroot jaspermdegroot modified the milestones: 1.5.0, 1.5 - 2.0 May 30, 2014

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Oct 2, 2014

Member

This is not a bug its just how events work in jQuery closing as not a bug.

Member

arschmitz commented Oct 2, 2014

This is not a bug its just how events work in jQuery closing as not a bug.

@arschmitz arschmitz closed this Oct 2, 2014

@ottoville

This comment has been minimized.

Show comment
Hide comment
@ottoville

ottoville Oct 2, 2014

This is not a bug? Wow, that is very sad statement for future of jQuery Mobile. All other form elements cause an change event to bubble up DOM tree, I don't see any reason to break HTML standard in this particular element.

In html5 standard section "4.10.5.5 Common event behaviors" it is written:

"When the input and change events apply (which is the case for all input controls other than buttons and those with the type attribute in the Hidden state), the events are fired to indicate that the user has interacted with the control. The input event fires whenever the user has modified the data of the control. The change event fires when the value is committed, if that makes sense for the control, or else when the control loses focus. In all cases, the input event comes before the corresponding change event (if any)."
http://www.w3.org/TR/html5/forms.html#common-input-element-events

If you move away from HTML5, you should at least change the statement in jQuery Mobile homepage, now it start with "jQuery Mobile is a HTML5-based user interface system "

This is not a bug? Wow, that is very sad statement for future of jQuery Mobile. All other form elements cause an change event to bubble up DOM tree, I don't see any reason to break HTML standard in this particular element.

In html5 standard section "4.10.5.5 Common event behaviors" it is written:

"When the input and change events apply (which is the case for all input controls other than buttons and those with the type attribute in the Hidden state), the events are fired to indicate that the user has interacted with the control. The input event fires whenever the user has modified the data of the control. The change event fires when the value is committed, if that makes sense for the control, or else when the control loses focus. In all cases, the input event comes before the corresponding change event (if any)."
http://www.w3.org/TR/html5/forms.html#common-input-element-events

If you move away from HTML5, you should at least change the statement in jQuery Mobile homepage, now it start with "jQuery Mobile is a HTML5-based user interface system "

@ottoville

This comment has been minimized.

Show comment
Hide comment
@ottoville

ottoville Oct 2, 2014

Also I guess this bug is root for many other weird bugs, such as this: #6021
If you break the native change behavior of form controls, who knows how many more incompatibilities will come.

Also I guess this bug is root for many other weird bugs, such as this: #6021
If you break the native change behavior of form controls, who knows how many more incompatibilities will come.

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Oct 2, 2014

Member

@ottoville maybe I misunderstand the issue. This is not a bug in jQuery mobile and not just about select elements. see @gabrielschulhof jsbin above. This is how jQuery events work. If you think this is a bug please feel free to file it as an issue on the jQuery repo. If i have misunderstood this issue please let me know.

Member

arschmitz commented Oct 2, 2014

@ottoville maybe I misunderstand the issue. This is not a bug in jQuery mobile and not just about select elements. see @gabrielschulhof jsbin above. This is how jQuery events work. If you think this is a bug please feel free to file it as an issue on the jQuery repo. If i have misunderstood this issue please let me know.

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