As this being a Non-Regression issue, changing the status to Untriaged so that the issue would get addressed.

Thank You!

Blinking actually works fine normally. However, when the bug reporter clicked the "System" link in the PDF, between steps 1 and 2, the blinking stops.

The page number text box is WebUI, so we'll need to ask Blink folks about text box blinking behavior.

Mark WontFix since this works as expected. The page number box has range selection instead of caret.

When moving focus to <input>, Blink selects all text in <input> to make range
selection == caret is not displayed.

Demo: https://jsfiddle.net/3odfumtp/1/

yosin: But at ~20 seconds in the video, there is no text in the box. If there's no text to select, shouldn't the caret start blinking again?

yosin: See comment 5. Basically, once the blinking stops, it never starts again.

Mark Untriaged since I could reproduce.

thestig@: I watched the video and try again on canary. 
I could reproduce when ominbox doesn't show candidate list after pressing tab.

It seems Tab navigation from outside chrome doesn't set PDF toolbar (in WebUI) active state.
When I click page number box then press left/right arrow key, caret starts blinking.

Note: When I attempt to use data:text/html,<input value="22"> with empty omnibox, caret doesn't stop blinking.

What controls the active state here? Maybe this is a guest_view issue?

drive-by: it looks like this bug thread was abandoned, likely unintentionally.

thestig@, can you pick up this up again and route it to an appropriate owner?

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.