1577530 - No space should be between the username string and the truncation points

Status: VERIFIED FIXED

(Core :: Layout: Block and Inline, defect)

Description

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Attachment: space between username and truncation points.png

[Notes]:

• Based on the mock-us no space should be between the username string and the truncation points.

[Affected Versions]:

• Nightly 70.0a1

[Affected Platforms]

• All Windows
• All Mac
• All Linux

[Prerequisites]

• Have a Firefox profile with multiple logins saved.
• Have a saved login that has a very long username.

[Steps to reproduce]:

1. Open the latest Nightly browser with the profile from prerequisites.
2. Navigate to "about:logins" page.
3. Click on one of the saved logins that has a very long username.
4. Observe the username input.

[Expected results]:

• There is no space between the username string and the truncation points.

[Actual results]:

• There is a space between the username string and the truncation points.

[Additional Notes]:

• Attached a screenshot with the issue.

Comment 1

[Matthew N. [:MattN]]

Mass removing [skyline] and [passwords:management] from about:logins bugs which are no longer useful.

Comment 2

[kenrick95]

Looks like the size of the space really depends on what character is hidden due to the ellipsis ("..."). Looks like in an <input> element, the ellipsis is "fixed" at the right-most part of the box, leaving some "space" between the last visible character and that ellipsis so that the rest of characters are hidden. To see the difference in the width of this "space", one could try to input all-uppercase "M" vs all exclamation mark ("!") at the username field.

One possible solution I can think of is to display the username as a <div> instead of using <input> when it is not editable although this might have impact on other behavior that I'm unaware of.

Any thoughts on this matter? Thanks :)

Comment 3

[Sam Foster [:sfoster] (he/him)]

Attachment: inputEllipsis.html

test case, showing the right-aligned ellipsis.

Comment 4

[Sam Foster [:sfoster] (he/him)]

I'm not convinced this is worth fixing. I'm attached a test case showing this is just how the text-overflow works. Yes, we could workaround it by using a different element or something but I'm not sure its worth the trouble and additional complexity. Let's re-triage it.

Comment 5

[Sam Foster [:sfoster] (he/him)]

This looks to be how we handle text-overflow ellipsis in the type=text html input fields, not really about:logins specific.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

It seems the ellipsis is not accounting for the input padding, incorrectly.

Seems to work fine for regular elements:

data:text/html,<div style="overflow: hidden; white-space: nowrap; padding: 10px; text-overflow: ellipsis; width: 100px">Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa</div>

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1577530 - Cache theming values from nsTextControlFrame correctly. r=mats,#layout-reviewers

The issue is that nsTextControlFrame might have a different used padding
then the editing root block and thus the editing root's scrolled
content, etc, because its padding doesn't match the style.

This causes TextOverflow code to miscompute the content area size, which
is sadness and causes the overflow markers to go over the padding box.

The REFLOW_ROOT condition was introduced in bug 157846 and only
partially takes care of the issue. This fix supersedes it, so we can
remove it.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fd07538e1231
Cache theming values from nsTextControlFrame correctly. r=heycam

Comment 9

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/26931 for changes under testing/web-platform/tests

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5ef9fa2708b2
Remove the test since some themes seem to do weird stuff when padding is specified, and this is covered once non-native-theme is enabled.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/39661a82f9d2
Annotate a test that is 1px less fuzzy.

Comment 12

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/fd07538e1231
https://hg.mozilla.org/mozilla-central/rev/5ef9fa2708b2
https://hg.mozilla.org/mozilla-central/rev/39661a82f9d2

Comment 13

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 14

[Sam Foster [:sfoster] (he/him)]

For me (ubuntu, today's Nightly), the test case from attachment 9193306 [details] still has the same gap between the truncated value and the ellipsis.
As I said earlier, subjectively it looks fine to me, but FWIW the original issue and screenshot from comment #0 still reproduces. :emilio, is this by design, or should I file a new bug to follow up?

Comment 15

[Emilio Cobos Álvarez (:emilio)]

If you're seeing the same thing I do, you're just seeing the space that we can't fit from an a character. It's still not the same as before (where the ellipsis was positioned outside of the content box). But yeah, I guess we could try to align the ellipsis to the end of the text instead. Mind filing a follow-up bug?

Comment 16

[Ciprian Muresan [:cmuresan], Ecosystem QA]

Marking this as Verified based on comment 14 and comment 15. I've logged Bug 1844050 as a follow-up.