2015406 - using reply button in tiktok doesn't work

Status: NEW

(Web Compatibility :: Site Reports, defect, P2)

Description

[chavovaldez]

Attachment: chrome-good.jpg

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:147.0) Gecko/20100101 Firefox/147.0

Steps to reproduce:

Go to a Tiktok live comment box. Click on a users dropdown menu. Click on reply.

Actual results:

The cursor stays in place.

Expected results:

The cursor should dropdown to the comment box with the users name already there.

Comment 1

[chavovaldez]

The picture is from chrome. On chrome I did the exact same thing, click the user button, click reply. The cursor dropped down to the textbox with the users name already there.

Comment 2

[Monica Chiorean]

I was able to reproduce the issue on Win11x64 using Firefox build 147.0.3. On Firefox nothing happens if pressing reply, while on Chrome user is taken to commentbox with username already there. Simple reply works, but not @reply.
Marking issue as new.

Comment 3

[chavovaldez]

I have nightly and beta installed too.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:denschub, could you have a look please?

For more information, please visit BugBot documentation.

Comment 5

[Sky Schubert [:skyschub]]

We do ship an intervention for broken comments via bug 1769762, maybe that one broke? Ksenia, can you have a look?

Comment 6

[Ksenia Berezina [:ksenia]]

The username gets inserted into the "Reply" element (instead of contenteditable comment box), but since the "Reply" container is removed from the DOM, the username is removed as well. I created a somewhat minimal testcase, but there is still quite a lot going on. There is a cached range that is being reused across multiple methods, however after running focus on the contenteditable this cached range is changed to that of the contenteditable in Chrome, but in Firefox it's still reusing the cached version.

Comment 7

[Ksenia Berezina [:ksenia]]

Attachment: firefox-tiktok-minimal.html

Comment 8

[Ksenia Berezina [:ksenia]]

Hi Masayuki, wonder if you might have an idea if this is a known difference between Firefox and Chrome?

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 6/26-6/30))]

I guess when the user clicks the <button>, only Firefox collapse Selection into or around the <button>. Then, the rangeCount becomes 1 so that the behavior could be different.

Comment 10

[Thomas Wisniewski [:twisniewski]]

:masayuki, does it help to add a click event listener which calls event.preventDefault() if there is an event.target.closest("button") or such? If so, we could do that in our intervention as well while we further investigate (of course we'd want to target only the reply and other affected buttons, if possible).

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 6/26-6/30))]

Sorry, my guess was wrong. I check the behavior in the testcase, then, I see:

Firefox

1. saveRange() is called by the click listener to save the range selecting <button> content.
2. prepareSelection() is called by insertText() and call <div contenteditable>.focus().
3. saveRange() is called by the focus listener, however, the range is still select the <button> content.

Chrome

1. saveRange() is called by the click listener to save the range selecting <button> content.
2. prepareSelection() is called by insertText() and call <div contenteditable>.focus().
3. saveRange() is called by the focus listener, the range is in the <div contenteditable>.

Finally, prepareSelection restores the savedRange as the selection range and insertText inserts the given text. So, the testcase depends on the timing of the selection update when focus is moved to an editing host.

Currently, when we dispatch a focus event, HTMLEditor will handle the event after the content's listeners run. The reason of this order is, we treat the HTMLEditor's handling is a default action of the focus change. However, it seems that Chrome does not think so. They make their HTML editor initialize the things first (including Selection). In my understanding, our behavior is logically correct from the DOM event propagation model. Therefore, I'm afraid to change our behavior.

Smaug: WDYT?

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 6/26-6/30))]

Ah, but current spec defines focus event as:

A user agent MUST dispatch this event when an event target receives focus. The focus MUST be given to the element before the dispatch of this event type.

So, the Chrome's behavior sounds correct. On the other hand, our internal event listeners does the same thing as HTMLEditor IIRC. So, do we need to fire a internal focus event before the DOM focus event to make the extant focus listeners handle them before dispatching the DOM focus event??

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

We do move focus before focus event. Could editor just check if focus has already moved when doing something?

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 6/26-6/30))]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #13)

We do move focus before focus event. Could editor just check if focus has already moved when doing something?

The problem here is not "which element has focus when a focus event listener runs". The problem here is "focused element (including the editor) has not handled focus yet when a focus listener of web app runs".

Our C++ code handles "focus"/eFocus event at here (rough search results):

• HTMLInputElement stores the value at focus to fire change event later
• TextControlElement initializes Selection
• HTMLTextAreaEleemnt stores the value at focus to fire change event later
• The editors initialize Selection at focus event in the system event group
• nsDocViewerFocusListener switches active nsFrameSelection
• nsImageMap notifies <area>s of focus

In my understanding, at least some of them should've already been done before the first focus event listener in web content runs.

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

Well, then we can add the focus event listener to capture phase relevant Window's parent target. That way event can be handled sooner.

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 6/26-6/30))]

Ah, good approach for this for now even though it's not ideal fix. I'll be back when I'm back from PTO.

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 6/26-6/30))]

The reported bug itself is fixed by bug 2026022.

However, there is a trivial but annoying bug. That is, when you insert the account name from the menu item, the account name following @ is inserted with trailing ASCII space, . Then, we render the caret after the space, but typing a character will remove the space. This symptom is caused by the following historical issue.

• We paint the caret after the invisible space at end of the line (bug 1951041)
• TikTok assumes that contenteditable="plaintext-only" preserves the spaces because of Chrome's behavior, but it's not standardized (bug 1950671, bug 1962439, spec issue, Chromium's bug)

I think we need to contact TikTok to specify white-space-collapse: preserve.

Comment 18

[Thomas Wisniewski [:twisniewski]]

If you'd like, we can ship a webcompat intervention to achieve that?

Would this CSS be good enough (applied to https://www.tiktok.com/*)?

[contenteditable='plaintext-only'] { white-space-collapse: preserve }

Or would we not want to target all such contenteditables, perhaps?

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 6/26-6/30))]

Well, I'd love to enable it in TikTok. On the other hand, I don't disagree with aligning the default style to Chrome once it's (or it'll be) standardized.

zcorpan, WDYT about the intervention?

Comment 20

[chavovaldez]

I have nightly installed and this is working mostly right atm. The only problem is it doesn't add a space at the end.