New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 668524 link

Starred by 3 users

Issue metadata

Status: Duplicate
Merged: issue 519621
Owner: ----
Closed: Dec 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug



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.

 

Comment 1 by ajha@chromium.org, Nov 30 2016

Labels: M-57
Labelling with current canary milestone for triaging.

Comment 2 by phistuck@gmail.com, Nov 30 2016

When I go to the URL you mentioned, I get a login screen. What are the credentials?
Cc: hdodda@chromium.org
Labels: Needs-Feedback
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!
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

Comment 5 by phistuck@gmail.com, 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.

Comment 6 by phistuck@gmail.com, 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.

Comment 7 by phistuck@gmail.com, 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?
Cc: tkent@chromium.org rbyers@chromium.org
Components: Blink>HitTesting Blink>Forms>Button
Labels: OS-Windows
Status: Untriaged (was: Unconfirmed)
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?

Comment 9 by tkent@chromium.org, Dec 4 2016

Mergedinto: 519621
Status: Duplicate (was: Untriaged)
Yeah, I think this is a dupe of  Issue 519621 .  phistuck@, thank you for the investigation.

Comment 10 by phistuck@gmail.com, 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