1511157 - Hotels.com location selection requires two taps in Focus+GV, but only one in Focus+WebView

Status: RESOLVED WORKSFORME

(GeckoView :: General, defect, P3)

Description

[Chris Peterson [:cpeterson]]

STR:
1. open hotels.com
2. click on the location field (before the date picker)
3. try to select a location from the drop down list

ACTUAL RESULT:
In Focus+GV, you have to tap twice to complete the selection.

EXPECTED RESULT:
In Focus+WebView, you only have to tap once to complete the selection.

Vesta filed a Focus issue:
https://github.com/mozilla-mobile/focus-android/issues/3984

Bug 1511154 describes a problem where the same Hotels.com page's date picker closes before the user can pick a date. I wonder if the web page has some JS that messes with the input focus?

Comment 1

[Chris Peterson [:cpeterson]]

P2 for Fenix.

Comment 2

[Makoto Kato [:m_kato]]

First tap is that compositing string is committed. If there is no composing string, it can select location. This seems to IME/keyboard issue.

Comment 3

[Makoto Kato [:m_kato]]

This occurs on Firefox Desktop, too. But Chrome Desktop can select location even if there is IME composition.

step

1. Focus location, then input とうきょう (It keeps composition)
2. Click location from list box

Gecko's result

composition is committed, but location isn't selected

Blink/Edge/WebKit's result

composition is committed, then location is selected

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

We dispatch click event even when there is composition.
https://jsfiddle.net/d_toybox/ouk8neb6/

Perhaps, hotels.com listens to different event(s), or they send different script to Blink/Gecko.

Comment 5

[Makoto Kato [:m_kato]]

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #4)

We dispatch click event even when there is composition.
https://jsfiddle.net/d_toybox/ouk8neb6/

Perhaps, hotels.com listens to different event(s), or they send different script to Blink/Gecko.

click event isn't posted to <div class="widget-autosuggest ..."> on hotels.com. WidgetMouseEvent.mClickCount seems to be 0, but I don't know why this count is 0.

Comment 6

[Makoto Kato [:m_kato]]

Input event handler of <input> seems to re-construct html into suggested location list. When clicking this list, Gecko commits string, then input event is fired. Then, I guess that ESM looks for target, but target may be destroyed, so click event isn't fired since mClickCount is 0 and mClickTarget is null.

But at least, as long as I test on Edge and Chrome, input event isn't fired at this situation, so I guess that this occurs on Gecko....

Comment 7

[Makoto Kato [:m_kato]]

Attachment: Bug 1511157 - Don't fire input event on blur. r?masayuki

Problem is that hotels.com updates suggestion list panel of location by input
event.

When location's text box has composing string and user clicks suggestion panel,
click event isn't fired in this panel. So location isn't selected. Click event
will be fired when target is valid, but target is gone because this panel is
reconstructed by input event.

Blink, WebKit and Edge don't fire input event during force committing by blur
although composition end is fired. But Gecko fires input event unfortunately,
so this occurs on Gecko only.

For compatibility, we shouldn't fire input event at this situation.

Also, although Gecko commits compositon when clicking current focus element,
input event will be fired on this situation. But WebKit and Blink don't.
So we should change to other browser's behaviour. When using contentedtiable,
there is no way to detect in EditorEventListner whether current mouse down is
with blur.

Comment 8

[Makoto Kato [:m_kato]]

(I am waiting for test result)

Comment 9

[David Bolter [:davidb] (NeedInfo me for attention)]

Anne I'm wondering what our best way forward is regarding comment 7. I imagine this pattern comes up a lot: we either follow chromium for web compat reasons (quicker) or we follow the spec and wait for a spec or chromium change (slower?). Thoughts?

Comment 10

[Anne (:annevk)]

I would expect Masayuki to be able to give a more informed answer here. It basically depends. Often the pragmatic route of changing Firefox and the standard is the way to go, except for when our approach is substantially better and we can weather the compatibility issues.

Per https://github.com/w3c/uievents/issues/202 we might actually be the ones breaking the standard here though?

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I don't think that we should change our behavior nor standards because input event (and preceding beforeinput event) is not fired only when IME composition is committed forcibly (i.e., not committed by user via keyboard). So, there are some issues if standards will be changed:

1. beforeinput needs to be always paired with "input" event.
2. beforeinput event in this case should be cancelable to make web apps can filter inserted string from IME. I.e., we'd steal the chance from web apps only when composition is committed without keyboard.
3. I don't think that it's not reasonable declaration, for example, "beforeinput event and input event are fired when immediately before and after the DOM is modified except text is inserted from IME and it's not caused by keyboard input"...

Anyway, I'll file a bug to Chromium project and I'll contact somebody who works on UI Events.

Comment 12

[[ex-Mozilla] Agi Sferro | :agi]

makoto, is this still relevant?

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

It may be better to fix Chromium's bug by us. Then, web apps need to align for the standard behavior.

Comment 14

[Makoto Kato [:m_kato]]

So I recommend that this is P3 instead of P2 due to web standard issue.

Comment 15

[Chris Peterson [:cpeterson]]

Makoto says this issue is spec side. No action until https://github.com/w3c/uievents/issues/202 (Event order between "compositionend" and "input") is resolved.

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

It seems that the Hotels.com issue has already been fixed by their side.

Comment 17

[James Graham [:jgraham]]

Even though the original hotels.com bug is fixed, setting webcompat-priority: ? to get it on the radar since some of the linked bugs also seem to involve site breakage.

Comment 18

[Dennis Schubert [:denschub]]

No known site breakage at this point, setting webcompat P3 for now.

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Makoto-san, I think that we can close this bug due to it's not reproducible anymore and we can discard the patch at least until UI Events changes the definition. I still think that our behavior is correct and the input event may be required by web apps in theory because the committing composition may not be intended by the web apps.

Comment 20

[Makoto Kato [:m_kato]]

Yep, we can close this and we cannot reproduce this.