sciter-js-sdk icon indicating copy to clipboard operation
sciter-js-sdk copied to clipboard

Problems with click events

Open jsprog opened this issue 4 years ago • 4 comments

LMDE4 and Windows 7:

  • click isn't generated for many elements (tested to fail with div, span, input[type=text], and input[type=password].
  • dblclick is generated after the second mousedown, not after the second mouseup.
  • contextmenu is generated after mouseup, not after mousedown (Not sure if this what's planned for sciter).

LMDE4:

  • contextmenu is generated twice.
  • The third mousedown for triple click is generated twice (div, span, button, checkbox, radio)

Windows 7:

  • The third mouseup for triple click is generated twice (input[type=text], input[type=password])
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>issue: problems with click events</title>

    <style>
        button, div, span {
            position: relative;
            display: inline-block;
            padding: 20px;
            background-color: #ccc;
        }
    </style>
</head>
<body>
    <!-- un-comment exactly one target for testing -->

    <div id="target">target</div>
    <!-- <span id="target">target</span> -->
    <!-- <input id="target" type="text"> -->
    <!-- <input id="target" type="password"> -->

    <!-- <button id="target">target</button> -->
    <!-- <input id="target" type="radio"> -->
    <!-- <input id="target" type="checkbox"> -->
    
    <script>
        const target = document.querySelector('#target')

        // click event isn't generated for many elements
        //     tested to fail with div, span, input[type=text], input[type=password]
        target.addEventListener('click', () => { console.log('target: click') })

        // dblclick is generated after the second mouse down,
        //     not after the second mouseup
        target.addEventListener('dblclick', () => { console.log('target: dblclick') })
        
        // contextmenu event is generated twice (linux) after mouseup (win + linux),
        //     not once after mousedown (not sure if this what's planned for sciter)
        target.addEventListener('contextmenu', (evt) => { console.log('target: contextmenu'); evt.preventDefault(); })

        target.addEventListener('mousedown', () => { console.log('target: mousedown') })
        target.addEventListener('mouseup', () => { console.log('target: mouseup') })
        target.addEventListener('mouseenter', () => { console.log('target: mouseenter') })
        target.addEventListener('mouseleave', () => { console.log('target: mouseleave') })
    </script>
</body>
</html>

jsprog avatar Dec 02 '20 23:12 jsprog

As of doubleclick events, Sciter uses desktop UI convention.

For example Windows:

WM_LBUTTONDBLCLK .. the system generates whenever the user presses, releases, and again presses the left mouse button within the system's double-click time limit. Double-clicking the left mouse button actually generates a sequence of four messages: WM_LBUTTONDOWN, WM_LBUTTONUP, WM_LBUTTONDBLCLK, and WM_LBUTTONUP.

As you see double click comes before second WM_LBUTTONUP - in place of second WM_LBUTTONDOWN.

As of clicks... That's quite strange entity to be honest. Nobody knows what the click really means.

Button click event makes sense, yes. Button click is either pair of mousedown/up or SPACE/ENTER key press.

But what does click mean on input[type=text] ? Do you want focus event, mousedown or selection change events instead? What is the purpose of handling click event in text editor? What exactly you want to catch?

Historically Sciter generates clicks on buttons or other elements that explicitly declare "clickability".

Two behaviors are used for that (applied through CSS): behavior:button - element is a) focusable and b) generates click events - behaves as a button precisely. It could be any otherwise passive element - div, span, li, etc. Another is behavior:clickable - that is non-focusable clickable element. <button> inside <toolbar> has behavior:clickable instead of behavior:button. In desktop UI systems elements of toolbars and menus are non-focusable but generate click events.

Check this:

<html>
    <head>
        <title>Test</title>
        <style>
div { behavior:clickable; }
        </style>
        <script>

//document.on("click", "div", function() {
//  Window.modal(<info>Got click</info>);
//});

document.$("div").on("click", function() {
  Window.modal(<info>Got click</info>);
});
        </script>
    </head>
    <body>

      <div>click me</div>

    </body>
</html>

It is possible to emulate "dumb clickability" in browser-compatibility.js, not so sure if anyone needs that. Usually handling click events on non-buttons is a plain design mistake in Web UIs. People forget about keyboard completely.

c-smile avatar Dec 04 '20 03:12 c-smile

contextmenu event is usually generated by underlying OS as it has special means to generate it.

On Windows WM_CONTEXTMENU is generated by either right or left mouse clicks (subject of user preferences) and by keyaboard - there is special key for that - on the left of right CTRL.

c-smile avatar Dec 04 '20 03:12 c-smile

Thank you for the detailed information.

As of doubleclick events, Sciter uses desktop UI convention.

I could confirm about this.

As of clicks... That's quite strange entity to be honest. Nobody knows what the click really means.

I agree with you about this, but I was forced to use div containers when creating my components for some reasons:

  • I couldn't override the background color for non disabled buttons https://github.com/c-smile/sciter-js-sdk/issues/24#issuecomment-735447032.
  • CSS Box Model for button is behaving differently from others. I won't say too much about this until I spend extra time to understand the problems very well.

But what does click mean on input[type=text] ? Do you want focus event, mousedown or selection change events instead? What is the purpose of handling click event in text editor? What exactly you want to catch?

Currently, I don't have a use case for clicks on text fields.

contextmenu event is usually generated by underlying OS as it has special means to generate it.

Not the case for LMDE4. After mouseup or mousedown won't hurt at all for contextmenu, and I think that I shouldn't mentioned this from the start.

jsprog avatar Dec 04 '20 22:12 jsprog

Some of the remaining problems are keeping me away from closing this issue.

After my last tests with version 4.4.7.2, Windows 7 isn't affected anymore, but LMDE4 is still affected:

  1. contextmenu event is triggered twice
  2. The third mousedown for triple click is triggered twice (div, span, button, checkbox, radio)

jsprog avatar Apr 28 '21 00:04 jsprog