Distraction Free Writing mode no longer wakes up on mouse move unless it is in the toolbar

[GregRoss]

In the upgrade to TinyMCE 4 it looks like DFW mode no longer makes the toolbar and other chrome elements visible on a mouse move unless the mouse is moved within the toolbar area.

[lgladdy]

This feels like a good behaviour to have anyway, so maybe it's intentional - @azaozz will know that for sure though.

This way you can easily click around and reposition text without being distracted by the boxes and animation - and only move up to the top menu bar when you change it - though maybe there should be a tooltip to explain this to users who are used to the old way.

[GregRoss]

Or a way to control which behaviour is in effect. Some users may like the old way better.

[azaozz]

This feels like a good behaviour to have...

Yes, think so too. Makes it more consistent and somewhat work on touch devices (better on Android than iOS).

Also, before the toolbar was display: none and was shown on mouse move in the top 1/3 of the screen (which was buggy sometimes). Now the toolbar is visibility: hidden and is shown on mouseenter.

[GregRoss]

For touch devices I would think you would want the opposite, to have it wake up at any touch of the window (if the onscreen keyboard isn't part of the browser window obviously). Having to hit the toolbar at the top of the screen without any visual clue as to where it is would be harder for users.

As long as it was intended though that's fine.

[nacin]

I think making an adjustment for touch devices is a good idea. Let's study it.

[GregRoss]

Patch to add better mouse move detection in DFW mode.

[GregRoss]

I've attached a patch that does three things:

1. Brings back the old behaviour of 'waking' up DFW mode when the mouse is moved, but extending it to the entire screen (both the main doc and the TinyMCE iframe). This will also capture browsers that don't execute proper touch events but instead translate them to mousemove events.

2. Add touchstart/end event handlers (though not on the iframe, could probably be extended to it) to show the toolbar on start and hide it on end.

3. Added a profile option to disable the above two behaviours and only 'wake up' the toolbar when the mouse moves in to it.

For your consideration... ;)

[GregRoss]

Minor update to previous patch to resolve inverted logic for the user preference.

[nacin]

azaozz is working on a patch to show the toolbar on touch.

Also, a user preference isn't really helpful in this case, and I don't think we'd like to bring back the old mouse-move thing, as it was a bit too sensitive.

[GregRoss]

Sensitivity of the mouse move could of course be adjusted, but I think it makes sense to show the toolbar on a mouse move as from a distraction free standpoint, once you reached over to the mouse you have effectively left DFW.

Before I looked at the code, I assumed the new behaviour was a bug and it wasn't readily apparent you had to move the mouse in to the toolbar.

A plugin could do this function as well but it's tricky and prone to breakage between versions.

[azaozz]

In 27806:

Make DFW usable on touch devices: change the toolbar to two rows and keep it and borders visible. See #26907

[azaozz]

[27806] also makes it quite easy to add back "show on mousemove", only need to throttle down the events and call wp.editor.fullscreen.toggleUI('autohide');.

This should be done. Feel free to reopen if the responsive styles need adjustment.

[helen]

Replying to azaozz:

Feel free to reopen if the responsive styles need adjustment.

Pretty bad at the 320px wide size that's pretty common in phones. See screenshot above.

[GregRoss]

The update just converts DFW mode on touch devices to fullscreen mode (aka UI is visible all the time), is that the desired behaviour?

[nacin]

Another issue:

• Now that the mouse no longer wakes up DFW, it's nearly impossible to see the word count. Especially if you have a long post — the word count is stuck to the very bottom of the editor, not to the bottom of the screen.

[azaozz]

Replying to GregRoss:

The update just converts DFW mode on touch devices to fullscreen mode (aka UI is visible all the time), is that the desired behaviour?

As iOS "locks" all position: fixed elements when the keyboard is open, this is the most straightforward way to make DFW usable there. It's not ideal, but other fixes (resetting the fixed elements on scroll?) would require bigger changes, more code, etc. Something for 4.0 perhaps.

Replying to nacin:

Now that the mouse no longer wakes up DFW, it's nearly impossible to see the word count.

Tested moving the word count and "Just Write" to the top, but its not better. When the user is typing it is usually at the bottom and the top can be hidden. We can return showing the toolbar/UI on mouse move if that is the better UX.

[GregRoss]

Replying to azaozz:

Replying to GregRoss:

The update just converts DFW mode on touch devices to fullscreen mode (aka UI is visible all the time), is that the desired behaviour?

As iOS "locks" all position: fixed elements when the keyboard is open, this is the most straightforward way to make DFW usable there. It's not ideal, but other fixes (resetting the fixed elements on scroll?) would require bigger changes, more code, etc. Something for 4.0 perhaps.

iOS is just one case that needs to be looked at, both Windows and Android support touch devices. I think the old behaviour makes more sense as it maintains the idea of DFW and doesn't show the toolbar and chrome until the user does something other than tying. My patch watched for touch events to wake up the display which should work across any browser that supports touch devices. But the other part of the patch which brings back the wakeup on mouse move also works for touch devices which don't support touch events as they all mimic mouse movements.

Replying to nacin:

Now that the mouse no longer wakes up DFW, it's nearly impossible to see the word count.

Tested moving the word count and "Just Write" to the top, but its not better. When the user is typing it is usually at the bottom and the top can be hidden. We can return showing the toolbar/UI on mouse move if that is the better UX.

I found the word count usually appears well below the visible area of the browser window now so scroll is always required.

Perhaps creating a second "toolbar" pinned to the bottom of the screen would make sense.

[nacin]

Per IRC: We're going to try to fix the word count to the bottom of the screen to appear when you hover. (Only when you hover the top toolbar, though — hovering near the bottom won't display it.)

[azaozz]

In 28043:

DFW:

• Move the word count and "Just Write" to a fixed bar at the bottom.
• Fix responsive mode to 480px. Narrower screens will have a scroll bar.
• Hide the Help button on screens < 480px, move the Save button to the right, make it bigger to match the others, and other responsive mode fixes.

Fixes #26907, see #27709

[azaozz]

This ticket was originally for bringing back the "show UI on mouse move" behavior but we started fixing other DFW issues here. Lets continue in #27709.

[azaozz]

In 28045:

Precommit cleanup for theme.js, editor.css amd wpdialogs/plugin.js, See #27055, #26907, #16284