We'd have to make the Settings object shared directly as well: the problem is it lives on Page/FrameHost, so Frame gets to it via its Page/FrameHost. However, Frame::detach() clears the m_host pointer, so the Frame no longer has a way of getting to the Settings object.

Fixing this would be valuable: we currently have code like https://chromium.googlesource.com/chromium/src/+blame/master/third_party/WebKit/Source/core/loader/MixedContentChecker.cpp#298 where one developer read the comment and another didn't, so one line null checks even though the prior line unconditionally dereferences =)

However, one potentially tricky thing to consider: what should happen if code tries to change settings for a detached frame? It'd still point to the shared Settings object. I feel like this should be a programming error as well, but I'm not sure how we'd catch it.

Yeah the Frame should hold a Member<Settings> so that it can access the settings when m_host is null.  But it would still be shared, i.e. one Settings per Page.  Why should be an error for a detached frame to change settings?

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot