1866710 - clicking on the address bar janks the browser for 500ms if you have copied large text outside of the browser

Status: NEW

(Firefox :: Address Bar, defect, P2)

Description

[Mayank Bansal]

STR:

1. Open the following sample text file in your local text editor
2. copy all its content (ctrl+c)
3. Open the browser
4. Click on the address bar

AR: The browser hangs for 500ms on my machine
ER: Not so

Regression range:
Bug 1860548 - Enable the URL Paste Suggestion feature by default in Nightly. r=mak

Differential Revision: https://phabricator.services.mozilla.com/D191868

Profile of clicking on the address bar : https://share.firefox.dev/47LpO9k
Bigger the copied text, longer is the jank.

Opening of the settings page is also slow:
Bad : https://share.firefox.dev/3sK4CSu
Good: https://share.firefox.dev/3SSkc9c

In general, it maybe feels like the browser is periodically janking
The caveat being that copying large texts may be an edge case.

Comment 1

[Mayank Bansal]

Attachment: PolymerJS_pretty.7z

Comment 2

[Mayank Bansal]

2.5s jank if you have copied a 90MB text file : https://share.firefox.dev/3QQVu6q

Comment 3

[Mayank Bansal]

Attachment: ridiculuous_huge.7z

Comment 4

[Mayank Bansal]

Attachment: about:support

Comment 5

[Mayank Bansal]

With the preference browser.urlbar.clipboard.featureGate = true, the regression range points to bug 1846028

Comment 6

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

Set release status flags based on info from the regressing bug 1860548

:klubana, since you are the author of the regressor, bug 1860548, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 7

[Marco Bonardo [:mak]]

60% of the time is spent in SanitizeTextFromClipboard, it's likely we can just give up if the data is longer than a meaningful size (I'd guess 2048 could be a good start) and return false from isActive
The other time is spent in readFromClipboard, though I don't see anything in the DataTransfer definition to read the size of the data without getting it, or check the size of the clipboard in general. We may ask someone from platform how complex would it be to get at least an estimate of the clipboard size, though from a quick glance at the MS documents I can't find an API for that.

Comment 8

[Marco Bonardo [:mak]]

Molly do you know if the OS API can be used to guess the size of the data in the clipboard, or the whole clipboard itself, without actually getting the data?

Comment 9

[Molly Howell (she/her) (mostly inactive)]

We sort of can; only sort of, but I think well enough to help with this case.

Unfortunately the "size of the clipboard" is not a meaningful concept in general, because the clipboard can contain the same data in multiple formats at once (which all have different sizes and are requested entirely separately from one another), and also because the content can be generated just-in-time, so even the size of one specific format may not be known at all until it is requested.

What we can do is request the size of the object we're going to copy, and in fact we do because we need to know that in order to copy it. That happens after the data has already been generated (in this case meaning the OS has copied it to something mapped in our address space), but it sounds like that should be plenty early to save most of the effort that we're talking about here, unless I'm misinterpreting. The challenge then is just to get that information piped back up to where the decision needs to be made.