kleki.com - see bug description

[webcompat-bot]

URL: https://kleki.com/

Browser / Version: Firefox 99.0 Operating System: Windows 10 Tested Another Browser: Yes Edge

Problem type: Something else Description: Drawing tool doesn't react to (touchscreen) pen pressure properly Steps to Reproduce: Drawing using the touchscreen Pen doesn't work as well as in Chrome/Edge, all lines have the constant width, not varied based on pen pressure sensitivity.

View the screenshot


Browser Configuration

• gfx.webrender.all: true
• gfx.webrender.blob-images: true
• gfx.webrender.enabled: true
• image.mem.shared: true
• buildID: 20220218090822
• channel: nightly
• hasTouchScreen: true
• mixed active content blocked: false
• mixed passive content blocked: false
• tracking content blocked: false

View console log messages

From webcompat.com with ❤️

[zombie]

I posted this, wasn't logged into github in Nightly, didn't know it will go into a moderation queue.

[dholbert]

I haven't actually debugged the site, but I'd guess they are (or should be) using https://developer.mozilla.org/en-US/docs/Web/API/Touch/force to detect the pressure.

And that page says this feature was removed (for Windows) https://bugzilla.mozilla.org/show_bug.cgi?id=888304, which is true, though it was reenabled later in https://bugzilla.mozilla.org/show_bug.cgi?id=1180706#c6 ( https://hg.mozilla.org/mozilla-central/rev/1056404c052e#l1.13 ) and is currently in "autodetect" form on Windows: https://searchfox.org/mozilla-central/rev/e580b1098c1f012880368989f6e386812fe6ccc6/modules/libpref/init/StaticPrefList.yaml#4061-4072

I suppose it's possible the autodetect mechanism is broken; @zombie, would you mind setting about:config pref dom.w3c_touch_events.enabled to 1 (i.e. "enabled") and seeing if that changes your behavior at all?

(might require a browser restart, I'm not sure)

[saschanaz]

I did some debugging and I think they are using https://developer.mozilla.org/en-US/docs/Web/API/PointerEvent/pressure, as there were lines using it at least. But not 100% sure as I couldn't find the cause.

[dholbert]

CC @theres-waldo (Botond) who might be interested here as well, since I think he's done some work (or code-review at least) that's associated with our touch-event handling.

[saschanaz]

Did a quick test with addEventListener("touchstart", console.log). It shows correct Touch.force value whereas the website is still broken.

[zombie]

I suppose it's possible the autodetect mechanism is broken; @zombie, would you mind setting about:config pref dom.w3c_touch_events.enabled to 1 (i.e. "enabled") and seeing if that changes your behavior at all?

Doesn't make a difference for kleki.com.

I also did a quick smoke-test for both Touch (.force) and Pointer (.pressure) events, and they both work with dom.w3c_touch_events.enabled set to either 1 or 2.

[theres-waldo]

Yeah, I expect the behaviour on a touchscreen would be worse in more ways than this if we failed to detect touch event support altogether.

If the browser is successfully sending pointer events with pressure values that vary with the pen pressure, I think the next step would be to investigate the page's JS further, to see what it does with those pressure values. Possibly there's a check there that causes it to go down a different codepath (that maybe ignores the pressure) for Firefox.

[softvision-raul-bucata]

@karlcow Do we have someone on the team that might have a similar device that has a touch pen? My guess is that the issue occurred on a Windows Surface device. @zombie Is that correct?

{inv_09/2022]

[zombie]

No, I'm using a Lenovo Yoga 9i, but any device with a pressure-sensitive pen should behave similarly, including a Surface.

[saschanaz]

It also occurs on Surface Pro 7 with Windows 11, yes.

[karlcow]

It is listening to pointer* and pointer.pressure in https://kleki.com/app/index.967ae276.js but I do not have a device allowing me to test this. I use the mac and rdm and activate touch events, and in this scenario: pressure = 1

It activates the menu on detection of pointerevents. but without a specific device this is hard to debug.

[dholbert]

FWIW I have a Surface 3 with a pen, and I can reproduce this behavior-difference on it (tested in Windows 10 as well as on Ubuntu 21.10 -- the site responds to pen-pressure in Chrome but not in Firefox Nightly, in both operating systems.)

I tried spoofing Chrome's UA string from Firefox, and that didn't help.

I then used devtools logging (right-click line of pretty-printed JS source, "Add Log") to log the value of t.pressure on the pretty-printed source line t.corrected=n (which is conveniently a unique statement that only occurs once in the source file https://kleki.com/app/index.967ae276.js). This line is just after the page has read the .pressure member and copied it into another variable.

Good news: I can confirm that I see similar values there in Firefox and Chrome -- t.pressure is 0 when I "hover", and then when I draw on the screen, it ranges up to be close to 0.5 (in both Firefox and Chrome) if I'm pressing firmly; and I see all sorts of fractional values between 0 and 0.5. So: at least for that particular API, we seem to support it and be providing similar results to what Chrome is providing.

[dholbert]

After poking into the site's help section, it looks like @bitbof is the author of this site (and it's open-source at https://github.com/bitbof/klecks ).

Hi @bitbof, I wonder if you could help us investigate what's going wrong here? As noted in comments above, it seems kleki doesn't respond to variable pen pressure in Firefox, even though we seem to be correctly reporting variable pressure values up to the site's JS (according to my devtools logging as referenced in my comment above).

Presumably Kleki's logic is taking a different turn in Firefox vs. Chrome for some reason (starting with variable pressure readings in both browsers, but discarding them at some point in Firefox and using a constant thickness). I wonder if you could help us figure out where that's happening & whether that's possible to fix. Thanks!

[dholbert]

One clue: I searched the source at https://github.com/bitbof/klecks/ for firefox and found this piece:

                if (isFirefox) {
                    correctedObj.pressure = 1;
                    customPressure = 1;

https://github.com/bitbof/klecks/blob/d12513860bd89fe84db3c21f630b28cb2972c876/src/app/script/bb/input/pointer-listener.ts#L371-L373

...where isFirefox is based on User Agent sniffing:

navigator.userAgent.toLowerCase().indexOf('firefox') > -1;

https://github.com/bitbof/klecks/blob/a87f8bc72e360d209d549451d05bd65032d4d83f/src/app/script/bb/base/browser.ts#L3

However, I'm guessing that's not the precise issue we're seeing on the live site (or it's not the whole story), because I'm not seeing any difference in live-site-behavior if I change my user agent string. (It's hard for me to see if that code exists somewhere on the live site, too, since the live site has different/minified naming for a lot of things.)

[karlcow]

Thanks @dholbert I filed https://github.com/bitbof/klecks/issues/4

[saschanaz]

The fix is now online: https://github.com/bitbof/klecks/commit/aebb515c6180801cfedae8af230ca7850fda0cc0

I confirm that it indeed works now.

[karlcow]

Thanks! Everyone. good team work