Issue metadata
Sign in to add a comment
|
Bug with perl based web application
Reported by
oneofthe...@googlemail.com,
Nov 24 2016
|
||||||||||||||||||||||||
Issue description
<b>Chrome Version : <Copy from: 'about:version'></b>
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
Safari:
Firefox:OK
IE:
vivaldi(chromium based):FAIL
The Bug appears in the ticket system OTRS. A testinstallation is available here: http://itsm-demo.otrs.com/otrs/index.pl?Action=AgentITSMConfigItemZoom;ConfigItemID=10
What steps will reproduce the problem?
(1)click on cmdb -> overview
(2)choose an item
(3)click edit and change something
(4) click submit
What is the expected result?
-> The new window should close now and the changes shoulb be submittet
What happens instead?
-> the window refreshes and nothing is changed
Please provide any additional information below. Attach a screenshot if
possible.
,
Nov 30 2016
When I go to the URL you mentioned, I get a login screen. What are the credentials?
,
Dec 1 2016
The given URl navigates to the login page . @oneoftheevil-- Please update the thread as per comment#2 and also provide us the chrome version and OS details , in which you faced the issue. Thanks!
,
Dec 1 2016
Sorry, with this link you should be logged in http://itsm-demo.otrs.com/otrs/index.pl?Action=Login&User=changemanager-E&Password=otrs123 Best Dave
,
Dec 2 2016
Notes from my debugging session - - The issue is that the submit button is not included as a field in the POST request body. - This probably happens because when you click on "Submit", you click on elements within the <button>, which breaks some code that adds <input type=hidden name=foo> where "foo" is the name of the target element of the submission button click, which is the <span> within it instead of <button, so the name is empty. - Firefox does not dispatch "click" to elements within <button>. See https://bugzilla.mozilla.org/show_bug.cgi?id=1089326 (this may change at some point and break you as well). - If you click on the border of the "Submit" button, the window closes.
,
Dec 3 2016
In case this is a new issue that only started since Chrome 54, it might be related to issue 196640 , however, I am still investigating whether this is the case.
,
Dec 3 2016
More notes - - I tried to remove that <input type="hidden" name=foo> addition and the bug still occurs. - I tried to remove the contents of the <button> and the bug does not occur anymore. The form is not submitted using the normal HTML form submission form (despite being triggered by a <button type=submit> click) - there is some validation (jQuery validation) process and then the form is submitted using form.submit() and the "submit" event returns false (prevents the default action, does not submit again). I looked at the HTML specification and it seems that the behavior compliant. It says (in my own words) - - When using the form.submit() method, the submitter element is the form itself - https://html.spec.whatwg.org/#the-form-element:concept-form-submit - Only if a <button> is the submitter, include it in the form-data (the data that is sent to the server upon submission) - https://html.spec.whatwg.org/#constructing-form-data-set Since form.submit() is used, the submitter is always the form, so <button> should never be included in the form-data. So this is basically a jQuery Validation issue, because it listens to the "click" event on elements the ":submit" jQuery selector (which selects <input type=submit> and <button type=submit>) selects. I submitted a pull request to jQuery Validation - https://github.com/jzaefferer/jquery-validation/pull/1901, but OTRS must update its plugin version (once it is released) in order to get the fix, or use a CSS workaround. Its GitHub organization disables the issue tracker, so I cannot file an issue. The CSS workaround would be - button[type="submit"] * { pointer-events: none; } A more localized and more performant CSS workaround would be - button[type="submit"] span { pointer-events: none; } By the way, pressing Enter on the various field (it is supposed to generate a synthetic "click" event on the submit button) does not fix the problem because there are numerous submit buttons and nothing makes the last one (the "Submit" button) get a synthetic "click" event. To summarize, I think this is a WontFix. Was this always a problem? Did it work in earlier versions of Chrome? If so, which version (or a period of time) did not have the issue that you can remember?
,
Dec 3 2016
The issue can be reproduced, so it is not uncomfirmed, however, it might not be a browser issue, but coding issue. rbyers@, tkent@ - seems related to issue crbug.com/519621 - what do you think? WontFix?
,
Dec 4 2016
Yeah, I think this is a dupe of Issue 519621 . phistuck@, thank you for the investigation.
,
Feb 17 2017
Note - my pull request was accepted by the jQuery Validation team (for now, anyway) - https://github.com/jquery-validation/jquery-validation/pull/1901 If you update jQuery Validation in OTRS (I do not know about its release frequency, though) to one that has my fix, it should resolve the issue. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by ajha@chromium.org
, Nov 30 2016