I don't think we want to expose a weak ptr on RenderFrameHost for a few different reasons.  But more importantly, we should already be tracking this.  UIThreadExtensionFunction has a RenderFrameHostTracker that observes the WebContents and waits for the render frame host to be deleted, and, when it is, resets the render_frame_host() to null.  So I don't think we need to add more weak ptr lifetime management; only make sure things are null-checking appropriately.

We hit this issue again in crbug.com/673459. It's like 4th time, and each time it's hard to debug. I'm pretty sure we have plenty of other instances of this very same issue.

I'd strongly suggest to use a weak pointer here. It will unlikely cause any performance regression but it would guarantee that these bugs will never happen again.

How would a weak ptr have helped in crbug.com/673459?  The code in question never checked the return result of render_frame_host(), and calling the operator -> on an invalidated weak ptr still crashes.  It's true that there would be benefit in having a null access rather than a UAF, but from a "do we crash or don't we", it doesn't seem like this would help.  Am I missing something?

I wanted to change the getter ExtensionFunction::render_frame_host() into
ExtensionFunction::GetRenderFrameHostAsWeakPtr(). Though when I think about it again, it looks like an overkill.

I still do believe that we can do something here to avoid this bug happening again.
How about renaming the getter into a method like: GetRenderFrameHostOrNull(). It's verbose, but I believe everyone will do a null check after calling such method.

Alternatively maybe we could remove refcounting from ExtensionFunction and make it WeakPtrFactory, then make the object gone with render frame host. I don't see much point in continuing executing an extension function after the host is gone, as we can't even post the response.