No space should be between the username string and the truncation points
Categories
(Core :: Layout: Block and Inline, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox-esr68 | --- | unaffected |
firefox68 | --- | unaffected |
firefox69 | --- | disabled |
firefox70 | --- | wontfix |
firefox86 | --- | fixed |
People
(Reporter: cmuntean, Assigned: emilio)
References
(Depends on 1 open bug, )
Details
Attachments
(3 files)
[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]:
- Open the latest Nightly browser with the profile from prerequisites.
- Navigate to "about:logins" page.
- Click on one of the saved logins that has a very long username.
- 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.
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 1•5 years ago
|
||
Mass removing [skyline] and [passwords:management] from about:logins bugs which are no longer useful.
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•4 years ago
|
||
test case, showing the right-aligned ellipsis.
Comment 4•4 years ago
|
||
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•4 years ago
|
||
This looks to be how we handle text-overflow ellipsis in the type=text html input fields, not really about:logins specific.
Assignee | ||
Comment 6•4 years ago
|
||
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>
Assignee | ||
Comment 7•4 years ago
|
||
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.
Updated•4 years ago
|
Comment 10•4 years ago
|
||
Comment 11•4 years ago
|
||
Comment 12•4 years ago
|
||
bugherder |
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 14•4 years ago
|
||
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?
Assignee | ||
Comment 15•4 years ago
|
||
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?
Updated•4 years ago
|
Comment 16•2 years ago
|
||
Marking this as Verified based on comment 14 and comment 15. I've logged Bug 1844050 as a follow-up.
Description
•