2002920 - Drag-and-drop 5MB of text on an blank tab leads to recurring 4.5s jank on the parent-process, spending time in nsIURIFixup.getFixupURIInfo

Status: VERIFIED FIXED

(Firefox :: Search, defect, P1)

Description

[Mayank Bansal]

Attachment: p5.js

STR1:

1. Open the browser to a blank tab
2. Download the attached sample text to your local machine.
3. Open it in a local text editor. I used notepad++
4. Select all the text and drag-and-drop it to the empty "body" of the blanl tab

• AR: https://share.firefox.dev/4oFc6Nz

STR2:

1. Open the attached file in the browser
2. select all the text
3. Drag the text to the address-bar without releasing it.

• AR: https://share.firefox.dev/3Kpf3Dw

Comment 1

[Mayank Bansal]

Dragging it on the address-bar leads to recurring CPU use till infinity: https://share.firefox.dev/4ohO3DV

Comment 2

[Mayank Bansal]

Bisection:

Bug 1948636 - Change query parameter handling in EngineURL to be consistent, regardless of how the full URL is specified. r=Standard8

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

This is the second time this regression has occurred. Perhaps a test should be added.

Comment 3

[BugBot [:suhaib / :marco]]

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

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

For more information, please visit BugBot documentation.

Comment 4

[BugBot [:suhaib / :marco]]

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

Comment 5

[James Teow [:jteow]]

We saw this during our bug scrub, Moritz mentioned he's looking into this.

Comment 6

[James Teow [:jteow]]

Setting to P1 because Moritz is actively going to work on it.

Comment 7

[Moritz Beier [:mbeier]]

For me there seems to be similar jank when dragging the text over the urlbar on a build without the commit from bug 1948636 (8f0c55f22e7a3f95b6f73c00b7792c0dd413bc16^). Looking at 4oFc6Nz, getSubmission (the only function changed in bug 1948636) only accounts for 15% of the samples, so I'm not sure if that's really the regressor. Mayank Bansal, could you please attach a profile with a build without bug 1948636?

The main issue seems to be that we call getFixupURIInfo() for all of the 138k lines of the text here. getFixupURIInfo() is not super slow but calling it 138k times can take a few seconds. The XPConnect functions alone make up >10% of it so it might not even be possible to improve it significantly, although it might be possible to fully do it in JS once bug 1643008 is done.

I think it's a better idea to only search the first 1000 or so lines for URIs instead of trying to make getFixupURIInfo() faster.
:mak I think you are more familiar with the URI fixup code, what do you think?

Comment 8

[Marco Bonardo [:mak] (Away 10-21 August)]

(In reply to Moritz Beier [:mbeier] from comment #7)

I think it's a better idea to only search the first 1000 or so lines for URIs instead of trying to make getFixupURIInfo() faster.
:mak I think you are more familiar with the URI fixup code, what do you think?

From what I can tell this code is used to manage a list of URIs that is not properly presented as a uri-list.
Most common case may be:

# some comment
uri
# other comment
# another comment
uri

Or some more exotic:

# comment
uri
title

# comment
uri
title

Some rows may also be empty.
There's also the case where you copy paste from a page an inadvertently select some text before/after the uri.

I don't see why it should support super exotic cases like:

very long
text string
...
uri
more text
much long
string
...
uri

Thus, I think the loop could reasonably check how many non uri rows were examined from the last uri, if that becomes large enough (I'd use a reasonably low value, like 20), just bail out and assume the remaining content is not relevant.
That should still support exotic cases or copy pasting lines before/after a uri.

Then to hit the slow path, you should basically build the clipboard on purpose.

Comment 9

[Mayank Bansal]

This is a build from 2025-01-20, which has bug 1911022 fixed, and bug 1948636 has not landed yet.

Profiles: https://share.firefox.dev/4pAS47n , https://share.firefox.dev/4qrKhJB

Observations:

1. The time spent is ~1 second, whereas it now takes 7xs-8s
2. There is not jank, because if you move the drgged text away from the url bar, hte jank goes away. Now, if you drag the text even once, you will see a long jank of 7s-8s.

Hope this helps.

Comment 10

[Moritz Beier [:mbeier]]

Thanks for the profile. Looks like getFixupURIInfo gets called less often on your machine compared to mine on 136 release. One possible explanation could be that some line in the text is causing an exception that got fixed by bug 1948636.

Are there any errors or other messages in the browser console and what search engine are you using?

Comment 11

[Mayank Bansal]

Attachment: console-export-2026-1-4_7-38-6.txt

there are some errors in the console.
Build from 2025-01-20

Comment 12

[Moritz Beier [:mbeier]]

Thanks. Looks like bug 1948636 fixed an issue that aborted parsing the lines in the text one-by-one and thus made dragging faster.

I think the best approach to improve performance here is to stop trying to parse every line after finding enough non-URIs like :mak suggested.

Comment 13

[Moritz Beier [:mbeier]]

Attachment: Bug 2002920 - Stop parsing plaintext as URI list after finding enough non-URIs in ContentAreaDropListener. r?mak

Comment 14

[Moritz Beier [:mbeier]]

Attachment: Bug 2002920 - Stop parsing URIs in urlbar dragover listener. r?mak

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/cd909c576692
https://hg.mozilla.org/integration/autoland/rev/c601c6053d43
Stop parsing URIs in urlbar dragover listener. r=mak,urlbar-reviewers

Comment 16

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/c601c6053d43

Comment 17

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:mbeier, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox148 to wontfix.

For more information, please visit BugBot documentation.

Comment 18

[Marco Bonardo [:mak] (Away 10-21 August)]

The second part still has to land, reopening until then

Comment 19

[Moritz Beier [:mbeier]]

For the record: the issue this bug is about (dragging) should be fully fixed by just the patch that already landed. The second patch will only improve the performance when dropping a very large text on the urlbar or tab switcher.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/5f1374405c2c
https://hg.mozilla.org/integration/autoland/rev/ba5186c183b5
Stop parsing plaintext as URI list after finding enough non-URIs in ContentAreaDropListener. r=mak

Comment 21

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/ba5186c183b5

Comment 22

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Reproducible on a 2026-01-19 Firefox Nightly build on Windows 10.

Verified as fixed on Firefox Nightly 149.0a1 on Windows 10, macOS 15 and Ubuntu 22.