If you're using the WYSIWYG editor for system preferences, the TinyMCE editor will update the system preference text editor when the content is different to the content that the editor started with when the page was loaded. If you change the content and then change it back to the original content, the editor will actually use the last "different" content. Eg: TinyMCE Editor: 123a Textarea: 123a TinyMce Editor: 123 Textarea: 123 TinyMce Editor: 123a Textarea: 123 This is due to (my) overzealous use of the "TinyMCE.isDirty()" function. I'll just strip it out and everything will be fine.
Created attachment 77322 [details] [review] Bug 21131 - Changing and restoring a WYSIWYG preference can result in unexpected behaviour When using the WYSIWYG editor for system preferences, the editor only updates the textarea element if the content is different from the original content. This means if you change a system preference and then change it back to the original content, the textarea will have the 2nd last change you made. This patch removes the TinyMCE.isDirty() check, which was responsible for comparing the original and changed content. Every input/keydown/dragend or TinyMCE command will cause the textarea element to be updated and trigger the input event which causes the "modified" class to be added to the element, so that the system preference can be saved. __TEST PLAN__ _Before applying_ 0. Change "UseWYSIWYGinSystemPreferences" to "Show" 1. Change "opaccredits" to "123a" 2. Click "Save all OPAC preferences" 3. Reload the page 4. Change "opaccredits" to "123" 5. Change "opaccredits" to "123a" 6. Click "Save all OPAC preferences" 7. Reload the page 8. Note that "opaccredits" says "123" _Apply the patch_ _After applying_ 1. Change "opaccredits" to "123a" 2. Change "opaccredits" to "123" 3. Click "Save all OPAC preferences" 4. Reload the page 5. Note that "opaccredits" says "123" (and not "123a") 6. Change "opaccredits" to "1234" 7. Click "Save all OPAC preferences" 8. Reload the page 9. Note that "opaccredits" says "1234"
Created attachment 77389 [details] [review] Bug 21131 - Changing and restoring a WYSIWYG preference can result in unexpected behaviour When using the WYSIWYG editor for system preferences, the editor only updates the textarea element if the content is different from the original content. This means if you change a system preference and then change it back to the original content, the textarea will have the 2nd last change you made. This patch removes the TinyMCE.isDirty() check, which was responsible for comparing the original and changed content. Every input/keydown/dragend or TinyMCE command will cause the textarea element to be updated and trigger the input event which causes the "modified" class to be added to the element, so that the system preference can be saved. __TEST PLAN__ _Before applying_ 0. Change "UseWYSIWYGinSystemPreferences" to "Show" 1. Change "opaccredits" to "123a" 2. Click "Save all OPAC preferences" 3. Reload the page 4. Change "opaccredits" to "123" 5. Change "opaccredits" to "123a" 6. Click "Save all OPAC preferences" 7. Reload the page 8. Note that "opaccredits" says "123" _Apply the patch_ _After applying_ 1. Change "opaccredits" to "123a" 2. Change "opaccredits" to "123" 3. Click "Save all OPAC preferences" 4. Reload the page 5. Note that "opaccredits" says "123" (and not "123a") 6. Change "opaccredits" to "1234" 7. Click "Save all OPAC preferences" 8. Reload the page 9. Note that "opaccredits" says "1234" Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Created attachment 77390 [details] [review] Bug 21131: Remove the TinyMCE.isDirty() check that caused unexpected behaviour When using the WYSIWYG editor for system preferences, the editor only updates the textarea element if the content is different from the original content. This means if you change a system preference and then change it back to the original content, the textarea will have the 2nd last change you made. This patch removes the TinyMCE.isDirty() check, which was responsible for comparing the original and changed content. Every input/keydown/dragend or TinyMCE command will cause the textarea element to be updated and trigger the input event which causes the "modified" class to be added to the element, so that the system preference can be saved. __TEST PLAN__ _Before applying_ 0. Change "UseWYSIWYGinSystemPreferences" to "Show" 1. Change "opaccredits" to "123a" 2. Click "Save all OPAC preferences" 3. Reload the page 4. Change "opaccredits" to "123" 5. Change "opaccredits" to "123a" 6. Click "Save all OPAC preferences" 7. Reload the page 8. Note that "opaccredits" says "123" _Apply the patch_ _After applying_ 1. Change "opaccredits" to "123a" 2. Change "opaccredits" to "123" 3. Click "Save all OPAC preferences" 4. Reload the page 5. Note that "opaccredits" says "123" (and not "123a") 6. Change "opaccredits" to "1234" 7. Click "Save all OPAC preferences" 8. Reload the page 9. Note that "opaccredits" says "1234" Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Hi David, we standardized the commit messages a bit more: https://wiki.koha-community.org/wiki/Commit_messages - Start with Bug XXXX: - Describe the fix in the subject, not the problem :)
(In reply to Katrin Fischer from comment #4) > Hi David, we standardized the commit messages a bit more: > https://wiki.koha-community.org/wiki/Commit_messages > - Start with Bug XXXX: > - Describe the fix in the subject, not the problem :) Thanks, Katrin. I actually wrote to koha-devel asking about https://wiki.koha-community.org/wiki/Commit_messages#Examples, when I was writing up this bug report, because I didn't understand the examples. But I realize now that the page actually starts with https://wiki.koha-community.org/wiki/Commit_messages#Good_commit_messages. I had no idea! But according to https://wiki.koha-community.org/wiki/Commit_messages#Subject_line, the prototypical example seems to describe the problem and not the fix :S.
Btw, I am super duper happy to follow a standard, so long as I actually know what the standard is... I see in https://wiki.koha-community.org/wiki/Commit_messages#Good_commit_messages_2 that the subject line describes the fix and not the problem though.
Awesome work all! Pushed to master for 18.11
Pushed to 18.05.x for 18.05.03
Pushed to 17.11.x for 17.11.10