Reply links seem to interfere with triple-click to select paragraph in Chrome
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	Esanders
	Aug 10 2020, 4:13 PM

Description

Triple click the paragraph beginning "Osobně se přejmenování..." on https://cs.wikipedia.org/wiki/Diskuse_k_Wikipedii:WikiProjekt_Olympi%C3%A1da#%C5%A0ablony_medailist%C3%A9

Observe that the "J" in the next comment is selected:

With the reply tool disabled, this works as expected:

Observed in Chrome on Ubuntu and by another user on Windows, but works fine in Firefox.

Update: Filed upstream: https://bugs.chromium.org/p/chromium/issues/detail?id=1116214

Details

	Subject	Repo	Branch	Lines +/-
	Undo inline-flex hack, fix alignment of buttons with text when wrapped	mediawiki/extensions/DiscussionTools	master	+17 -21
	Work around Chromium bug with triple-click selection and reply links	mediawiki/extensions/DiscussionTools	master	+4 -0

Customize query in gerrit

Related Objects

Mentioned In: T325416: Unexpected space before the Reply button when it wraps to a new line
T271645: Reply link is misplaced when a comment has U+2066 in a Arabic Wikipedia
T265291: The tool should add a blank line before comment

Event Timeline

Esanders created this task.Aug 10 2020, 4:13 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 10 2020, 4:13 PM

I can also reproduce this. It doesn't happen if you remove the user-select: none; property from the reply link container.

This is definitely a bug in Chrome, maybe we should just report it there.

I vaguely recall a similar bug happening with headings and section edit links? I don't remember how we fixed that.

Some experimenting shows that we can work around this by setting display: inline-flex; on the reply link container (but not display: inline-block;, huh).

Patriccck subscribed.Aug 10 2020, 4:38 PM

@matmarex can you foresee any negative consequences with the approach you proposed above in talking with @ppelberg he express the opinion that this should be moved to the backlog for now unless there is a straight forward fix?

Let's just file this upstream with Chromium for now.

Try it here: "Chtěné asi ne, ale jestli by se toto řešilo až dodatečně při dalším průchodu..." from Harold. The [reply] link is missing (because of missing signature) and it works.

In T260072#6380544, @Esanders wrote:

Let's just file this upstream with Chromium for now.

@Esanders / @matmarex: when one of y'all files this issue, can you please link to it on this task and then move it here https://phabricator.wikimedia.org/project/board/4358/ ?

I reported it: https://bugs.chromium.org/p/chromium/issues/detail?id=1116214

matmarex removed a project: Editing-team (Kanban Board).Aug 13 2020, 11:25 PM

In T260072#6384509, @matmarex wrote:

I reported it: https://bugs.chromium.org/p/chromium/issues/detail?id=1116214

Thank you, Bartosz.

Esanders updated the task description. (Show Details)Aug 14 2020, 10:15 PM

Urbanecm added a project: Upstream.Aug 15 2020, 11:39 AM

Urbanecm moved this task from Backlog to Reported Upstream on the Upstream board.

Quotation marks („ U+201E and “ U+201C) are not selected either.
https://cs.wikipedia.org/wiki/Wikipedie:Pod_l%C3%ADpou_(technika)#Reply_tool_%E2%80%93_bug?

@Draceane That is not related to this bug (and I think it's the expected behavior).

On that page (https://cs.wikipedia.org/wiki/Wikipedie:Pod_lípou_(návrhy)#Rozlišování_barev_infoboxů_českých_sídel_podle_země), the comment's author used the HTML tags <q>…</q> to mark the quotation, instead of actual quotation mark characters. The tags are displayed like quotation marks, but the actual characters don't exist in the text, and can't be selected. They behave similarly to the arrow icon shown next to external links (screenshot from the same page at the bottom):

I think we should just apply the workaround I mentioned in T260072#6373594, the Chromium bug report hasn't seen any action.

Change 631831 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/DiscussionTools@master] Work around Chromium bug with triple-click selection and reply links

https://gerrit.wikimedia.org/r/631831

gerritbot added a project: Patch-For-Review.Oct 2 2020, 5:25 PM

matmarex added a project: Editing-team (Kanban Board).Oct 2 2020, 5:26 PM

matmarex moved this task from Incoming to Code Review on the Editing-team (Kanban Board) board.

Change 631831 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Work around Chromium bug with triple-click selection and reply links

https://gerrit.wikimedia.org/r/631831

ReleaseTaggerBot added a project: MW-1.36-notes (1.36.0-wmf.12; 2020-10-05; NEVER DEPLOYED).Oct 2 2020, 8:00 PM

Maintenance_bot removed a project: Patch-For-Review.Oct 2 2020, 8:10 PM

matmarex moved this task from Code Review to Ready for Sign Off on the Editing-team (Kanban Board) board.Oct 2 2020, 8:20 PM

matmarex added a project: Skipped QA.

ppelberg closed this task as Resolved.Oct 3 2020, 1:40 AM

ppelberg claimed this task.

matmarex mentioned this in T265291: The tool should add a blank line before comment.Nov 10 2020, 6:36 PM

matmarex mentioned this in T271645: Reply link is misplaced when a comment has U+2066 in a Arabic Wikipedia.Jan 12 2021, 11:22 PM

matmarex mentioned this in T325416: Unexpected space before the Reply button when it wraps to a new line.Dec 17 2022, 2:44 PM

That is fixed upstream in Chromium/Chrome.

Change 891720 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@master] Undo inline-flex hack, fix alignment of buttons with text when wrapped

https://gerrit.wikimedia.org/r/891720

gerritbot added a project: Patch-For-Review.Feb 23 2023, 11:18 PM

Change 891720 merged by jenkins-bot: