Using PgDn and PgUp keyboard keys in the editor scrolls both post edit box and the whole viewport

[archon810]

The editor in WordPress 4.1 is great, and the whole sticky sidebar is a great improvement, but editing using Page Down and Page Up keys as part of the workflow is some of the most frustrating experience one can have because they control both the cursor in the post edit box and the page itself.

For example, if I go into a short post, put the cursor at the beginning of the post, and press Page Down, I'm going to end up with this:

At this point, I can only see a tiny sliver of the post because the page has scrolled too.

This is similar to #30919, except I'm not talking about the distraction-free mode, which I almost never use.

Windows 8.1 on Chrome 42 beta, but this behavior has been the same for as long as I can remember.

[dlynch027]

Can confirm. If you click out of the editor, and then page down, it functions like it should. However, clicking inside the editor and then doing a page down will take you immediately to the bottom as it also removes the editor functions at the top(until you scroll back up).

Tested this on the latest Ubuntu with Chrome 41 Stable 64-bit

[mrwweb]

#30919 was marked as a duplicate.

[archon810]

Any ideas here from the core team?

[mrwweb]

A couple notes:

• As mentioned in #30919, this also affects the END and HOME keys.
• There may be some a11y considerations here. I see from WebAIM that ​JAWS uses `PgUp` and `PgDwn` to control voice speed.

[adamsilverstein]

@archon810 - thanks for the bug report.

I agree this is very annoying; however, I'm not sure if this is a bug, or expected browser behavior.

Everywhere I checked in other text fields or even full screen editors like google docs, hitting page down was applied at the window level and my page scrolled if possible. I'm worried trying to fix this here will involve some fragile JS and the result may not be what users expect.

Related: #27770

[archon810]

There's a fundamental difference between editing in Google docs (or any editor program ever) and WordPress though - Google Docs gives you the full view to work on the text, and page down and up work as expected. Same with any editing software, like Word, any IDE, email clients, etc. That's what these 2 very handy buttons are for and have been since the invention of the keyboard.

They're useless in WordPress, a major piece of software now powering a huge chunk of the Internet. If browsers scroll down natively when you press it even if you're in an edit field, that's a usability issue that should be fixed. That's my opinion on this matter.

I hope you will see it that way too. There are few things more annoying about editing text day in and day out than ending up with a sliver of visible text when you just want to navigate the post you're writing.

[archon810]

Btw, the only other even more annoying issue that I can think of is when you go to an edit page, make edits, submit them, something goes wrong or you have some logic to deny the submission (like text validation), click back, and all your changes are lost as the editor reloads the original data rather than the form you just spent time editing.

I have an open ticket for this too if you're interested.

[mrwweb]

Replying to adamsilverstein:

I agree this is very annoying; however, I'm not sure if this is a bug, or expected browser behavior.

I agree with @archon810. WordPress breaks the expected browser behavior with the fancy scrolling editor, so it becomes WordPress's responsibility to implement any expected browser behaviors that are broken. I'd liken this to how single-page web apps need to not break the back button or <div role="button"> needs a bunch of JS to re-implement the expected keyboard behaviors.

[adamsilverstein]

I agree with @archon810. WordPress breaks the expected browser behavior with the fancy scrolling editor, so it becomes WordPress's responsibility to implement any expected browser behaviors that are broken.

To take WordPress out of the question, I tried testing this on the TineMCE homepage ​https://www.tinymce.com/ (this is the editor used in WordPress)

The scroll behavior I see is the same as the WordPress editor and seems to be browser specific - I tested chrome and firefox... chrome always scrolls the outer page, no matter what. Firefox will scroll only the editor region _if it has a scroll bar_. I don't think TinyMCE or WordPress do anything to change the reaction of the page to these key events.

I still feel this is a browser behavior and changing it will break user's expectations, not help them.

[adamsilverstein]

They're useless in WordPress, a major piece of software now powering a huge chunk of the Internet. If browsers scroll down natively when you press it even if you're in an edit field, that's a usability issue that should be fixed. That's my opinion on this matter.

I agree these keys are currently useless in Chrome - I discovered in testing the firefox is a bit different: it will let you scroll an inner area without scrolling the page, if the inner area has a scroll bar - this makes page up/down more useful in firefox.

I agree this is a bad user experience: my point is that this is a browser issue, not a WordPress issue. Trying to address it in WordPress will only make it behave differently than every other site, possibly confusing users. Maybe some users have grown to expect the page up/down will work on the page?

[afercia]

Hm I think the "scroll" we see in the Post screen is actually the page that scrolls normally while other elements are "fixed" in place. :)

[afercia]

Removing the accessibility focus since this is something more related to the Editor and for the Editor Team.

[noisysocks]

We should match the normal behaviour that a textarea has here.