WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
196053
[iOS] Cannot tab cycle through credit card fields on antonsvpatisserie.com checkout page
https://bugs.webkit.org/show_bug.cgi?id=196053
Summary
[iOS] Cannot tab cycle through credit card fields on antonsvpatisserie.com ch...
Daniel Bates
Reported
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.
Attachments
For the bots
(1.95 KB, patch)
2019-07-01 14:07 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
Patch
(8.77 KB, patch)
2019-07-01 14:56 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
To land
(9.93 KB, patch)
2019-07-02 10:08 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2019-03-20 21:06:36 PDT
<
rdar://problem/49093034
>
Daniel Bates
Comment 2
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.
Daniel Bates
Comment 3
2019-07-01 14:07:50 PDT
Created
attachment 373262
[details]
For the bots
Daniel Bates
Comment 4
2019-07-01 14:56:59 PDT
Created
attachment 373270
[details]
Patch
Daniel Bates
Comment 5
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?
Chris Dumez
Comment 6
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?
Daniel Bates
Comment 7
2019-07-02 10:08:21 PDT
Created
attachment 373336
[details]
To land
Daniel Bates
Comment 8
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.
Daniel Bates
Comment 9
2019-07-02 10:23:51 PDT
Committed
r247056
: <
https://trac.webkit.org/changeset/247056
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug