0.12ms uninterruptible reflow at _ensureFormattedHostVisible/<@resource:///modules/UrlbarValueFormatter.sys.mjs:96:9
Categories
(Firefox :: Address Bar, defect, P2)
Tracking
()
Performance Impact | low |
People
(Reporter: mconley, Unassigned)
References
(Regression)
Details
(Keywords: perf, perf:frontend, regression, Whiteboard: [ohnoreflow][snt-scrubbed][search-performance])
Here's the stack:
_ensureFormattedHostVisible/<@resource:///modules/UrlbarValueFormatter.jsm:96:9
Version: 75.0a1
Build: 20200211094607
That's this line: https://searchfox.org/mozilla-central/rev/7e92a667e3829831c31e8d46aefe7ef67ad5be1c/browser/components/urlbar/UrlbarValueFormatter.jsm#96
Comment 1•5 years ago
|
||
Is this caused by bug 1605889 or is it a more recent regression?
Updated•5 years ago
|
Comment 2•5 years ago
|
||
(In reply to Drew Willcoxon :adw from comment #1)
Is this caused by bug 1605889 or is it a more recent regression?
Most likely bug 1605889.
Comment 3•5 years ago
•
|
||
We're setting scrollLeft, we're in a RAF, we likely need a promiseDocumentFlushed.
note: in the past having both may have caused unexpected misbehavior of the scrolling position, so any change should be manually verified against short, long, short_rtl, long_rtl, short_rtldomain, long_rtldomain URIs, and switching across tabs containing those. (we do have an automated test, but it may not catch every edge case).
Updated•5 years ago
|
Updated•5 years ago
|
Updated•4 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 4•2 years ago
|
||
Rather than bringing on this madness with urls that can fade either left or right depending on the origin, we should investigate adding an invisible LTR forcing character when we remove the protocol (whether it's http or https), that would allow us to remove most of the complexity and work we do here to ensure the origin is visible, the origin would always be at the start.
Updated•1 year ago
|
Updated•1 year ago
|
Description
•