Closed Bug 1540861 Opened 5 years ago Closed 5 years ago

Autocompleting long data URIs is slower with Quantumbar enabled


(Firefox :: Address Bar, defect, P1)




Firefox 68
Tracking Status
firefox68 --- verified
firefox69 --- verified
firefox70 --- verified


(Reporter: ntim, Assigned: mak)



(Keywords: perf)


(1 file, 1 obsolete file)


  • Have a long data URI in the history
  • type letters that are in that data URI in the address bar

Quantumbar's view freezes a bit to render the data URI.

In comparison, the legacy view takes a lot less time to render it.

I suspect we didn't implement some optimization, in the old implementation we cut the size of text runs to "textRunsMaxLen".

Points: --- → 1
Priority: -- → P1
Assignee: nobody → dao+bmo
Keywords: perf
See Also: → 907001
Assignee: dao+bmo → nobody
Attachment #9055442 - Attachment is obsolete: true
Assignee: nobody → mak77
Pushed by
Limit the length of titles and URLs we display so layout doesn't spend too much time building text runs. r=dao

Backed out changeset d389f6f9743e (Bug 1540861) for causing perma failing bc7 failures in browser/components/urlbar/tests/browser/browser_UrlbarInput_tooltip.js


[task 2019-04-09T16:10:42.829Z] 16:10:42 INFO - TEST-START | browser/components/urlbar/tests/browser/browser_UrlbarInput_tooltip.js
[task 2019-04-09T16:11:27.845Z] 16:11:27 INFO - TEST-INFO | started process screentopng
[task 2019-04-09T16:11:28.312Z] 16:11:28 INFO - TEST-INFO | screentopng: exit 0
[task 2019-04-09T16:11:28.314Z] 16:11:28 INFO - Buffered messages logged at 16:10:42
[task 2019-04-09T16:11:28.314Z] 16:11:28 INFO - Entering test bound
[task 2019-04-09T16:11:28.314Z] 16:11:28 INFO - Buffered messages finished
[task 2019-04-09T16:11:28.315Z] 16:11:28 INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_UrlbarInput_tooltip.js | Test timed out -
[task 2019-04-09T16:11:28.316Z] 16:11:28 INFO - GECKO(6096) | MEMORY STAT | vsize 2009MB | residentFast 357MB | heapAllocated 123MB
[task 2019-04-09T16:11:28.317Z] 16:11:28 INFO - TEST-OK | browser/components/urlbar/tests/browser/browser_UrlbarInput_tooltip.js | took 45023ms
[task 2019-04-09T16:11:28.318Z] 16:11:28 INFO - checking window state
[task 2019-04-09T16:11:28.319Z] 16:11:28 INFO - TEST-START | browser/components/urlbar/tests/browser/browser_UrlbarInput_unit.js
[task 2019-04-09T16:11:28.327Z] 16:11:28 INFO - GECKO(6096) | MEMORY STAT | vsize 2010MB | residentFast 362MB | heapAllocated 131MB
[task 2019-04-09T16:11:28.328Z] 16:11:28 INFO - TEST-OK | browser/components/urlbar/tests/browser/browser_UrlbarInput_unit.js | took 252ms
[task 2019-04-09T16:11:28.328Z] 16:11:28 INFO - checking window state
[task 2019-04-09T16:11:28.328Z] 16:11:28 INFO - TEST-START | browser/components/urlbar/tests/browser/browser_UrlbarLoadRace.js
[task 2019-04-09T16:11:28.822Z] 16:11:28 INFO - Not taking screenshot here: see the one that was previously logged
[task 2019-04-09T16:11:28.824Z] 16:11:28 INFO - Buffered messages logged at 16:11:28
[task 2019-04-09T16:11:28.825Z] 16:11:28 INFO - Entering test bound setup
[task 2019-04-09T16:11:28.826Z] 16:11:28 INFO - Leaving test bound setup
[task 2019-04-09T16:11:28.827Z] 16:11:28 INFO - Entering test bound test_location_change_stops_load
[task 2019-04-09T16:11:28.828Z] 16:11:28 INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_UrlbarLoadRace.js | should have called getShortcutOrURIAndPostData - true == true -
[task 2019-04-09T16:11:28.829Z] 16:11:28 INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_UrlbarLoadRace.js | Should have not attempted to open the shortcut page - true == true -
[task 2019-04-09T16:11:28.830Z] 16:11:28 INFO - Leaving test bound test_location_change_stops_load
[task 2019-04-09T16:11:28.834Z] 16:11:28 INFO - Entering test bound test_opening_different_tab_with_location_change
[task 2019-04-09T16:11:28.835Z] 16:11:28 INFO - Buffered messages finished
[task 2019-04-09T16:11:28.836Z] 16:11:28 INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_UrlbarInput_tooltip.js | Uncaught exception received from previously timed out test - at chrome://mochitests/content/browser/browser/components/urlbar/tests/browser/browser_UrlbarInput_tooltip.js:18 - TypeError: BrowserTestUtils is null
[task 2019-04-09T16:11:28.837Z] 16:11:28 INFO - Stack trace:
[task 2019-04-09T16:11:28.838Z] 16:11:28 INFO - synthesizeMouseOut@chrome://mochitests/content/browser/browser/components/urlbar/tests/browser/browser_UrlbarInput_tooltip.js:18:17
[task 2019-04-09T16:11:28.838Z] 16:11:28 INFO - @chrome://mochitests/content/browser/browser/components/urlbar/tests/browser/browser_UrlbarInput_tooltip.js:70:9
[task 2019-04-09T16:11:28.839Z] 16:11:28 INFO - Async*Tester_execTest/<@chrome://mochikit/content/browser-test.js:1116:34
[task 2019-04-09T16:11:28.839Z] 16:11:28 INFO - Tester_execTest@chrome://mochikit/content/browser-test.js:1144:12
[task 2019-04-09T16:11:28.840Z] 16:11:28 INFO - nextTest/<@chrome://mochikit/content/browser-test.js:1005:14

Flags: needinfo?(mak77)
Backout by
Backed out changeset d389f6f9743e for causing perma failing bc7 failures in browser/components/urlbar/tests/browser/browser_UrlbarInput_tooltip.js

ok, off-hand it looks like failing only on Linux x64 shippable opt

Flags: needinfo?(mak77)
Pushed by
Limit the length of titles and URLs we display so layout doesn't spend too much time building text runs. r=dao
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68

Can this have caused Its exactly broken Adress Bar on Linux.

Flags: qe-verify+
QA Contact: aflorinescu

While trying to verify this issue and I've stumbled on the fact that very long URL (e.g. don't even get saved in history. However, the very long url from the example is displayed on the autocomplete with "switch tab" option while another tab has it.
Is there a limit of URL length when saving/populating history? Also, it would be useful to know what "long" url actually means?
The above is reproducible with both awesome/quantum-bar. (tried with a nightly build right before and after the fix)

Flags: needinfo?(mak77)

Yes, there is a url length limit that is defined as const DB_URL_LENGTH_MAX = 65536;

Flags: needinfo?(mak77)


          (affected baseline) 68.0a1   20190402214908
          (fixed)69.0b3 20190708182549
          (fixed)68.0     20190705220548
          (fixed)70.0a1 20190711230342

Further discussing with :mak , I've setup a profile that would have the default limit for URL length modified to 60k (places.history.maxUrlLength=60000) - default value being 2000. After that I've used "freaking huge url" to generate a few ~8k chars URLs. Also, using the same method, added a few custom bookmarks with 60k+ chars URLs.

Using the above profile, I've then reproduced the initial reported behavior prior to this fix on affected version 68.0a1 - 20190402214908 on which quantum bar is defaulted to false (so in order to reproduce, the pref. browser.urlbar.quantumbar needs to be manually turned on to true).

Afterwards, I've then verified the fixed versions (see Environment) on Ubuntu 16.04, Osx 10.13.6, Windows 10 build 1903 and as they don't exhibit the obvious stuttering that can be noticed on the affected baseline (68.0a1 20190402214908/quantum on), we can consider this issue verified fixed.

Flags: qe-verify+
OS: Unspecified → All
Hardware: Unspecified → Desktop
You need to log in before you can comment on or make changes to this bug.