WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#26907 closed defect (bug) (fixed)

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

Reported by: GregRoss Owned by: azaozz
Milestone: 3.9 Priority: normal
Severity: normal Version: 3.9
Component: TinyMCE Keywords: needs-patch
Focuses: Cc:

Description

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.

Attachments (3)

26907.patch (6.6 KB) - added by GregRoss 6 years ago.
Patch to add better mouse move detection in DFW mode.
26907 V2.patch (6.6 KB) - added by GregRoss 6 years ago.
Minor update to previous patch to resolve inverted logic for the user preference.
Screen Shot 2014-03-28 at 1.34.17 PM.png (35.3 KB) - added by helen 5 years ago.

Download all attachments as: .zip

Change History (28)

#1 @lgladdy
6 years ago

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.

#2 @GregRoss
6 years ago

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

This ticket was mentioned in IRC in #wordpress-dev by lgladdy. View the logs.


6 years ago

#4 @azaozz
6 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed

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.

#5 @GregRoss
6 years ago

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.

#6 @nacin
6 years ago

  • Milestone set to 3.9
  • Resolution worksforme deleted
  • Status changed from closed to reopened

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

@GregRoss
6 years ago

Patch to add better mouse move detection in DFW mode.

#7 @GregRoss
6 years ago

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.
  1. 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.
  1. 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
6 years ago

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

#8 @samuelsidler
5 years ago

  • Keywords has-patch needs-testing added

This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.


5 years ago

#10 @nacin
5 years ago

  • Keywords needs-patch added; has-patch needs-testing removed
  • Owner set to azaozz
  • Status changed from reopened to assigned

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.

#11 @GregRoss
5 years ago

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.

#12 @azaozz
5 years ago

In 27806:

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

#13 follow-up: @azaozz
5 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

[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.

Last edited 5 years ago by azaozz (previous) (diff)

#14 in reply to: ↑ 13 @helen
5 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

#15 @GregRoss
5 years ago

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

#16 follow-up: @nacin
5 years ago

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.

#17 @nacin
5 years ago

  • Status changed from reopened to assigned

#18 in reply to: ↑ 16 ; follow-up: @azaozz
5 years ago

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.

#19 in reply to: ↑ 18 @GregRoss
5 years ago

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.

This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.


5 years ago

#21 @nacin
5 years ago

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.)

This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.


5 years ago

#23 @azaozz
5 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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

#24 @azaozz
5 years ago

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.

#25 @azaozz
5 years ago

In 28045:

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

Note: See TracTickets for help on using tickets.