1827778 - Errors when editing very long URLs

Status: NEW

(Core :: Graphics, defect)

Description

[Martin Thomson [:mt:]]

STR:

1. Go to https://bug1824470.bmoattachments.org/attachment.cgi?id=9328248
2. Copy the ridiculously long URL you find there (it's ~200k in length)
3. Paste it into the address bar (and hit enter)
4. Focus the address bar and hit the End key to try to edit the last few characters

What should happen

It's a text field, you go to the end and edit it

What really happens

I get different behaviour depending on which browser I use. Both are Firefox 114, Nightly, Windows 11. One potentially relevant distinction is that they use different graphics cards (Intel vs. Nvidia).

One (Intel) has a very annoying off-by one error, where the cursor appears to be in one place, but it is offset by one character. Consequently, I find it very difficult to edit things because I end up typing in the wrong place. The last few characters disappear under the icons that are drawn at the end of the address bar (ellipsis, pocket, bookmarks in a clean profile), which might match the amount that the cursor is offset.

The other (Nvidia) places the cursor at the end of the URL, but doesn't render any characters at all. The entire address bar appears to be empty.

In both cases, editing works. As long as the visual feedback is ignored, adding and removing characters according to what keys were pressed as though everything were normal. Arrows keys, selection, and copy-paste works fine with the cursor moving as expected, it is just the characters that aren't being displayed correctly.

I've verified in a clean profile on both machines.

Comment 1

[Daniel Holbert [:dholbert]]

I think this is fundamentally a limitation of our text layout/rendering code. This shows up in e.g. view-source of the giant-data-URI testcase as well. (For me, when I scroll all the way to the right, I see a bunch of blank space before </title> but if I select a region of that blank space and copy to my clipboard, I get actual a characters.)

I think we have bugs open on this or something similar, particularly for the view-source scenario (where it's common to have a gazillion characters on a single line in e.g. a minified JS file), so this might be a dupe of one such bug.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (just with an `input` element)

Here's a testcase like the STR but just using an input element. When I focus it and press 'end', I see blank space at the end, though I can still edit/copypaste the characters (which are in fact mostly a characters even though they don't paint).

Comment 3

[Daniel Holbert [:dholbert]]

(My graphics card is from AMD, by the way. I think the symptoms that I'm seeing are the same as the symptoms that martin described on his NVIDIA configuration.)

Comment 4

[Martin Thomson [:mt:]]

That's a helpful test case. In Edge, they have a similar problem. The text renders, but what looks like a bunch of trailing spaces ends up being the end of the string when you copy and paste it elsewhere. (e.g., Focus, End, Shift-Left a few times, Ctrl-C, Ctrl-A, Ctrl-V)

Comment 5

[Martin Thomson [:mt:]]

Attachment: view-source.png

I don't know if this is helpful, but it shows up some interesting artifacts. It's a shot of view-source from testcase 1. I've highlighted the last three characters ("End"), which then seem to vanish (they are just re-rendered in white). Maybe you can count pixels here to learn something about what is going on.

Note also that while this is monospace rendering, the problem is the same. Also, text after the offending <span> renders fine.

Also also, selecting text is offset from the rendered characters. Though it is monospaced, the selection doesn't always line up with the characters as they are rendered. There seems to be some sort of cumulative drift, so it is fine in some places, but not others.

Comment 6

[Jonathan Kew [:jfkthame]]

I think this is similar to bug 1726431, too -- rendering (positioning of the content) starts to get erratic at sizes beyond 16M device pixels. That bug talks about extremely tall pages, but the same issue applies in both x and y dimensions.

I get different behaviour depending on which browser I use. Both are Firefox 114, Nightly, Windows 11. One potentially relevant distinction is that they use different graphics cards (Intel vs. Nvidia).

Do they have different resolution (system-level scaling)? That would affect the device-pixel dimensions of what we're trying to render, and so would likely result in different behavior.

Comment 7

[Martin Thomson [:mt:]]

Oh yes, good call. The Intel box has a screen with DPR 2, the Nvidia is on a DPR 1 screen.

Comment 8

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

The severity field is not set for this bug.
:lsalzman, could you have a look please?

For more information, please visit auto_nag documentation.