Bug 226245

Summary:

Slot elements (Web Components v1) containing only digits bug

Product:

WebKit

Reporter:

timonson <timo.rossa>

Component:

JavaScriptCore

Assignee:

Nobody <webkit-unassigned>

Status:

NEW

Severity:

Normal

CC:

rniwa, webkit-bug-importer

Priority:

Keywords:

InRadar

Version:

Safari 14

Hardware:

iPhone / iPad

OS:

iOS 14

Bug Depends on:

Bug Blocks:

148695

Attachments:

Description	Flags
Check rendered elements and DOM in Dev Tools	none

timonson

Reported 2021-05-25 15:59:53 PDT

Created attachment 429704 [details] Check rendered elements and DOM in Dev Tools Sorry for posting it in the wrong place, I am new here. In the following reproduction I use the same Custom Element twice. Everything is the same but the content of the slot. First it contains an alphanumeric string and in the second example it contains a string containing digits. The second slot is not in the right place in the DOM and somehow rendered twice. You can see the difference immediately by noticing it has a text-decoration (underline), although it shouldn't have it. Please see the attached image. This bug happens on all latest Safari for iOS versions. It does NOT happen on Safari for Mac or any other browser. Reproduction: ```JavaScript <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8" /> <title>Shadow</title> <link rel="icon" href="data:," /> </head> <body> <script> customElements.define( "my-anchor", class extends HTMLElement { connectedCallback() { const shadow = this.attachShadow({ mode: "open" }) shadow.innerHTML = `<a><slot></slot></a><style> a{ text-decoration: none; font-size:20px; background:yellow;margin:20px;}</style>` } } ) </script> <my-anchor>01525 7010235</my-anchor> <my-anchor>abcde ferfdee</my-anchor> </body> </html> ```

Attachments
Check rendered elements and DOM in Dev Tools (119.91 KB, image/png) 2021-05-25 15:59 PDT, timonson	no flags	Details
View All Add attachment proposed patch, testcase, etc.

timonson

Comment 1 2021-05-25 16:08:33 PDT

What is even more confusing, if the slot element is rendered correctly also depends on the length of the digits string. But I can't determine a certain metric.

timonson

Comment 2 2021-05-25 21:16:51 PDT

When I was talking in OP about the first slot I meant the second slot and vice versa.

Radar WebKit Bug Importer

Comment 3 2021-06-01 16:00:19 PDT

<rdar://problem/78736879>

Ryosuke Niwa

Comment 4 2021-06-01 16:05:00 PDT

Ah, this is a data detector feature detecting those numbers as phone numbers & trying to turn it into a tel link.

timonson

Comment 5 2021-06-01 22:04:20 PDT

But this is not expected/desired behavior in this context, right?

Ryosuke Niwa

Comment 6 2021-06-01 23:14:40 PDT

(In reply to timonson from comment #5) > But this is not expected/desired behavior in this context, right? The fact the number is wrapped by an anchor element? That is Data Detector feature working as intended.

timonson

Comment 7 2021-06-01 23:51:25 PDT

Let me clarify my question: Although the Data Detector feature might be working as intended, is this really the desired behavior overall considering that no other browser is behaving like this? If it is I would appreciate a reference to the spec which defines it. Thanks!

Ryosuke Niwa

Comment 8 2021-06-01 23:54:53 PDT

(In reply to timonson from comment #7) > Let me clarify my question: Although the Data Detector feature might be > working as intended, is this really the desired behavior overall considering > that no other browser is behaving like this? If it is I would appreciate a > reference to the spec which defines it. Thanks! Well, it's a feature so that users can click on a phone number & be able to make a phone call easily. There isn't really any spec for this just like Chrome & Safari both support translation as a browser feature and replace page content when it's used.

timonson

Comment 9 2021-06-01 23:58:54 PDT

I think you have not fully understood the bug report yet what is probably my fault. Please replicate my example and you will see that the slot element with the phone number is fully taken out of the normal DOM context where a slot element should be. When you change the CSS you will see that one slot element reacts to CSS (not only text-decorator) and the other doesnt at all. Please take another look at the DOM context and where/how the slot elements are put differently.

Note You need to log in before you can comment on or make changes to this bug.