WordPress.org

Make WordPress Core

Opened 17 months ago

Last modified 17 months ago

#22649 assigned defect (bug)

iPad: Media Modal Problem Editing Long Values

Reported by: miqrogroove Owned by: azaozz
Milestone: Future Release 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:

  1. On Dashboard, tap Add Media.
  2. If necessary, upload an image with an obnoxiously long filename, such as a friend's photo from Facebook.
  3. Select an image in the Media Library tab that has an obnoxiously long title.
  4. Tap the title field. Cursor should appear at right end of value and visual keyboard should open.
  5. 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)

image.jpg (460.3 KB) - added by miqrogroove 17 months ago.
Bug screen shot.
image.2.jpg (418.8 KB) - added by miqrogroove 17 months ago.
Post editor bug screen shot.
22649-admin-bar.js.patch (823 bytes) - added by azaozz 17 months ago.
22649-media-views.js.patch (712 bytes) - added by azaozz 17 months ago.
22649-admin-bar.js-testing.patch (996 bytes) - added by azaozz 17 months ago.
22649-media-views.js-2.patch (982 bytes) - added by azaozz 17 months ago.

Download all attachments as: .zip

Change History (30)

miqrogroove17 months ago

Bug screen shot.

comment:1 nacin17 months ago

On Dashboard, tap Add Media.

QuickPress? Is this reproducible on the posts screen too?

miqrogroove17 months ago

Post editor bug screen shot.

comment:2 miqrogroove17 months ago

It is, yes. Additional screen shot attached.

comment:3 miqrogroove17 months 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.

comment:4 follow-up: miqrogroove17 months 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.

comment:5 koopersmith17 months 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.

comment:6 nacin17 months ago

  • Keywords needs-testing added

comment:7 nacin17 months ago

azaozz, any ideas?

comment:8 nacin17 months ago

  • Owner set to azaozz
  • Status changed from new to assigned

comment:9 in reply to: ↑ 4 azaozz17 months 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.

comment:10 nacin17 months ago

  • Keywords needs-patch added

comment:11 azaozz17 months 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.

comment:12 azaozz17 months 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.

Version 0, edited 17 months ago by azaozz (next)

comment:13 nacin17 months ago

  • Keywords has-patch added; needs-patch removed

comment:14 miqrogroove17 months 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.

comment:15 follow-up: miqrogroove17 months 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.

comment:16 in reply to: ↑ 15 ; follow-up: helenyhou17 months ago

Replying to miqrogroove:

22649-media-views.js-2.patch - can you make it scroll up on blur too?

On blur of... what?

comment:17 in reply to: ↑ 16 ; follow-up: miqrogroove17 months ago

Replying to helenyhou:

On blur of... what?

Inputs and textareas.

comment:18 in reply to: ↑ 17 helenyhou17 months 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.

comment:19 nacin17 months 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.)

comment:20 follow-up: miqrogroove17 months ago

+1 admin bar commit

-1 media patch, not ready

comment:21 in reply to: ↑ 20 ; follow-up: helenyhou17 months ago

Replying to miqrogroove:

-1 media patch, not ready

Can you elaborate?

comment:22 in reply to: ↑ 21 miqrogroove17 months 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.

comment:23 helenyhou17 months 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.

comment:24 azaozz17 months 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.

Note: See TracTickets for help on using tickets.