Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Enable attached example module and go to /triggering-elements
In Chrome go over the tabs and click enter (i.e. don't click with the mouse). The $form_state['triggering_element']['#value'] changes according to the selected tab.
In Firefox go to the second tab and hit enter. $form_state['triggering_element']['#value'] is the first button instead of the second.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 1153960-trigger-element-7.patch | 1.01 KB | amitaibu |
| #5 | 1153960-trigger-element-5.patch | 753 bytes | amitaibu |
| user_modal.tar_.gz | 1.09 KB | amitaibu | |
Comments
Comment #1
Damien Tournoud CreditAttribution: Damien Tournoud commentedTry disabling Javascript and you will see that the behavior remains the same.
It's a browser issue, and a very messy one. HTML5 has some nothing to say on this issue:
"May", "May pick another", ...
Comment #2
amitaibuSo you say we should change the variable name to "#it-might-be-the-triggering_element" ? ;)
Comment #3
Damien Tournoud CreditAttribution: Damien Tournoud commentedIt is the triggering element alright. It's just that each browser have a different notion of what is the default button associated with a text field.
Comment #4
amitaibuThe problem that I had with it, was when I wanted to use #limit_validation_errors. So in the end I gave all the submit buttons the same #limit_validation_errors so it will validate only what is really needed.
I guess this issue should be about writing a patch to document the fact that #triggering_element is browser specific.
Comment #5
amitaibuLittle docs about this.
Comment #6
rfayThis has been brought up before, and I *think* it's a general web-wide problem with browsers not being consistent. I've fought with it quite a lot (I hate the performance settings page because I always hit enter to submit, and it clears the cache instead of saving my settings.)
I suppose we could do something about this with javascript, but not sure there's a general solution. However, I'm certainly not a wise one in this area.
Comment #7
amitaibuA bit better docs.
Comment #8
rfayHmm. $form_state['clicked_button'] is obsolete ($form_state['triggering_element'] has replaced it. So in 8.x we should remove 'clicked_button' completely from the doc.
Moving this to 8.x since it has to be done there first.
I don't have an objection to documenting this in the AJAX stuff (I don't think) but I don't think this problem has anything to do with Drupal.
Comment #9
amitaibu> I don't think this problem has anything to do with Drupal.
I agree it's not a Drupal bug, but still I think a line or two can help people understand why their form isn't submitted as they might expect.
Comment #10
rfayComment #11
amitaibu@rfay,
Your comment on #10 is empty?
Comment #12
amitaibu#7: 1153960-trigger-element-7.patch queued for re-testing.
Comment #14
Everett Zufelt CreditAttribution: Everett Zufelt commented+ * and is also used in Ajax handlers. Note that the value of the triggering
+ * element after a user pressed the enter key is browser specific, as the HTML
+ * does not specify clear enough which element should be selected as the
Note that the value of the triggering element after a user presses the enter key is browser specific, as HTML does not provide a mechanism to specify which button to use as the triggering element.
Comment #27
smustgrave CreditAttribution: smustgrave at Mobomo commentedTested on safari, chrome, and firefox and not seeing any issue with the states.
If still a valid task please reopen updating issue summary to reflect D10
Thanks!