1771501 - Copy/Paste from southwest.com adds extra characters (since Firefox considers the adjacent "height:0; overflow:hidden" element to be selectable, while other browsers do not)

Status: NEW

(Core :: DOM: Selection, defect)

Description

[jt]

Attachment: 2022-05-27 08_50_23-southwest.png

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

Steps to reproduce:

Log into southwest.com > My Account (top) > Profile Details > copy (ctrl-c) the known traveler number or rapid rewards number after double-click to select.

Actual results:

On the clipboard, a character gets added to the front. Rapid rewards is all numerical, known traveler number is alphanumeric. Confirmed behavior on at least two machines in Firefox. Not happening in Chrome or Edge.

Expected results:

Correct text without extra character should be copied to clipboard.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Daniel Holbert [:dholbert]]

Thanks! I can reproduce the issue (using "known traveler number")

What's going on is:

• Southwest actually has two copies of this information in two back-to-back span elements, with the first span intended for screen readers and being hidden (via clip styling).
• The first (hidden) one has spaces between each character (presumably to make it easier for screen readers to read out individual characters rather than interpreting it as a word).
• When you double-click to select the one that you can see (the second span), you select back to the most recent space, which ends up including the final character of the invisible screen-reader version.

Our behavior makes some amount of sense, but Chrome does seem to behave differently, so it's definitely worth investigating further...

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Here's a reduced testcase, using Southwest's full .swa-g-screen-reader-only style rule for the first span.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

Here's a further reduced testcase. It looks like essentially Chrome is just making overflow:hidden;height:0 content wholly unselectable (i.e. it doesn't even show up in Select All operations)

That seems a bit surprising/unexpected. I wonder if this is intentional or just a side effect of some optimization they're performing to avoid generating layout boxes for such content (for example).

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (test using select-all / Ctrl+A)

Here's a testcase to demonstrate that Chrome is simply not considering this element to be selectable at all (rather than e.g. doing some fancy heuristics to determine appropriate bounds for double-click-to-select operations).

If you select-all in this testcase and copypaste, Firefox copies the hidden text "PASS" but Chrome does not.

Comment 7

[Daniel Holbert [:dholbert]]

FWIW Safari matches Chrome's behavior here. Also, Chrome hasn't changed this behavior recently; I tried e.g. Chrome 40 and it matches current results (they don't copy 'PASS' in testcase 3 unless I use a nonzero height on the .test div). So: if this is a quirk on their side, it's a long-standing one, maybe dating back ~forever or at least before the webkit fork.

Our behavior also hasn't changed recently (so this is not a regression); I tried Nightly 2015-11-23 (Firefox 45 Nightly) and it matches current Nightly on all three attached testcases.

Comment 8

[Dennis Schubert [:denschub]]

This seems like a WebCompat P3 for now, as it is a niche edge-case that's just annoying but not really breaking anything. However, CC'ing Masayuki, just for visibility - this is another issue with selections.

Comment 9

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Changing the severity according to comment 8.