Opened 5 years ago
Closed 11 months ago
#44431 closed defect (bug) (invalid)
Post editor toolbar: inconsistent and bugged sticky behaviour, and; incorrect paragraph styles menu positioning on scroll
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.9.6 |
Component: | Administration | Keywords: | has-screenshots reporter-feedback close |
Focuses: | ui, javascript, administration | Cc: |
Description
The MCE editor toolbar exhibits inconsistent and incorrect sticky behaviour on scroll. There are three patterns I've observed:
1) If you wait for more than a few seconds before scrolling, the editor toolbar will not stick, and you'll need to scroll up to make any changes on medium-long posts.
2) If you scroll within approximately 1 sec of the toolbar appearing, it will stick to the top of the window, and will never unstick, causing it to cover the Title field, preventing it from being edited, and also when scrolling down past the main content textarea, it will remain stuck and will overlap subsequent fields as well.
3) In the "goldilocks zone" between the above time periods, it's possible to have the toolbar stick when scrolling, then unstick, and it will remain in the location where it became unstuck, usually in the middle of the main content textarea.
Initial page load
Along a similar vein, the paragraph style menu positioning is also incorrectly implemented. It appears that the logic to determine its position is:
1) Take the Y page offset for the paragraph style menu button
2) Apply this offset to the fixed menu as its top style property
This is only legitimate when the user does not scroll. As soon as the user scrolls, whether the toolbar sticks or not, the page offset of the menu button applied as the top offset of the menu will cause the menu to appear entirely disconnected from the button.
If the toolbar is not stuck, then the menu will always at least still be visible, because it's not possible to click the menu button once it has been scrolled out of view, and its page offset will be small enough that the menu will still appear within the window.
However, if the toolbar is not initially visible before scrolling, or if it sticks on scroll, then the menu will be placed outside of the viewable window, making it inaccessible.
We have the following active plugins that interact with the post add/edit form: TinyMCE Advanced v4.7.11, Advanced Custom Fields Pro v5.5.10, and Gravity Forms v2.1.3.9. Deactivating any/all of these plugins had no discernible impact on the above behaviour.
Attachments (9)
Change History (14)
#1
@
5 years ago
- Keywords reporter-feedback added
@startsat60 thanks for the bug report.
What browser are you using? Testing this in Firefox, Chrome and Edge on Win 10, all seems to work properly. It's true that this code is getting old. The "stickiness" there is implemented mostly with JS. At the time there was no other way, but now the browsers support most of it from CSS.
Not sure why the toolbar position "breaks" on scrolling. But the headings/paragraph drop-down should always hide on scroll. Perhaps this fails in your browser, or is affected by a script added by plugin? Could you try another browser to confirm?
#2
follow-up:
↓ 3
@
5 years ago
@azaozz We see this behaviour on Chrome and Firefox, on multiple machines in our editorial team, all using Macs.
#3
in reply to:
↑ 2
@
5 years ago
Replying to startsat60:
Just tested on a Mac and all seems to work pretty well here... Is it possible that you are using some kind of script that interferes with scrolling? Do you see any errors in the browser console?
In no, try pasting this in the browser console, then press Enter:
jQuery( document ).on( 'scroll', function() { console.log( window.scrollY ); } );
After that when scrolling there will be a lot of numbers outputted in the console. When you scroll slowly they should be outputted "smoothly", perhaps skipping a bit. Something like this:
1 2 5 8 11 15 18 ...
#4
@
2 years ago
- Keywords close added
Hello @startsat60,
Does this problem still exist today? If yes, please review and follow-up to Ozz's questions to help contributors with further investigation.
Marking this ticket as a close candidate. What does that mean? If there's no activity in a month, the ticket will be closed. But don't worry as it can be reopened if the problem continues.
Initial page load