Thanks for filing the issue!

From comment#0, it is clear that the issue seems to be a feature request rather than a bug, hence marking it as Untriaged and requesting someone from respective team to have a look into this issue and help in further triaging it.
Note: Tentatively adding component "Blink>Input", please change if this isn't apt.

I don't want to mark this as triaged yet as I didn't fully understand the use case and the experience you want to provide to the user.

I assume that user might have all forms of the inputs and you should behave accordingly for each type of the input regardless of which one is connected to the computer. So if you get mouse events (or pointerevents with type mouse) you should do your behavior with respect to mouse events. The same goes for touch events.
Even the compat click events coming touch events have a property showing that they are not from the mouse. So that confusion can get resolved.

Repoter, can you elaborate a little more on the webpage you have in mind?

The user might use mouse, or might use touch.
As far as current information provided by the browser goes, the script doesn't have any idea what the user is using or what can he use.

The use case I have is a calendar with reservations. The user can reserve some days in that calendar. With mouse he can click and drag through days to have them reserved. With touch (currently detected by 'mobile' user agent) he must tap on the beginning and then on end of reservation, while swiping is used for scrolling through the calendar. 


The mouse event object provides in chrome "sourceCapabilities" property that tells about capabilities of the device being used, though that information would be more useful before the click event actually fired, because it has no relation to that particular event but is rather an indication of overall capabilities.

As far as i know, there does not exist any property indicative of input device being used, I tested click events fired through touch and mouse and found no differences. I found out, that firefox provides 'mozInputSource' which is the property I would like, there is no similar property in Chrome.

The only workaround that I know of is to attach handler to touch events and use 'preventDefault' to avoid firing mouse click events. This is a workaround, but not too nice, because it will prevent much more than just mouse events.
If I would preventDefault on touch event in my calendar, I would block the scroll function. I would rather have the ability to not attach any click listener beforehand, but the script has no information to be able to do that.

I would rather have that sourceCapabilities information in the window.navigator object, than in mouse event object. Then I would have the possibility to set up all my events beforehand. Once the event is fired, the capabilities information comes too late to be of any use.

In the event object, I would like to have something like 'mozInputSource' from firefox.

> I would rather have that sourceCapabilities information in the window.navigator object, than in mouse event object. Then I would have the possibility to set up all my events beforehand. Once the event is fired, the capabilities information comes too late to be of any use.

Regarding this point, that is not the correct assumption. Just because user has touch screen you cannot ignore all the clicks. Because they might also have mouse and then when they interact with your page with mouse you should respond to the click. Right?

> As far as i know, there does not exist any property indicative of input device being used, I tested click events fired through touch and mouse and found no differences. I found out, that firefox provides 'mozInputSource' which is the property I would like, there is no similar property in Chrome.
> In the event object, I would like to have something like 'mozInputSource' from firefox.
I don't think this is not correct. The sourceCapabilities that you mentioned does have firesTouchEvents property and it is also populated for the click events (from mouse and from touch). Could you double check this? Does click having that property resolve the issue?

Aside from all this, would pointerevents be any help? it has a property called pointerType which could be mouse/touch/pen and maybe more in the future.

Reporter feel free to continue discussion here. I'll leave this as P3 as it doesn't seem that we immediately need such an API to address a usecase that is not addressable today by the current APIs.

I was not aware of pointerevents.
Now i see, this issue is pointless, I am sorry for disturbing you.