#17503 closed defect (bug) (fixed)
Make DFW mouse movement behavior consistent
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Priority: | normal | Milestone: | 3.2 |
| Component: | Editor | Version: | 3.2 |
| Severity: | major | Keywords: | |
| 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)
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.
- Owner set to azaozz
- Resolution set to fixed
- Status changed from new to closed
In [18137]:
Sounds good, hopefully we will have time to do this properly before is too late for 3.2.