RESOLVED FIXED 200216
[iPadOS] slides.google.com: tapping near cursor in a slide title focuses the speaker notes 
https://bugs.webkit.org/show_bug.cgi?id=200216
Summary [iPadOS] slides.google.com: tapping near cursor in a slide title focuses the ...
Maciej Stachowiak
Reported 2019-07-28 22:48:44 PDT
Tapping the near cursor in a title in a slides.google.com slide focuses the speaker notes. Steps to reproduce: 0) Install iOS 13 beta or newer on a non-mini iPad (no hardware keyboard attached) 1) Visit https://slides.google.com/ and log in with a Google account (if not already logged in) 2) Create a new presentation using the orange 'Your big idea' presentation template. 3) Go to the second slide (e.g. by tapping it in the sidebar). 3) Tap the title on the slide. (The cursor appears at this point, but, consistent with Google Docs and Google Sheets, it takes ab extra tap near the cursor to bring up the keyboard) 4) Tap near the cursor. Results: - Focus is placed in speaker notes instead of the title. - The slide shrinks to really tiny. It's possible these behaviors are connected somehow, both seem undesirable.
Attachments
Fixes the bug (16.68 KB, patch)
2019-08-06 17:50 PDT, Ryosuke Niwa 		no flags
DetailsFormatted DiffDiff
EWS build fix (16.71 KB, patch)
2019-08-06 19:00 PDT, Ryosuke Niwa 		wenson_hsieh: review+
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2019-07-28 22:49:13 PDT
<rdar://problem/53648131>
Maciej Stachowiak
Comment 2 2019-07-29 00:26:42 PDT
None of this weirdness happens with a physical keyboard attached, by the way.
Daniel Bates
Comment 3 2019-08-01 13:55:02 PDT
slides.google.com has seems to always have an <iframe> as their active element whose content document's <body> has inputMode = "none" even when you tap once. When you tap twice, slides remove's the inputMode HTML attribute entirely => unspecified input mode => default behavior and we show the keyboard. As to why the site works when you have a hardware keyboard attached...because we do not respect inputMode when you have one attached 😀. Haven't tried what happens on a Chromebook or Surface, but in absence of doing so, I'm leaning towards this bug being a site issue. Might be able to add a site quirk though for slides.google.com. Here's what we know towards a quirk: 1. The user explicitly tapped on something 2. The tapped thing causes a focusing/re-focusing of a content editable element (their active element <iframe>'s content document's <body> is content editable) 3. Slides does not appear to have custom keyboard UI.
Daniel Bates
Comment 4 2019-08-01 14:00:27 PDT
(In reply to Daniel Bates from comment #3) > slides.google.com has seems to always have an <iframe> as their active > element whose content document's <body> has inputMode = "none" even when you > tap once. When you tap twice, slides remove's the inputMode HTML attribute > entirely => unspecified input mode => default behavior and we show the > keyboard. > > As to why the site works when you have a hardware keyboard > attached...because we do not respect inputMode when you have one attached 😀. > > Haven't tried what happens on a Chromebook or Surface, but in absence of > doing so, I'm leaning towards this bug being a site issue. Might be able to > add a site quirk though for slides.google.com. Here's what we know towards a > quirk: > > 1. The user explicitly tapped on something > 2. The tapped thing causes a focusing/re-focusing of a content editable > element (their active element <iframe>'s content document's <body> is > content editable) Cannot use this as a factor because every tapped element (tapping a slide thumbnail etc etc) seems to refocus <body> and <body> is always content editable. That sucks.
Daniel Bates
Comment 5 2019-08-01 14:01:16 PDT
Over to Evangelism...
Daniel Bates
Comment 7 2019-08-02 11:16:48 PDT
Taking this bug back.... WebKit does not consider the fact that causing the keyboard to show or hide as a result of an HTML inputmode change can effect the position of touchevents (and mouse events) that are being processed. More specifically, the bug on slides.google.com occurs because the UI process is notified of the HTML inputMode change and we reload the input views between the touchdown and touchup as debug logging shows: ### -_webTouchEventsRecognized:; type: TouchStart ### -_webTouchEventsRecognized:; type: TouchEnd ### -_webTouchEventsRecognized:; type: TouchStart ### -_didUpdateInputMode: ### -_keyboardWillShow: ### -_webTouchEventsRecognized:; type: TouchEnd ### -_keyboardDidShow: My guess is that Google changes focus on touchup (aka TouchEnd) and the showing of the keyboard effects the tapped point on the page.
Ryosuke Niwa
Comment 8 2019-08-06 17:50:13 PDT
Created attachment 375672 [details] Fixes the bug
Ryosuke Niwa
Comment 9 2019-08-06 19:00:03 PDT
Created attachment 375674 [details] EWS build fix
Wenson Hsieh
Comment 10 2019-08-06 19:08:42 PDT
Comment on attachment 375674 [details] EWS build fix View in context: https://bugs.webkit.org/attachment.cgi?id=375674&action=review > Source/WebKit/ChangeLog:16 > + touchend / pointerup evnets are dispatched but this is rather risky since that could affact random Nit - evnets => events, affact => affect > Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm:944 > + if (m_pendingInputModeChange) > + pageClient().focusedElementDidChangeInputMode(*m_pendingInputModeChange); Would it make sense to clear out m_pendingInputModeChange after we use it here?
Ryosuke Niwa
Comment 11 2019-08-06 20:12:12 PDT
(In reply to Wenson Hsieh from comment #10) > Comment on attachment 375674 [details] > EWS build fix > > View in context: > https://bugs.webkit.org/attachment.cgi?id=375674&action=review > > > Source/WebKit/ChangeLog:16 > > + touchend / pointerup evnets are dispatched but this is rather risky since that could affact random > > Nit - evnets => events, affact => affect > > Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm:944 > > + if (m_pendingInputModeChange) > > + pageClient().focusedElementDidChangeInputMode(*m_pendingInputModeChange); > > Would it make sense to clear out m_pendingInputModeChange after we use it > here? Yeah, we should surely do that.
Ryosuke Niwa
Comment 12 2019-08-06 20:15:21 PDT
Committed r248338: <https://trac.webkit.org/changeset/248338>
Note You need to log in before you can comment on or make changes to this bug.