Can’t draw anything without setting touch-action

[chris-morgan]

I just tried this out, cargo build --release --features http, and found input broken: I couldn’t draw anything with mouse, touch or pen.

Upon adding the CSS touch-action: none to the canvas, it worked properly in Chrome (though sadly that stops touch scrolling from working, and there’s currently no solution for this (!), per w3c/pointerevents#203). Firefox still wouldn’t draw with the pen, and drew spindly little lines with the mouse.

Windows 10, Surface Book.

[Logicalshift]

There's quite a lot of subtle variability between browsers regarding pointer events - which I'm hoping will work themselves out over time. Firefox (and Safari) reports the mouse as having 0 pressure and Chrome reports it as having 1 - this is what makes the lines show up as very thin in Firefox. I'm planning to detect this and set pressure based on pointer velocity at some point in the future, so it's a bit of a glitch for now.

I mainly use Chrome on OS X for testing, but I do have acess to a Windows laptop with a N-Trig digitizer that should be fairly close to your Surface Book in behaviour. I've misplaced the pen, which means I can't test that until I get a new one. On my system, using the mouse alone worked, as did using touch to scroll around.

I did briefly see behaviour that looked as you described: all input rejected. I'm going to have to wait until I get my replacement pen to be sure but I think it looked like an issue with palm rejection leaving something in a broken state - if that's the case it might also work for you in Chrome if you use only the mouse from the start.

One other question - was it the case that only the drawing actions were broken? Ie, could you select tools and click on the buttons in the timeline? paint.js where the drawing actions are all defined is meant to let through actions from the touch device so scrolling works as normal on a touch screen, and the behaviour you describe could be down to that part of the code malfunctioning somehow.

[chris-morgan]

Firefox (and Safari) reports the mouse as having 0 pressure and Chrome reports it as having 1 - this is what makes the lines show up as very thin in Firefox.

Hmm? The spec says:

For hardware and platforms that do not support pressure, the value MUST be 0.5 when in the active buttons state and 0 otherwise.

And this matches what I’ve seen every time I’ve dealt with pointer events.

---

It was only drawing actions that were broken. I could interact with other controls successfully.

[Logicalshift]

No processing is done on the pressure information, so thin lines do indicate that it's either 0 or very low. FlowBetween doesn't just support pointer events, though they are the default. If the browser doesn't support them, FlowBetween will fall back to touch events then to mouse events.

There's some debugging you can do to see what events are being generated: firstly, in the console you can run show_notes() to see the verbose logs. The first message should be ==> Will use pointer events for painting (modern browser) if FlowBetween is wiring up pointer events - which it should do if they're available.

In Safari on OS X: it's definitely using pointer events, and the pressure is definitely not coming out as 0.5 when drawing with the mouse, or a graphics tablet: here's an extract from the raw event:

[Log] PointerEvent (paint.js, line 121)
altKey: false
...
offsetX: 514
offsetY: 133
pageX: 494
pageY: 158
pointerId: 1
pointerType: "mouse"
pressure: 0
relatedTarget: null
returnValue: false
...
PointerEvent Prototype

So I'm thinking it's not compliant with the spec here. Both Firefox and Chrome are properly reporting pressure via pointer events on OS X with a tablet, but Firefox also reports pressure 0 when using a mouse (on OS X and Windows).

You can view updates from the server side with show_update_events(): this will show you if FlowBetween is trying to draw to the canvas when you try to draw anything. I've just pushed a change that adds show_server_requests() to show what's being sent the other way: one thing I'm wondering is it might be starting the paint action and then cancelling it (you can also dig down and see the pressure being reported here - note that it's the same value as is in the pressure field for the pointer event).

[Logicalshift]

My replacement pen for my N-trig display has arrived. My suspicion was partially correct: what's happening is the pointer event for painting is starting, continuing for a while and is then being cancelled. It's sometimes possible to see the brush stroke starting, but it seems the browser (or maybe Windows?) decides that it's supposed to scroll the window instead and cancels the previous action.

I suspect there's an event I can call preventDefault on to stop this from happening, but I'm not sure what that would be at the moment.

My thought was that it starts as a touch event which is then cancelled due to palm rejection, but this sequence happens regardless of if I lay my hand on the screen. I think this might be a change to previous behaviour as I have had this working in Windows in the past.

[Logicalshift]

I believe the latest version partially fixes this issue: I think I want the canvas to scroll on touch and not draw but this is not the current behaviour.

I've done some research and found that some people reported that capturing the touch start event was the way to go to fix this issue.

Unfortunately this really only confirms my suspicions that this once worked as this code is already present:

        // If touch events are also supported, disable them for this control so gestures are disabled
        if (supports_touch_events) {
            // Touch & pointer events fight each other :-(
            add_action_event(node, 'touchstart', ev => ev.preventDefault(), false);
        }

What has changed is that Chrome is no longer supplying ontouchstart in window, which is how the supports_touch_events flag gets set. I've made a couple of modifications here: firstly to just assume touch events are supported (as apparently they still are), and secondly I've added a check so that the touch event is not suppressed if the pointer is not captured - which should be what's needed to make scrolling via touch work.

[Logicalshift]

One last fix: I've stopped painting on touch events (combined with the capture check this makes scrolling on touch work)

[zicklag]

I'm getting the same no-input issue on Chromium on Linux ( with a mouse ). Latest commit off of master: 8bcf2a7. Also when running GTK I can't click any buttons, but I can curiously click the little check-mark on the image history list.

Very cool looking tool by the way! 😃

[Logicalshift]

The GTK bug has me deeply mystified at the moment: it only happens when the keyboard layout is set to something other than US.

Chromium is working for me, though on Linux it doesn't pass through pressure information: it's not impossible that there's still a problem, but it's also possible you've hit another bug, which is that FlowBetween isn't creating a default layer at the moment, which also disables the drawing actions. Clicking the '+' icon above the timeline will add a layer if that's the problem (it's supposed to add a new layer by default but the code to do so got lost in a redesign of the storage subsystem)

[zicklag]

Clicking the '+' icon above the timeline will add a layer if that's the problem (it's supposed to add a new layer by default but the code to do so got lost in a redesign of the storage subsystem)

Ah, that worked for Chrome, thanks. :)

I really like this idea of an SVG painting and animation tool. It's pretty neat.

---

The GTK bug has me deeply mystified at the moment: it only happens when the keyboard layout is set to something other than US.

Interestingly I have my keyboard set to US, but I did notice an error in the console and it actually can work for just a second before it hits that error and then completely freezes.

thread '<unnamed>' panicked at 'Enabling options: Unexpected OpenGL errors: [UnknownError(1282)]', render/src/gl_renderer/error.rs:19:9
stack backtrace:
   0: rust_begin_unwind
             at /rustc/de521cbb303c08febd9fa3755caccd4f3e491ea3/library/std/src/panicking.rs:475
   1: std::panicking::begin_panic_fmt
             at /rustc/de521cbb303c08febd9fa3755caccd4f3e491ea3/library/std/src/panicking.rs:429
   2: flo_render::gl_renderer::error::panic_on_gl_error
   3: flo_render::gl_renderer::renderer::GlRenderer::render
   4: std::thread::local::LocalKey<T>::with
   5: futures_executor::local_pool::block_on
   6: <O as gtk::auto::gl_area::GLAreaExt>::connect_render::render_trampoline
   7: <unknown>
   8: <unknown>
   9: g_signal_emit_valist
  10: g_signal_emit
  11: <unknown>
  12: <unknown>
  13: gtk_container_propagate_draw
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: gtk_container_propagate_draw
  18: <unknown>
  19: <unknown>
  20: <unknown>
  21: gtk_container_propagate_draw
  22: <unknown>
  23: <unknown>
  24: <unknown>
  25: <unknown>
  26: <unknown>
  27: <unknown>
  28: gtk_container_propagate_draw
  29: <unknown>
  30: <unknown>
  31: gtk_container_propagate_draw
  32: <unknown>
  33: <unknown>
  34: gtk_container_propagate_draw
  35: <unknown>
  36: <unknown>
  37: gtk_container_propagate_draw
  38: <unknown>
  39: <unknown>
  40: gtk_container_propagate_draw
  41: <unknown>
  42: <unknown>
  43: <unknown>
  44: gtk_container_propagate_draw
  45: <unknown>
  46: <unknown>
  47: <unknown>
  48: gtk_container_propagate_draw
  49: <unknown>
  50: <unknown>
  51: <unknown>
  52: <unknown>
  53: gtk_main_do_event
  54: <unknown>
  55: <unknown>
  56: <unknown>
  57: <unknown>
  58: <unknown>
  59: g_signal_emit_valist
  60: g_signal_emit
  61: <unknown>
  62: <unknown>
  63: <unknown>
  64: g_main_context_dispatch
  65: <unknown>
  66: g_main_loop_run
  67: gtk_main