#17503 closed defect (bug) (fixed)
Make DFW mouse movement behavior consistent
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Milestone: | 3.2 | Priority: | normal |
| Severity: | major | Version: | 3.2 |
| Component: | Editor | Keywords: | |
| Focuses: | Cc: |
Description
In HTML mode:
- On any mouse movement, DFW fades in.
- This can be jumpy and distracting.
In visual mode:
- On any mouse movement outside of the content area, DFW fades in.
- When you have content and are scrolled down (thus content area is 100% height), you need to do a jig with your mouse, outside of the content area then back over to hit one of the buttons.
We need to come up with a middle ground on these behaviors. Both of them are largely untenable, and the inconsistency is also a poor experience.
It will not be easy to change the visual mode behavior since we're in an iframe there, but azaozz says there's a way.
I'm thinking we only fade it in when the mouse movements are near the top of the document -- I'd suggest perhaps 1.5 times the height of the header, in a manner so it's faded in by the time you get to one of the buttons.
This is better than we have now in the HTML editor -- it'd still fade in at occasionally undesired times, but most of the time it would be desired. If you're working in a document that is scrolled down, chances are you're working in the bottom 50% of the window anyway.
And it would be better than we have now in the visual editor -- it'd actually fade in when you want it, because right now it feels very unnatural.
Change History (5)
#2
follow-up:
↓ 3
@
13 years ago
I don't want it limited to top of screen, breaks flow if scrolling page. I think any movement should trigger.
There have been some reports via wordpress.com testers that the icons are getting covered up by admin bar. Should check that as well.
Sounds good, hopefully we will have time to do this properly before is too late for 3.2.