Opened 12 years ago
Closed 14 months ago
#22649 closed defect (bug) (worksforme)
iPad: Media Modal Problem Editing Long Values
Reported by: | miqrogroove | Owned by: | azaozz |
---|---|---|---|
Milestone: | Priority: | low | |
Severity: | normal | Version: | 3.5 |
Component: | Media | Keywords: | needs-testing has-patch |
Focuses: | Cc: |
Description
In Brief: When I try to edit a very long image title (uploaded file name) the media modal window jumps around and I can't see what I'm editing.
Steps to Reproduce:
- On Dashboard, tap Add Media.
- If necessary, upload an image with an obnoxiously long filename, such as a friend's photo from Facebook.
- Select an image in the Media Library tab that has an obnoxiously long title.
- Tap the title field. Cursor should appear at right end of value and visual keyboard should open.
- Tap the backspace key.
Expected Result:
Plain text editing.
Actual result:
Media Library moves off screen.
Found in 3.5-RC2-22944. Screen shot coming momentarily.
Attachments (6)
Change History (33)
#1
@
12 years ago
On Dashboard, tap Add Media.
QuickPress? Is this reproducible on the posts screen too?
#3
@
12 years ago
This also happens in the Alt Text field and the Search field, though I think those are much less likely to be encountered. No such problem with the Caption field.
#4
follow-up:
↓ 9
@
12 years ago
Attempting to produce similar results with the fields on the Add New Post page: In the title or tags input fields, overflowing the width and then using backspace causes the admin bar to reposition itself to the upper-left corner of the input box. Unsure if this is a separate bug of the same nature or an indication that it's a browser bug.
#5
@
12 years ago
The fact that it also moves the admin bar leads me to think that this might be a mobile safari/webkit bug related to position:fixed;
which has had its fair share of bugs there already.
#9
in reply to:
↑ 4
@
12 years ago
Replying to miqrogroove:
Yes, seems this is the same bug. In both cases closing/hiding the keyboard fixes the positions. Looks like this is the same bug with position: fixed
that sometimes moves the toolbar lower when the keyboard is shown. In the media modal it's even more severe though as it moves it almost completely off-screen.
Looking at some workarounds (disabling scrollintoview) that might fix this at least in some cases.
#11
@
12 years ago
The only way to consistently fix this for the media modal is to set it to position: absolute
. As we already do that for window width of less than 600px (as part of the responsive layout), perhaps we could set it for all mobile devices. Alternatively can detect iOS Safari and set it only there.
#12
@
12 years ago
Tried to find other workaround but don't see any. The above patches works, but have side effects.
22649-admin-bar.js.patch sets the toolbar to position: absolute
while a text field or a textarea is focused. This keeps it in place at the top but effectively hides it if the window is scrolled down.
22649-media-views.js.patch sets the media modal to position: absolute
which shows it at the top of the window, so we would need to scroll to the top for the user to see it :(
I'm 50/50 on both workarounds. They make better in iOS Safari but the side effects are significant.
#14
@
12 years ago
22649-admin-bar.js.patch - very much in favor of this. It corrects the admin bar everywhere except in the post Visual tab. The lack of the fix in there is noticeable.
#15
follow-up:
↓ 16
@
12 years ago
22649-media-views.js-2.patch - can you make it scroll up on blur too? It's kind of annoying that half of the modal isn't visible after closing the keyboard.
#16
in reply to:
↑ 15
;
follow-up:
↓ 17
@
12 years ago
Replying to miqrogroove:
22649-media-views.js-2.patch - can you make it scroll up on blur too?
On blur of... what?
#18
in reply to:
↑ 17
@
12 years ago
Replying to miqrogroove:
Replying to helenyhou:
On blur of... what?
Inputs and textareas.
That's not how that workaround works, at least if I'm reading correctly. It positions the modal absolutely in Mobile Safari when opening, not dependent on whether or not an input has focus.
The toolbar piece makes sense to me. It can be a little funky on blur (the toolbar is sometimes moved down momentarily), but it's better than without.
The media modal piece with scrolling, 22649-media-views.js-2.patch, also works for me in practice. Tested with putting another wp_editor() instance way farther down. I kind of hate the idea that we're scrolling the user around, and it isn't completely seamless, but it does fix the problem reported without making other things unusable.
#19
@
12 years ago
- Priority changed from normal to low
I'm generally fine with the admin bar patch, but note that it will not work properly on the frontend. The backend applies 28px in padding to the html element, while the frontend applies 28px in margin. Thus, it ends up completely hiding underneath the top of the window.
I'm testing the media-views patch on Chrome and I find it to be completely seamless there. (Disabling the browser checks, obviously.)
#22
in reply to:
↑ 21
@
12 years ago
Replying to helenyhou:
Can you elaborate?
As described above, the media modal works better on iPad without the patch. To fully elaborate:
Without patch:
- Editing long image titles is difficult.
- Everything else works fine.
With patch:
- Using any text input or textarea causes the media modal to be positioned half way off screen until manually scrolling to the top of the page.
#23
@
12 years ago
I did not experience the positioning problem with using inputs or textareas in the media modal with the patch. The parts that aren't seamless are that the overlay stops at a point, which you'll see if you scroll down without closing the modal, and that, at least on the iPad, the screen whites out for a moment while it's doing its scrolling thing.
Thinking about effects on the front end with the toolbar patch make me hesitant about that piece, even if it's just about the toolbar and hides it for a bit when in an input. I don't find anything completely unusable without the workarounds, just awkward, but the same awkward I experience in other places on the web on the iPad. We haven't milestoned this for 3.5, and I'm thinking we shouldn't rush it.
#24
@
12 years ago
- Milestone changed from Awaiting Review to Future Release
Yeah, I'm having second thoughts after re-testing these again. The media modal problem is quite rare (happens only if the length of the file name or alt string exceeds the visible length of the text field). The toolbar problem is annoying but doesn't make any screen impossible to use (as @helenyhou says).
+1 to leave these for 3.6 while hoping iOS Safari would finally be fixed to not mangle position:fixed elements when the keyboard is shown.
This ticket was mentioned in Slack in #core by miqrogroove. View the logs.
9 years ago
#26
@
9 years ago
postion:fixed and scrolling in iOS 8. https://meta.discourse.org/t/dealing-with-ios-8-mobile-safari-bugs/24101/13
Related?
Also, #32502.
#27
@
14 months ago
- Resolution set to worksforme
- Status changed from assigned to closed
Tested as of 10/19/2023 and this does not appear to be an issue. Given the vast numbers of changes to the WordPress design, the media modal, and to the iPad operating system and browser, I'm not even going to attempt to identify what actually changed here. Closing.
Bug screen shot.