-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
com_redirect modal close button check in fix #19116
Conversation
'height' => '400px', | ||
'width' => '800px', | ||
'bodyHeight' => '70', | ||
'modalWidth' => '80', | ||
'closeButton' => false, | ||
'backdrop' => 'static', | ||
'keyboard' => false, | ||
'footer' => '<button class="btn" data-dismiss="modal" aria-hidden="true">' | ||
. JText::_("JLIB_HTML_BEHAVIOR_CLOSE") . '</button>' | ||
'footer' => '<button type="button" class="btn" data-dismiss="modal" aria-hidden="true"' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other buttons don't have type="button"
. Can it be omitted?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Omitting the type defaults to type = submit.
Following the info provided by @brianteeman all three buttons should be of type = button because:
"The button has no default behavior. It can have client-side scripts associated with the element's events, which are triggered when the events occur."
The assumption I make here is that both the save and save & close buttons do not submit the form (then they should be of type=submit), but trigger jQuery script that does the checking and saving.
If the above is the way to go (all buttons type = button), then there are probably other areas where we can improve.
Can somebody confirm?
What I learned is that using the < a> in a form is wrong. Although it works, it behaves differently in e.g. accessibility use cases (for a Screen-Reader a link behaves different to a button (tab index, space bar / enter behavior)).
https://css-tricks.com/use-button-element/
Op 23 dec. 2017 19:11, om 19:11, Quy <notifications@github.com> schreef:
…In the edit article modal, `<a>` is used instead of `<button>`. Maybe
use `<a>` to be consistent.
![article-edit-modal](https://user-images.githubusercontent.com/368084/34321642-068edda2-e7c9-11e7-8dad-4661edbe8e87.gif)
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#19116 (comment)
|
I have tested this item ✅ successfully on 71bb5d9 This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/19116. |
I have tested this item ✅ successfully on 71bb5d9 This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/19116. Tested in: Firefox 57.0.3 |
The reason for A tag instead of BUTTON, which is the correct one, has to do with the stupid bootstrap modal script! To verify this go to the page with this modal and press enter (it doesn't matter which element has focus), the form will be submitted although it shouldn't. Now change the Button to A tags and retest, form will not submit! This is a hack that is needed atm as we cannot change the Bootstrap 2.3.2 javascript! |
Ready to Commit after two successful tests. |
@franz-wohlkoenig NO, the tags need to be converted to A for the reason I stated above. Please remove the RTC label |
Hello @dgt41, just tried what you described: open the modal, press enter key. This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/19116. |
You need to test this with Firefox |
I am testing this with Firefox (Quantum): 57.0.3 (64-bit) This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/19116. |
I have tested this item 🔴 unsuccessfully on 71bb5d9 Because here is it not a real issue, because I can not reproduce it !!! See earlier test too. This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/19116. I can not reproduce the case of @dgt41 in Firefox and Google Chrome. |
@Ruud68 have you tested in Google Chrome (without the patch tester)? Result? |
Hi @sandewt I have just installed Google Chrome (Version 63.0.3239.108 (Official Build) (64-bit)) You tested unsuccessful, what is it that you tested? I am confused :) |
Hi @Ruud68, There is a misunderstanding. I mean with unsuccessfull in Google Chrome that the plugin is (remains) checked in without and with the patch tester. So you don't need the patch tester! I can't reproduce the case of @dgt41 in Firefox and Google Chrome. Gr. This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/19116. Note: Tested in Firefox 57.0.3 successfull. |
Okay, retested everything both with FF and Chrome. without patch: with the patch applied: So the issue raised by @dgt41 that blocks this patch from becoming RTC CANNOT be reproduced (at least by me and @sandewt ). I have tried to reproduce on both a clean install as on (multiple) production sites). How to proceed? This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/19116. |
Ready to Commit as stated above. |
Pull Request for Issue # .
Summary of Changes
Changed the close button (footer) to execute the plugin.cancel task
Testing Instructions
Expected result
The plg_system_redirect should be checked in
Actual result
The plg_system_redirect is NOT checked in.
in [tab 2] press ctrl-f5 and you can see that although the modal in tab 1 is closed, the plugin is not checked in correct.
Documentation Changes Required
none.
Note
this was previously fixed here: #18292 but unfortunately reintroduced with normalize patch: #18913