Looks like this was reported on 60.0.3112.90 on Mac.

I can't seem to repro on Mac or Windows 64.0.3261.0, using the following steps:
1) Start Chrome with --site-per-process.
2) Visit http://csreis.github.io/tests/cross-site-iframe.html
3) In DevTools, run:
navFrame("https://csreis.github.io/tests/form-post.html")
4) Verify caret works in the OOPIF's input box.
5) Kill the subframe process in Chrome's task manager and observe the sad frame.
6) Switch DevTools back to the top frame (in the console tab), then run the command from step 3 again.
7) Try to give focus to the input box.

I see the caret, unlike in the video.

ekaramad@, can you check whether the original bug is gone on your test page?  If so, feel free to close the bug.

I double checked this on Canary 64.0.3279.0.

a) Following the steps bug description, I confirm the bug exists (caret not shown).
b) Following the steps in comment #1 I do see the caret.

creis@: Wouldn't the navigation path be somehow different. What I am doing here is setting window.location to the same URL. I think the codepath for devtools should be different and maybe even browser initiated?

To me it looks like calling RenderWidgetHostView::Show is solving the problem (switching tabs). So it could be (random guess) a visibility issue).

I investigated a bit more and I think the issue is page focus. Specifically, in steps in comment #1 going from devtools to the page resets page focus for all site instances. This does not happen when I use javascript in parent frame to renavigate a crashed frame.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4b1c41f9c900466955056635ebe5259add8575d0

commit 4b1c41f9c900466955056635ebe5259add8575d0
Author: Ehsan Karamad <ekaramad@chromium.org>
Date: Mon Dec 11 20:04:42 2017

Update page focus for re-navigated crashed OOPIFs

When a crashed OOPIF is navigated again the RenderWidget is recreated but
RenderWidgetHost is reused. Therefore RenderWidgt assumes no page focus while
RenderWidgetHost might be focused. This leads to caret not showing for a focused
input (and the text area no being highlighted).

This CL adds a method to RenderFrameHostManager to ensure page focus consistency
similar to page visibility.

Bug:  752140 
Change-Id: I1baaaa6c4b2c720a73f1cb72a3ad80e30e9036dc
Reviewed-on: https://chromium-review.googlesource.com/818732
Reviewed-by: Ehsan Karamad <ekaramad@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Ehsan Karamad <ekaramad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523180}
[modify] https://crrev.com/4b1c41f9c900466955056635ebe5259add8575d0/content/browser/frame_host/render_frame_host_manager.cc
[modify] https://crrev.com/4b1c41f9c900466955056635ebe5259add8575d0/content/browser/frame_host/render_frame_host_manager.h

ekaramad@ Could you please provide any sample test case file with OOPIF which has an <input> box to verify this issue from Chrome-TE end?

Thanks!

1- Enable strict site isolation: chrome://flags/#enable-site-per-process
2- Navigate chrome to http://csreis.github.io/tests/cross-site-iframe-mixed-content.html
3- Click on "Go HTTPS (complex page)".
4- Inside the <iframe> (chromium waterfall page) click on "search" and wait until the <input> box for query appears.
5- Click and observe the box is highlighted and caret visible.
6- Now open task manager and kill the subframe process for the waterfall page.
7- Go back to the tab and repeat steps 3-4.

On current stable the input box is no longer highlighted. On Canary (after the fix) it is.

Marking as fixed.