Make WordPress Core

Opened 10 years ago

Closed 10 years ago

#29356 closed defect (bug) (fixed)

iPad Menu Tapping is Broken

Reported by: miqrogroove's profile miqrogroove Owned by: helen's profile helen
Milestone: 4.1 Priority: normal
Severity: major Version: 4.0
Component: Administration Keywords: needs-testing
Focuses: Cc:

Description

In 4.0-beta4, menu items require multiple taps on iPad.

In 3.8 and 3.9, this problem does not exist.

Attachments (2)

photo 1.PNG (167.2 KB) - added by stephdau 10 years ago.
Note how the Pages menu entry is highlighted (on 1st click), but not expanded. It takes a 2nd click to expand it to get to its options.
29356.patch (4.8 KB) - added by azaozz 10 years ago.

Download all attachments as: .zip

Change History (32)

This ticket was mentioned in IRC in #wordpress-dev by helen. View the logs.


10 years ago

@stephdau
10 years ago

Note how the Pages menu entry is highlighted (on 1st click), but not expanded. It takes a 2nd click to expand it to get to its options.

#2 @stephdau
10 years ago

  • Keywords needs-patch added

I'm able to reproduce this on the latest nightly installed on a test site (see attached screenshot).

Menu items are highlighted on 1st click, but it takes a 2nd one to expand them to get to their respective sub-options.

See Pages and Media menu items in https://cloudup.com/cGj0uNU4C9m

#3 @Ipstenu
10 years ago

I tested on the nightly and mine expand properly on one click, but I have to tap twice on the individual item to go to the expanded page.

Tested the toolbar links:
Toolbar - Sites - Site Name - Dashboard (all one tap) - this works as expected

Tested Network Admin:
Users - Add User - ADD USER (double tap add user to get to that page)

Tested per site menu:
Users - Add User - ADD USER (double tap add user to get to that page)

#4 @stephdau
10 years ago

I'm also noticing that the behavior I documented above is only true on 1st click. Meaning that the issue is there when the user tries to expand a menu, but any other attempts at expanding other menus without yet leaving the page are successful.

#5 @stephdau
10 years ago

...which could not be tested in ipstenu's context, since the items she listed actually have an action that makes the user leave the page. I suspect the same case is true.

#6 @Ipstenu
10 years ago

the user -> add user should have behaved like that, but once you said it's only true on first click that's... weird.

If I click on comments, I go right to comments (as expected), but if I click on 'users' I get the menu popping out right away like I expect. It's the double click on the final action that's acting up for me on my iPad Mini using Chrome and Safari.

#7 @stephdau
10 years ago

What version of iOS/Safari are you on? I'm using my wife's iPad, and it's on an older 7.1.1 release.

#8 @Ipstenu
10 years ago

7.1.2, which is the latest for the iPad Mini.

#9 @miqrogroove
10 years ago

  • Severity changed from normal to major

#10 @helen
10 years ago

I played with this for a while, trying to get something reliable to reproduce, without much luck. I only tracked down one relevant change in 4.0: [29247] for #27980.

Most of the time, the menu works as expected for me. It is quite slow to expand/collapse submenus, which can feel like nothing's happened, but it does work. I can see it being frustrating for any extended use, though.

On occasion, a menu will not expand, but as noted by stephdau, only the first time. Subsequent menu taps all work. It *seems* to correlate with how quickly after (or during) page load you open the menu, but I don't feel confident saying that's definitely related.

Ultimately, this is unlikely to be something that can make it into 4.0. We're already well into freeze, and while I agree that this is something important to track down and fix, it's not a blocker for the release, especially given that there isn't a viable patch or even reliable reproduction steps. We can start with seeing what effects reverting the changeset linked above has on iPads and all the other cited devices and go from there. Happy to include in a point release if we can figure it out.

#11 @miqrogroove
10 years ago

Reverting 29247 does not fix this. :(

#12 @miqrogroove
10 years ago

I tried reverting several files one at a time to try to narrow down the cause.

I was successful in restoring the menu by reverting https://core.trac.wordpress.org/export/HEAD/tags/3.9/src/wp-includes/js/jquery/jquery.js described as [27027] Update to jQuery 1.11.0. The trunk revision is described as [28238] Update jQuery to 1.11.1.

Any chance we can revert that one?

#13 @miqrogroove
10 years ago

And if we can't get that reversion into 4.0, could we please assign this to 4.0.1 for quick response?

#14 @SergeyBiryukov
10 years ago

  • Milestone changed from Awaiting Review to 4.0.1

Moving to 4.0.1 for review.

This ticket was mentioned in IRC in #wordpress-dev by MarkJaquith. View the logs.


10 years ago

This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.


10 years ago

#17 @nacin
10 years ago

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

#18 @azaozz
10 years ago

Does this still happen in iOS8?

#19 @Ipstenu
10 years ago

iPad Mini - iOS8

Safari
First tap of menu with dropdown items - Shows flyout menu (as expected)
Click of flyout sub-menu item - Takes two taps
Click of expanded sub-menu - Takes two taps

First tap of toolbar menu with dropdown - shows flyout menu
Click of flyout sub-menu item - Takes ONE tap

Chrome
First tap of menu with dropdown items - Shows flyout menu (as expected)
Click of flyout sub-menu item - Takes two taps
Click of expanded sub-menu - Takes two taps

First tap of toolbar menu with dropdown - shows flyout menu
Click of flyout sub-menu item - Takes ONE tap

#20 follow-up: @helen
10 years ago

miqrogroove - can you be more specific about what exactly is taking multiple taps to work?

Installing iOS 8 now, but for the record, I still get very inconsistent results from load to load in Safari in iOS 7. Sometimes the first tap on a menu item does not show the dropdown, but all subsequent taps work as expected. I have not had any taps beyond that first one not work, and even then sometimes the first tap will work. It is, however, quite slow to respond to taps.

#21 in reply to: ↑ 20 ; follow-up: @miqrogroove
10 years ago

Replying to helen:

miqrogroove - can you be more specific about what exactly is taking multiple taps to work?

I always work in landscape mode, if that's relevant. The menus open normally, but to get the links to open up seems to take a random number of taps.

#22 in reply to: ↑ 21 @helen
10 years ago

Replying to miqrogroove:

I always work in landscape mode, if that's relevant.

It's extremely relevant. The menu is different between the two widths. Did you look at stephdau's screenshots?

So a note to everybody else looking at this: this is referring to the original with-flyouts menu, not the small-screen, touch-optimized version.

#23 @Ipstenu
10 years ago

On portrait mode, I can reproduce the two-clicks on all things. Once I tap to expand the whole menu, it's always a double-tap to get to the dropdown (not flyouts).

On landscape I cannot. Flyouts show on one tap, but selecting items IN the flyout take two.

#24 @azaozz
10 years ago

Seems this is caused by hoverIntent and/or using the focus event on the links in the menu. Often (and inconsistently) the first "tap" doesn't fire the click event in iOS, just fires focus.

Last edited 10 years ago by azaozz (previous) (diff)

@azaozz
10 years ago

#25 @azaozz
10 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

In 29356.patch: don't initialize hoverIntent and don't attach handlers to the focus event in iOS and Android.

Tested on iOS8 and Android 4.4.4. Both hoverIntent and the focus event should be irrelevant for all touch-screen devices, however this would need testing on as many devices as possible. At least older Android and Windows 8.1 with touchscreen.

Last edited 10 years ago by azaozz (previous) (diff)

#26 @azaozz
10 years ago

In [29770]:

Fix tapping on the menu in iOS and Android, fixes #29356 for trunk.

#27 @azaozz
10 years ago

  • Keywords has-patch removed

This would need testing in older Android before merging to 4.0.1.

#28 @MikeNGarrett
10 years ago

I tested this on Android 4.0 on an emulated Samsung Galaxy Tab 2 using the default android browser. I was not seeing the issues mentioned in this browser before or after the patch. I also tested Android 4.4 on an emulated Galaxy Tab 4 with the same results.

I was seeing this in iOS 6 on an emulated iPad 3rd edition and iOS 8 on an emulated iPad Air.

This may have been isolated to iOS.

#29 @nacin
10 years ago

  • Milestone changed from 4.0.1 to 4.1

#30 @azaozz
10 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

As far as I see this is fixed for 4.1.

Note: See TracTickets for help on using tickets.