search

observablehq / feedback

Customer submitted bugs and feature requests
42 stars 3 forks source link

editing toolbar broken on first cell before editing #280

Closed triptych closed 3 years ago

triptych commented 3 years ago

Describe the bug

The new integrated toolbar shows up on the right in a broken state when editing a brand new blank notebook. See screenshots below.

To Reproduce Steps to reproduce the behavior:

  1. go to observablehq.com
  2. create a new blank notebook
  3. focus cursor in first cell

Expected behavior Expect toolbar to be below the cell. Instead it's to the right in a weird broken state.

Screenshots Chrome:

chrome_De93fQDGFl

Firefox:

firefox_c2j6rfMtOu

Desktop (please complete the following information):

Additional context

I suspect that since I am using an all-in-one laptop with a touch screen whatever Observable is doing to detect for touch is interfering with the display. This is not caused by some plugin because the behavior happens even in incognito window.

Note: reloading the blank notebook does not change the behavior, but EDITING a cell and reloading will cause the toolbar to drop down and appear as it should. This only happens for the initial state before a cell is edited, and even then the page has to be reloaded ( probably changing the code decision path for the rendering ) before the right toolbar shows up

triptych commented 3 years ago

Here's a notebook that demonstrates the issue - I've never edited the initial cell so it stays in the "broken" state https://observablehq.com/@triptych/untitled/2

CobusT commented 3 years ago

Thanks for the bug report, and your great additional context. This is very likely a bug related to our detection of touch support.

mootari commented 3 years ago

This is very likely a bug related to our detection of touch support.

@CobusT I think these are distinct issues:

mbostock commented 3 years ago

This was a framework bug in server-side rendering and hydration, not in our application code. A fix will be released shortly.

CobusT commented 3 years ago

Should be ready to test!

triptych commented 3 years ago

What I see now: image

Which fixes the First time loading brokenness of the toolbar.

@mootari is correct that while the bar is rendering nicely now, it's still in the "inline" toolbar mode vs the "footer" toolbar of a non-touch device.

That could be a subject for another bug, but my initial issue posted for this bug is fixed.

mbostock commented 3 years ago

That’s currently the intended behavior, Andrew. We’ll let you know if we change it. 👍

mootari commented 3 years ago

That’s currently the intended behavior, Andrew. We’ll let you know if we change it. 👍

@mbostock I think there may be a misunderstanding here. From what I understand Andrew has a "normal" laptop with a touchpad and the ability to use a mouse. This laptop also has a touchscreen, but the touch screen is not the primary input method.

mbostock commented 3 years ago

That was my interpretation, @mootari. I similarly have an iPad with a physical keyboard that gets the inline toolbar treatment. We use touch support as a proxy for whether the device is likely to have a virtual onscreen keyboard rather than a physical keyboard. (And, to a lesser degree, to avoid iOS’s wonky position-fixed implementation when an input is focused.) As far as I’m aware, there’s no standard way of querying wether a device has a physical keyboard.

triptych commented 3 years ago

This is accurate. I have an HP Pavilion which is an 'all-in-one' with a touch screen. I'm ok with having both ( My mac laptop has the toolbar at the bottom ) . One possible option - could we override the "detection" and choose which version of the toolbar we want --> inline / footer as a configurable override?