Event propagation on sap.m.DatePicker not bubbling to container

[Tukutupap]

OpenUI5 version:
Looks like all releases are affected

Browser/version (+device/version):
Chrome 116+
Firefox 116+
Edge 116+

Any other tested browsers/devices(OK/FAIL):
N/A

URL (minimal example if possible):
https://jsbin.com/bunebu/edit?html,output

Steps to reproduce the problem:

Go to the link and click "run with JS" if the project doesnt render.
Click the disabled input and see how the counter does not go up.
What is the expected result?
Event should be bubbled up and counter should go up.

What happens instead?
Nothing happens.

Any other information? (attach screenshot if possible):
I have also tested this with sap.m.Select and sap.m.Combobox and got the same results.
This used to be a Firefox 61+ only issue, I reported this back in 2019 (#2554), however this is an issue that affects all browsers now.
This bug is in reference to #2192 and I do apologize in advance if this turns out to be the same thing, I just wanted to make sure you guys are aware that this is not only happening the first time you focus the element, but every single time if the element happens to be disabled. 2192 is closed and im not sure if anybody is following there.
Feel free to close if this is the same issue.
Thanks so much in advance!

[kineticjs]

Hi @Tukutupap,

Thank you very much for the sample and the analysis.

Looks like the issue is browser dependent. I reproduce the issue with FF/Edge 116, while with Chrome 114.0.5735.110 the "click" event on a disabled input still bubbles up.

Modified JSbin to use native APIs only: https://jsbin.com/qiyuboqike/edit?html,output

The attachBrowserEvent listens on the input's wrapper, this is why its listener was notified with Chrome 114.

Given the behavior is native, not sure what we can do about it.
Did you have some specific workaround at mind [or rather suggested that it could be a UI5-specific issue]?

Thanks!
Diana

[Tukutupap]

Thanks Diana,

This has been going on for a long time in Firefox, but is fairly recent for Edge and Chrome, these are the ones I normally deal with but I'm sure there are others affected.

The example I provided is very simple, but there are other situations that are more common. For example, if you render a date picker within a table row to show a date and the date picker is disabled, if you want to click on the row - to display more details for example - and you click on the date picker the click event will not be accessible to the row so rowSelectionChange would never be triggered.

At the moment my way around this has been to attachBrowserEvent('click') to all the controls I render within my table rows and make them enabled/noneditable so that the click event gets to the table, but this is more of a patch than a real solution.

I understand the behaviour is native, I just thought of opening an Issue and get your take on it.

Thank you!

[DonkeyCo]

Hi @Tukutupap,

according to the HTML specification, disabled form controls should not fire a click event.

"A form control that is disabled must prevent any click events that are queued on the user interaction task source from being dispatched on the element."

As the form control does not fire an event, no event is bubbling up. That should be the default in browsers implementing the spec. There was quite a big discussion regarding this behaviour in Chrome, but it seems like the sentiment is that no event firing and bubbling is the ideal case: whatwg/html#5886.

I understand your issue at hand though and it seems like your workaround seems to work fine for you. Another approach would be to use pointer-events: none, when dealing with disabled controls inside of a wrapper control. This would disable pointer events on the input field completely, making it possible to receive pointer-events from the wrapper.
I've created an example here: https://jsbin.com/binukidudu/1/edit?html,output.
Be careful though, using pointer-events: none also disables text selection. Not sure if this may impose a problem for you.

I don't think introducing such a workaround is viable in UI5 in general (m.Table, m.Page, etc.), as this could interfere with text-selection and other pointer events.

I hope this provides a bit more information!

Thanks!
Duc

PS: This is quite the interesting topic. If you are interested in why this worked in Chrome for a while you can read it here: whatwg/html#5886 (comment)

[Tukutupap]

Thank you @DonkeyCo for putting all this info together, this has been very helpful.