1884355 - Substack's "share quote" functionality doesn't consistently work on Firefox.

Status: NEW

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

Description

[Emilio Cobos Álvarez [:emilio]]

(Doesn't look like a regression, at least it repros back to 98)

STR:

• Go to any substack page. I went to the first article of the first featured page: https://www.realtimemandarin.com/p/get-your-mandarin-skills-up-to-date
• Select some article text. A "share quote" button should pop up.

ER:

• The selected text is displayed in the quote.

AR:

• Depending on how you select it, the quote is sometimes not there.
• In particular, if I triple-click to select a whole paragraph, the quote is always empty.

This seems to work on both Safari and Chrome.

cc'ing some folks that might know off-hand what might be different.

Comment 1

[Emilio Cobos Álvarez [:emilio]]

Attachment: Test-case.

I think this is probably a difference on how we position the selection ranges on triple-click.

In Firefox, I get:

[0] start: P@0, end: P@1

In Chrome and WebKit I get:

[0] start: #text@0, end: P@0

Which doesn't make any sense to me? Our behavior seems reasonable off-hand. We're positioned at the start of the paragraph all the way until the end of the paragraph. WebKit and Blink somehow have an end node before the start? Or they interpret the selection spec differently...

Masayuki, are you familiar with this? am I missing something?

Per https://dom.spec.whatwg.org/#boundary-points it seems our behavior should be correct... I don't see how the WebKit behavior makes sense.

Comment 2

[Emilio Cobos Álvarez [:emilio]]

Ah, so the thing I was missing is that P@0 is the next paragraph in WebKit. So the behavior makes sense at least.

Comment 3

[Emilio Cobos Álvarez [:emilio]]

If I manually position the selection on the page to match blink with:

sel.getRangeAt(0).setStart(sel.getRangeAt(0).startContainer.firstChild, 0)
sel.getRangeAt(0).setEnd(sel.getRangeAt(0).endContainer.nextElementSibling, 0)

Then the functionality works... So I think this is likely a bug in how substack is using the selection API... Will try to contact

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Well, it seems that if I select a paragraph without triple click, it works (I tested on Android). So I guess that they check the start boundary is in a text node. It could be fixable in our side, but I don't think it's reasonable unless Chrome/Safari excludes invisible spaces at start/end of the paragraph since drill-down at the boundaries is additional cost without reasonable result change.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I wonder why don't they use stringify method of Selection simply...

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Nod. I contacted them, and told them to reach back if it happens to be a Firefox bug, but so far it seems it's just a bug on their end.