Opened 3 years ago
Closed 2 years ago
#53174 closed defect (bug) (fixed)
notice in link-popup of WYSIWYG overlapping search field
Reported by: | jonny-s | Owned by: | joedolson |
---|---|---|---|
Milestone: | 6.1 | Priority: | normal |
Severity: | minor | Version: | 5.7.1 |
Component: | Editor | Keywords: | has-patch needs-testing commit dev-reviewed |
Focuses: | ui, accessibility, css, administration | Cc: |
Description
Hi,
I just noticed, that if text-size is scaled by browser-settings, in the WYSIWYG-Editor's link modal popup the notice is overlapping the search field (see screenshot).
Attachments (14)
Change History (55)
#1
@
3 years ago
- Focuses accessibility css added
- Keywords needs-patch added
Thanks for the report!
I see a similar overlap with a minimum font size.
The #wp-link .query-results
container uses absolute positioning from the top (either 166px or 210px) in editor.css.
I tried changing the value to an em
measurement, but that does not seem to work well.
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
3 years ago
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
3 years ago
#6
@
3 years ago
- Keywords has-patch added; needs-patch removed
CSS flex could help with larger text. I returned the layout to static positioning and removed some overflow: hidden
rules. I'm not sure this is better overall, but it's at least a start.
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
3 years ago
#9
@
3 years ago
Unfortunately, this has created some big problems with focus and keyboard access - the active item scrolls out of view on click, keyboard navigation no longer keeps things in view. This will probably need some more work.
If the #search-results
div has absolute positioning, the keyboard/focus works as expected, and with the other style changes, doesn't trigger the overlap with the search input.
Updating patch to apply absolute positioning on results and give the results div width.
#10
@
3 years ago
- Milestone changed from 5.9 to 6.0
Thanks for updating the patch!
It might be ready, but I'm not confident about committing it today. I'll move this to the next release (if someone else thinks it's ready now, the ticket can go back to 5.9).
#11
@
3 years ago
This works fairly well at low levels of text zoom, but there are a lot of CSS issues at higher levels of text zoom (over 170%). Browser zoom works fine.
Practically speaking, I think this is a significant improvement on the current state, and it does resolve the specific problem documented. However, with a little more time, it could definitely be improved.
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
3 years ago
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
2 years ago
#15
@
2 years ago
- Keywords needs-patch added; has-patch removed
We reviewed this ticket today during the Accessibility Team's weekly bug scrub.
As mentioned by @joedolson in one of the above comments, there are a few issues with high levels of text zoom.
WCAG 2.1 Success Criterion 1.4.4 require the text to be resizable up to 200% without loss of functionality, so if someone is able to test with this level of zoom, it would really help in finding all issues.
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
2 years ago
This ticket was mentioned in Slack in #accessibility by sabernhardt. View the logs.
2 years ago
#19
@
2 years ago
- Keywords needs-patch removed
This patch significantly improves the layout when text zoom is at 200%.
#22
@
2 years ago
- Keywords commit removed
This still has broken keyboard functionality; need to fix that before can be committed.
#23
@
2 years ago
On further testing, what I'm observing isn't new; it's just a little hard to follow at high zoom because the shifts impacting what's currently visible happen a lot more frequently. To help with this, I'm going to increase the modal height a bit more.
#26
@
2 years ago
- Keywords commit removed
- Resolution fixed deleted
- Status changed from closed to reopened
#27
@
2 years ago
- Keywords has-patch needs-testing added
Increasing the modal height required a few more changes.
This ticket was mentioned in Slack in #core by desrosj. View the logs.
2 years ago
This ticket was mentioned in Slack in #core by chaion07. View the logs.
2 years ago
#30
@
2 years ago
@sabernhardt Can you give a text description of the problem and solution? I'm not clear what this is solving from the screenshots.
#31
@
2 years ago
@joedolson The "Cancel" and "Add link" buttons can be hidden behind the bottom of the browser window because the Link Options modal is 100 pixels taller now.
- If the zoom level is at 100%, resize the browser window to a height between 521 and 600 pixels and any width.
- Activate Classic Editor.
- Create a new post in the post editor.
- Insert a link, and open the Link Options.
- Look for the "Add link" button at the bottom.
#32
@
2 years ago
- Keywords commit added
Tested; looks good. Marking for commit. Good catch! I didn't check the max height issues carefully enough.
This ticket was mentioned in Slack in #core-committers by joedolson. View the logs.
2 years ago
#35
@
2 years ago
- Keywords dev-reviewed added; dev-feedback removed
Thanks @sabernhardt for the detailed testing procedure :)
Patch tested, works for me 👍
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
2 years ago
#38
@
2 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Reopening for backport consideration
Notice is overlapping search field when text-size is scaled