Opened 9 days ago
Closed 4 days ago
#65778 closed defect (bug) (fixed)
The Media toolbar loading spinner is not visible in the responsive view and misplaced in the desktop view
| Reported by: | afercia | Owned by: | joedolson |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.1 |
| Component: | Media | Version: | trunk |
| Severity: | normal | Keywords: | has-patch commit |
| Cc: | Focuses: | css |
Description (last modified by )
Splitting this out from https://core.trac.wordpress.org/ticket/65732#comment:14
It appears to be a regression in trunk. I could not reproduce the issue in WP 7.0.
- Go to the Media Library, grid view.
- WHen selecting from the 'type' filter or searching, a spinner appears in the toolbar. It so fast that sometimes can't be noticed.
- For testing purposes: Locate it in your browser devtools inspector, it's placed after the 'Bulk select' button:
<span class="spinner"></span>
- Add the CSS class
is-activeto make it visible. - Observe it is misplaced as in: not vertically aligned.
- Emulate the responsive view below 782 pixels.
- Refresh the page, just in case.
- Observe that even without adding the
is-activeclass, the media toolbar shows a sort of gray border at the bottom. - That's the spinner... not sure why its layout is so broken.
See attached screenshot.
Attachments (5)
Change History (16)
#3
@
8 days ago
Was just coming to say the same thing.
But I think this is fixed just by removing the absolute positioning; I don't think any of that is actually needed in either viewport.
This ticket was mentioned in PR #12797 on WordPress/wordpress-develop by @joedolson.
8 days ago
#4
- Keywords has-patch added
Limit the spinner absolute positioning to only take effect in the media modal.
Trac ticket: https://core.trac.wordpress.org/ticket/65778
## Use of AI Tools
#5
@
7 days ago
I spotted one more misplaced spinner in the 'Attachment details' dialog, although this one appears to be a regression from WP 6.6. See attached screenshots.
#7
@
4 days ago
Had a look at the positioning across different widths. The spinner is centered on .media-toolbar-secondary, and I think that's the problem.
On a wide window, the two dropdowns sit on one row, the toolbar is 48px tall, and the spinner lines up with them fine (0.2px off). Below 900px, the dropdowns stack, the toolbar becomes 117px, and centering on it puts the spinner in the gap between the two: roughly 22px below "Filter by type" and 36px above "Filter by date".
@afercia that looks like the misplacement in your screenshot. It isn't the offset being a couple of pixels out, it's that the anchor is the container rather than the dropdown next to it.
All three rules center on the container, so top: 50%, calc( 50% - 8px ) and top: 0; bottom: 0; margin: auto all hit this once the toolbar wraps. Anchoring to the date dropdown instead would cover both layouts, and you wouldn't need a separate rule per breakpoint.
On left vs right, the current calc( 100% + 2px ) leaves a 2px gap. right: -30px gives 10px and calc( 100% + 20px ) gives 20px.
Wide window:
Below 900px:
(Spinner forced visible for the screenshots, it only shows while loading normally.)
@joedolson commented on PR #12797:
4 days ago
#8
I think it's reasonable to adjust the specific barrier issues for spinners in this ticket, but not change the existing positioning significantly. There's no clear "winning" position for the spinner on mobile - ideally, it would either be in a clear global position, or always be associated with whatever field triggered it. Those are both more significant changes, however.
@joedolson commented on PR #12797:
4 days ago
#9
#10
@
4 days ago
- Keywords commit added; has-screenshots removed
While I like the suggestion of anchoring the spinner to the date dropdown, @rcorrales, that's unfortunately very non-trivial, because of the structure of the containers. It also can create confusing problems if an extender inserts an additional dropdown into the secondary container; because the spinner would seem to be at a random location.
Overall, I think that this is good as it is now; it fixes the key problems that are serious in current trunk. I'm recommending for commit, but will wait to do so.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)


Oh. Turns out the 'bottom border' is the scrollbar of the container with
overflow: auto;.The spinner is misplaced, actually it's off-screen on the right. It's hidden with
visibility: hiddenso it still takes space and makes the container content overflow. As such, the scrollbar appears.The fix is adjusting the spinner position which is now determined by
left: calc(100% + 2px);.Ideally, it should not use absolute positioning in the first place.