Bug 196053

Summary:

[iOS] Cannot tab cycle through credit card fields on antonsvpatisserie.com checkout page

Product:

WebKit

Reporter:

Daniel Bates <dbates>

Component:

WebCore Misc.

Assignee:

Daniel Bates <dbates>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

cdumez, esprehn+autocc, ews-watchlist, gyuyoung.kim, megan_gardner, webkit-bug-importer, wenson_hsieh

Priority:

Keywords:

InRadar, PlatformOnly

Version:

WebKit Local Build

Hardware:

iPhone / iPad

OS:

iOS 12

URL:

https://www.antonsvpatisserie.com/

Bug Depends on:

Bug Blocks:

190571

Attachments:

Description	Flags
For the bots	none
Patch	none
To land	none

Description Daniel Bates 2019-03-20 21:06:24 PDT

Seen on iPad with hardware keyboard. Does not happen on Mac.

Steps to reproduce:

1. Visit <https://www.antonsvpatisserie.com/collections/all>.
2. Pick a cake (any cake, they’re all delicious 😀, say the Signature Flavor).
3. Choose pickup and click Add to Cart.
4. Chose a date and pickup time and click Checkout.
5. Fill out the customer information form and click to go to payment detail screen.
6. On the payment details screen, press the Tab key on the keyboard to get to the credit card number field.

You can’t. You also can’t tab through any of the other credit card field on the page. Tab cycling seems to be limited to the discount field and then to the chrome, address bar. Compare to Mac, where you can tab cycle through the entire form.

Comment 1 Radar WebKit Bug Importer 2019-03-20 21:06:36 PDT

<rdar://problem/49093034>

Comment 2 Daniel Bates 2019-07-01 13:38:03 PDT

Credit card fields are in an iframe. iOS hacks it to disallow iframes from being focusable: <https://trac.webkit.org/browser/trunk/Source/WebCore/html/HTMLIFrameElement.h?rev=246884#L54>

Why did we do this? Well it's because we didn't want a <iframe contenteditable="true"></iframe> to be focusable and for next/previous accessory bar buttons to allow focusing it.

Comment 3 Daniel Bates 2019-07-01 14:07:50 PDT

Created attachment 373262 [details]
For the bots

Comment 4 Daniel Bates 2019-07-01 14:56:59 PDT

Created attachment 373270 [details]
Patch

Comment 5 Daniel Bates 2019-07-01 16:38:31 PDT

Comment on attachment 373270 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=373270&action=review

> Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:2456
> +    if (is<HTMLIFrameElement>(node))

This requires me to pull in a header. I could just call node->isFrameOwnerElement() <-- this would also cover <embed>/<object>, which are not needed to be covered....  I waffled on which was better.... went with is<> like the existing code and it's more narrow... What do you think?

Comment 6 Chris Dumez 2019-07-01 16:44:30 PDT

Comment on attachment 373270 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=373270&action=review

>> Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:2456
>> +    if (is<HTMLIFrameElement>(node))
> 
> This requires me to pull in a header. I could just call node->isFrameOwnerElement() <-- this would also cover <embed>/<object>, which are not needed to be covered....  I waffled on which was better.... went with is<> like the existing code and it's more narrow... What do you think?

For what it's worth, the new include does not bother me but if you really want to avoid it, you can always if (node.hasTagName(HTMLNames::iframeTag)).

nit: While we're at it, can we rename node to element?

Comment 7 Daniel Bates 2019-07-02 10:08:21 PDT

Created attachment 373336 [details]
To land

Comment 8 Daniel Bates 2019-07-02 10:08:55 PDT

(In reply to Chris Dumez from comment #6)
> nit: While we're at it, can we rename node to element?

Ok.

Comment 9 Daniel Bates 2019-07-02 10:23:51 PDT

Committed r247056: <https://trac.webkit.org/changeset/247056>