1705871 - In some cases, the last letter of the bookmark name isn't visible in the bookmark doorhanger

Status: NEW

(Core :: Layout: Scrolling and Overflow, defect, P3)

Description

[tgn-ff]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

1. Open a site and set it as a bookmark.
2. Click at the start button in the urlbar and change its name to WWWWWWWWWWWWWWWWWWWWWWWE. This step is sensitive to font/size. You have to either set your font to ubuntu at 10pt, or try another string or sentence.

Actual results:

The last letter of the string doesn't show at all. You cannot scroll the text to see it by moving the keyboard indicator with the arrow keys, for example. In other strings the letter might be partially visible.

Expected results:

It should be possible to see the entire string by moving with the keyboard indicator.

Comment 1

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

:tgnff242, if you think that's a regression, could you try to find a regression range using for example mozregression?

Comment 2

[tgn-ff]

I don't think it's a regression, but I can only reproduce it with proton doorhangers enabled. Even if it were, this is an edge case that depends on font size, text field size etc, I couldn't be sure that a good build is actually good.

Comment 3

[Alex Cornestean]

Hello,

I reproduced the issue only on the latest Nightly (90.0a1/20210419221626) and Beta (89.0b1/20210419195043) under Windows 10 x64 and Ubuntu 16.04 LTS using this particular string WWWWWWWWWWWWWWWWWWWWWWWE . Tested the latest Release (88.0/20210415204500) as well, but the issue does not occur there. As such it seems it’s an issue introduced with the new Proton UI.

As mentioned in the description of the issue, the last letter of the string is not visible and it cannot be scrolled using the arrow keys. Replacing the above string with WWWWWWWWWWWWWWWWWWWWWWWe or WWWWWWWWWWWWWWWWWWWWWWww will make it so that the last letter is only partially visible.

Comment 4

[Alex Cornestean]

Attachment: 2021-04-20_12h28_40.png

Comment 5

[Tyler Duzan]

Thank you for the report. Due to this being such a specifically triggered corner case I'm setting this as a P3, but I would like to see if we can assess this to ensure that the impact isn't more widespread than it appears. I'm not sure who off the top should dig in, but I'll needinfo mconley to see if he can find someone to take a look and verify that this is as edge as it appears.

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Neil recently worked on this input field. Perhaps he knows?

Comment 7

[Neil Deakin]

I looked into this a bit. It looks like we are returning early at https://searchfox.org/mozilla-central/rev/4648b6ee31c2519b1753023e4f4853b14fdd16e5/layout/base/PresShell.cpp#3474 because ComputeWhereToScroll returned the same value as the original point, so no scrolling occurs.

Earlier, nsIScrollableFrame::GetScrolledRect() is returning a smaller rectangle than the rectangle being scrolled into view. So this seems like some issue either computing the rectangle size or new scroll position.

Comment 8

[Neil Deakin]

Going to move to the scrolling component for now.

Comment 9

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

The product::component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 10

[Jonathan Kew [:jfkthame]]

This seems to be related to the use of padding on the text-field. A reduced testcase that reproduces the problem for me on Win10:

data:text/html,<input style="padding:12px; width:100px" value="WWWWWWE">