1614689 - 0.12ms uninterruptible reflow at _ensureFormattedHostVisible/<@resource:///modules/UrlbarValueFormatter.sys.mjs:96:9

Status: NEW

(Firefox :: Address Bar, defect, P2)

Description

[Mike Conley (:mconley) (:⚙️) (PTO: May 27-31)]

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

[Drew Willcoxon :adw]

Is this caused by bug 1605889 or is it a more recent regression?

Comment 2

[Dão Gottwald [:dao]]

(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

[Marco Bonardo [:mak]]

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

Comment 4

[Marco Bonardo [:mak]]

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.