improve drop down menu handling on android

[mahe...@samsung.com]

Hi everyone,

recently I had tough time using a desktop site which had drop down menu. Raised a bug for the same https://code.google.com/p/chromium/issues/detail?id=382002

General way these websites implement drop down menu is by listening to mouseenter/mouseleave event to show drop down on the menu itself and the menu itself is anchor element loads a new page. So on android chrome always follows the link but never show dropdown. As mouseenter/mouseleave events were followed by firing click event immediately.

iOS handles these events differently, example: iOS does not fire "click" event when you tap of the menu first time but fires on second time. So drop down menu shows up at first and on second tap it follows the link on menu.

Any thoughts on why we shouldn't match this behavior?

Thanks,
Mahesh

[Rick Byers]

I just (before noticing this thread) added the following text to the bug.  What do you think?

We've considered matching Safari's behavior here in the past, but there's a general consensus that it's developer hostile.  I've seen many developers complain that their click events are going missing and users have to click twice for no apparent reason.  The web is moving to be mobile optimized - we've gotten this far, I think complicating/confusing the model for mobile-first websites for better compatibility with websites that _still_ haven't been designed with mobile in mind (and are using such UI paradigms that are now out of fashion) is precisely the wrong tradeoff for blink at this stage.

Note that the user should be able to longpress on the hover menu to trigger the hover menu without also triggering a tap.

The IE team made a similar decision for the same reason, but they added a heuristic to effectively provide the page author with a very simple workaround they could opt-in to: http://msdn.microsoft.com/en-us/library/ie/jj152135(v=vs.85).aspx.  I'd support implementing the same aria-haspopup heuristic, or possibly defining a new specific API for this. 

Rick

[Tien Mai]

Hello Rick,

My name is Tien from the Microsoft Edge team. We are investigating this issue again after receiving some feedback from users no sites such as Ebay and USPS. Could you please provide some insights to why Safari's behavior was considered developer hostile? 

Thanks,

Tien

[Rick Byers]

Hi Tien,

The concern is really just about one of predictability and minimizing surprise. It's quite odd and unprecedented that a click listener wouldn't fire the first time a button is pressed but would file the second time. How can we evaluate whether that causes more problems than it fixes? That said, I'm personally a fan of fixing broken web content in any pragmatic way, especially when it brings engines closer together. Has Safari kept this exact behavior for the last decade (I haven't worked in this space much myself in a long time)? Maybe it's time to just accept it's required for good compatibility with Safari and existing web content that's never going to get updated to be mobile-friendly?

Chromium has a pretty strict policy of shipping only browser behavior that's fully specified and covered by conformance tests. So if we did want to copy WebKit here, I think the place to start would be in a standards group - maybe UI events or pointer events? See if we can get consensus on the exact behavior and an API for suppressing it. @Mustaq Ahmed and/or @Robert Flack should be able to advise. 

Rick

On Sun, Jan 28, 2024 at 6:16 PM Tien Mai <tienmai....@gmail.com> wrote:

Hello Rick,

My name is Tien from the Microsoft Edge team. We are investigating this issue again after receiving some feedback from users no sites such as Ebay and USPS. Could you please provide some insights to why Safari's behavior was considered developer hostile? 

Thanks,

Tien

On Friday, August 1, 2014 at 5:30:31 PM UTC-7 Rick Byers wrote:

[Tien Mai]

Hi Rick,

The existing behavior is that Safari cancels navigations when there is a hover logic invoked on anchor tags or on elements that are otherwise clickable. It also implemented some additional logic that determines whether any child element of the element that appeared is clickable.

• If so, they'll cancel the navigation and treat the tap as a hover. 
• If not, they'll continue with the navigation/executing the click handler. You can see this difference when tapping between the "Anchor + Anchor" and the "Anchor + Empty Div" links and the "onClick + onClick" and "onClick + Empty Div" elements on iPadOS

From a user perspective, I don't perceive much risk in encountering additional sub-menus when I click on let's say a dropdown with a clickable element for the first time. In fact, I find it more surprising when users anticipate the presence of sub-menus but cannot access them. Currently, in Edge, the workaround involves a long press to reveal the sub-menu (as exemplified on eBay below). However, this action triggers the right-click menu, obscuring the text of the dropdown menus. Personally, I find this behavior more confusing. 

Some sites that we have seen implementing :hover that causes the above behavior is USPS and ebay.com. 

We ran an experiment in stable to change this behavior in Edge only for a small number of the stable users. Within 2 weeks, there were about 25k suppressed mouse events (average 13 per user) of which about 6.5k or 24% of users tapped an element they may not have seen without the feature, and about 16k consecutively tapped a button that suppressed mouse events for the feature.

Raising this issue in a standard group sounds like a good idea. Please feel free to share more of your thoughts.

Thanks,

Tien

--

Tien Mai (Ms)

SheCodes Vietnam | Founder & President

Babson College | Global Scholar 2020

Mobile: (+1) 518.423.0197 | LinkedIn: https://www.linkedin.com/in/tienmai98/

-------------------------------------------------------------------------------------------------

SheCodes Vietnam

"Founded in 2018, SheCodes Vietnam is a non-profit tech startup that organizes the first female & non-binary hackathon for Vietnamese youth. SheCodes Vietnam’s mission is to build a supportive community for women in tech & close the gender gap in tech industry."