Make WordPress Core

Opened 8 years ago

Closed 5 years ago

#37790 closed defect (bug) (wontfix)

Post editing sidebar does not always act sticky

Reported by: tomdxw's profile tomdxw Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.6
Component: Editor Keywords: has-patch
Focuses: Cc:

Description

Situation 1 (works fine)

  1. Go to the new post page (/wp-admin/post-new.php).
  2. Paste enough lorem ipsum into the visual editor that the page is able to scroll.
  3. Scroll down.

Expected and actual behaviour:

#side-sortables gets position: fixed and sticks to the viewport as you scroll down the page

Situation 2 (does not work)

  1. Add metaboxes to the post type (enough so that the page will scroll - ACF is an easy way to do this, or you could just install a bunch of plugins, or manually create the metaboxes).
  2. Go to the new post page.
  3. Scroll down.

(Make sure your viewport is taller than the editor).

Expected behaviour:

Just like the other situation, #side-sortables should get position: fixed and stick to the viewport as you scroll down the page.

Actual behaviour:

Nothing happens to #side-sortables and the sidebar does not follow the viewport as the user scrolls.


This happens because in wp-admin/js/editor-expand.js it compares the height of the editor against the height of the viewport.

// Sidebar pinning
if ( $postboxContainer.width() < 300 && heights.windowWidth > 600 && // sidebar position is changed with @media from CSS, make sure it is on the side
    $document.height() > ( $sideSortables.height() + postBodyTop + 120 ) && // the sidebar is not the tallest element
    heights.windowHeight < editorHeight ) { // the editor is taller than the viewport

It should compare the height of the whole page instead. i.e.:

heights.windowHeight < $('#poststuff').outerHeight() ) { // the page content is taller than the viewport

Attached a diff (make sure to do define('SCRIPT_DEBUG', true);when using this diff as I didn't recompile the JS).

Attachments (1)

sticky.diff (866 bytes) - added by tomdxw 8 years ago.

Download all attachments as: .zip

Change History (8)

@tomdxw
8 years ago

#1 @tomdxw
8 years ago

  • Keywords has-patch added

#2 @swissspidy
8 years ago

  • Keywords needs-testing added

Thanks for the patch!

Attached a diff (make sure to do define('SCRIPT_DEBUG', true);when using this diff as I didn't recompile the JS).

That's not needed for patches anyway, as the JavaScript gets minified during the build process.

#3 @tomdxw
7 years ago

  • Keywords 4.8-early added

#4 @tomdxw
7 years ago

  • Keywords 4.8-early removed

#5 @tomdxw
7 years ago

  • Keywords 4.9-early added

#6 @aprea
6 years ago

FWIW this patch is a very welcome change and appears to fix the problem described in situation 2.

I ended up needed this for a production site and had to deregister editor-expand in favour of this patched version.

#7 @desrosj
5 years ago

  • Keywords needs-testing 4.9-early removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I am going to close this out as a wontfix. The new block editor has redesigned the edit screen and the Classic Editor is being preserved as is, with the exception of major bugs.

Note: See TracTickets for help on using tickets.