This looks a lot like the RenderText::GetCursorBounds()	regression seen in  issue 780670 . Trent, is it reasonable to apply a similar fix here?

I'm not sure whether the fix in  Issue 780670  can be used here.

There's a page fault required to load text-breaking rules from disk into memory whenever an input cursor needs to be rendered in a textfield. This must happen before text entry can occur in the omnibox. It's just a matter of when it's scheduled.

Avoiding the page fault during startup is kinda like threading a needle. To fix  Issue 780670 , I found a way to maintain that "threading" without regressing  Issue 739641 . I don't know if the same can be done in an elegant way for  Issue 789190  (which is what the culprit here - r521474 - was fixing).

Could we delay cursor positioning in the omnibox until we actually need it for text entry?

Currently this page fault is on the critical path for getting the first pixels on screen, and it appears to be affecting the top 10% of users particularly badly -- at the 90th %ile the regression is 180ms and at the 99th %ile it's 400ms. So I think it's worth expending a fair amount of effort to address this.

+skare for the omnibox question.

*** UI Mass Triage ***