STR:

• 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".

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

Failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&fromchange=a16ab9d38fe748d125dad628afd99d442185f9e5&selectedJob=239096813

https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=239096813&repo=autoland&lineNumber=5847

[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

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

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

Can this have caused https://bugzilla.mozilla.org/show_bug.cgi?id=1544221? Its exactly broken Adress Bar on Linux.

While trying to verify this issue and I've stumbled on the fact that very long URL (e.g. https://lifehacker.com/freaking-huge-url-lengthens-too-short-links-5193013) 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)

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

Environment:

          (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.