![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 12 years ago
Closed 6 years ago
#29778 closed defect (bug) (worksforme)
Editor sidebar scrolling breaks when adding anything above post meta boxes
| Reported by: | iseulde | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Editor | Version: | 4.0 |
| Severity: | normal | Keywords: | has-patch close |
| Cc: | Focuses: | ui, javascript, administration |
Description
To test add some html with the submitpost_box and submitpage_box hooks.
Attachments (2)
Change History (12)
#3
follow-up:
↓ 4
@
12 years ago
I had a different approach by putting any newly added content to the #side-sortables div.
I guess it's something we should decide on what's best.
#4
in reply to: ↑ 3
@
12 years ago
Replying to AugusGils:
I had a different approach by putting any newly added content to the #side-sortables div.
I guess it's something we should decide on what's best.
You're moving the action to the sortable div. So anything that action outputs will become sortable.
#6
@
12 years ago
29778.diff changes (a bit) how these two actions work by moving them inside the UI droppable element. This may cause incompatibilities with existing plugins. The approach in 29778.patch has full backwards compatibility.
#8
@
12 years ago
- Milestone 4.1 → Future Release
Thinking more about this: both patches are not 100% backwards compatible. The first adds another wrapper that may become a problem when a plugin traverses the parent nodes with jQuery. The second adds non-sortable elements inside UI Sortable container that may break in some cases. Not sure which one is better.
Furthermore haven't seen any bug reports about broken sidebar because of this. Would be good to test with existing plugins/code.
So what doesn't work is scrolling back up. It's scrolls up to the first box and then whatever's added on top scrolls under it. Until you scroll up all the way.