Touch-enabled context menu: `Cut | Copy | Paste | ...`

Browser Support Web Compatibility
1

Hello, Brave community!

I am attempting to understand the behavior of the context menu generated by touch events on a touchscreen Thinkpad:

Touch_context-menu
Touch_context-menu794×367 34.9 KB

The issue is that the context menu, which pops up when text is selected is not clickable/touchable. The behavior is identical in Chromium, so this is obviously upstream and may have to do with click-emulation for touchscreens? I do not understand why this feature is half-implemented. Does anyone know how to entirely disable the popup menu and the little tabs to the left and right of the selection . . or better, how I may interact with them? I cannot inspect these elements, because as soon as the mouse/touchpad is used the context menu is removed.

I am working on a WYSIWYG editor, which publishes to IPFS and promoting Brave as the optimal browser for working with IPFS/IPNS content.

I absolutely love what the team has done to support IPFS! And all the amazing features you all have built! Amazing, incredible work. :clap: IPFS support is working beautifully!!!

Live demo available here.

2

@yarrow are you saying this is happening on all sites or content or only on IPFS/IPNS?

It would also help if you can try to provide more details. Such as:

  • What version of Brave you’re using

  • Which OS is on your Thinkpad? (Try to be specific, like if it’s Windows is it Windows 10 or 11)

3

I am using the latest version of Brave (Version 1.57.62 Chromium: 116.0.5845.180) on Ubuntu 22.04, on 6th Generation Lenovo Thinkpad X1 Carbon.

I don’t think this has anything to do with IPFS support, which has been working excellently.

I think this has to do with how touch events are being handled for a touchscreen by the Chromium core. Essentially, touching selected text in contenteditable element pops up a context menu which cannot be interacted with.

The behavior is identical when loading this from file:///home/user/test.html:

<!DOCTYPE html>
<html>
<head></head>
<body>
    <article contenteditable style="width: 100vw; height: 100vh;">
        Edit me.
    </article>
</body>
</html>

The behavior is identical on Chromium.

4

Also, I am not able to prevent the context menu. This does not work:

<script>
document.addEventListener('contextmenu', (e) => {
    console.log('contextmenu', e)
    e.preventDefault()
    e.stopPropagation()
})
</script>

While this does of course prevent this normal context menu displayed when right-clicking:

contextmenu

Both fire the 'contextmenu` event.

. . ahh, I found a solution at least to disable the menu:

<script>
const $article = document.querySelector('article')
$article.addEventListener('touchstart', (e) => {
    console.log('touchstart:', e)
    e.preventDefault()
})
</script>

That is the crux of it. I didn’t want a non-functioning menu popping up. Thanks for any other advice you can offer.

5

I’m trying to look for something similar but not really coming across anything specific. What I’ll do is tag @Mattches to see if he can point in the right direction.

That said, I would also suggest perhaps reaching out to Chromium team at the same time since you’re saying it seems to happen on chromium browsers as well. You can create an issue with chromium at https://bugs.chromium.org/p/chromium/issues/list

6

Yes, I will put it on the Chromium team’s radar.

I’m seeing now how I can step around the issue, so I’m all good, and I appreciate the feedback. Mostly I was trying to ascertain if there was something that I was missing; prefer to leverage as much default behavior as possible.

Submitted: https://bugs.chromium.org/p/chromium/issues/detail?id=1484206

Thanks for you help :pray:

7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.