What is your proposal? It seems to me like it's working as intended.

The problem is if ShouldUseCustomFrame() returns false, then CreateFootnoteView is never called. If a dialog is designed with a footnote view in mind then the code expects it to always be created, right?

A footnote view only makes sense in the context of a custom frame. If you need something like a footnote view on a dialog that has a native frame, you'd have to implement that functionality, which doesn't exist because AFAIK we've never needed it. What dialog is this causing issues for?

I was adding a function CreateNonClientFrameView() for ChooserDialogView class, which has similar logic as:
https://cs.chromium.org/chromium/src/ui/views/window/dialog_delegate.cc?dr=C&sq=package:chromium&l=192
When I was testing the Web Bluetooth chooser on Chrome Apps for the case when ShouldUseCustomFrame() returns false, since the footnote view is created only when it is needed:
https://cs.chromium.org/chromium/src/chrome/browser/ui/views/chooser_content_view.cc?sq=package:chromium&rcl=1478621894&l=282
when ShouldUseCustomFrame() is false, CreateFootnoteView() is never called:
https://cs.chromium.org/chromium/src/ui/views/window/dialog_delegate.cc?sq=package:chromium&rcl=1478435172&l=211
So the |footnote_link_| is nullptr in this case, but is used in other places such as:
https://cs.chromium.org/chromium/src/chrome/browser/ui/views/chooser_content_view.cc?dr=C&sq=package:chromium&l=208
and it causes crash.

So I think your options are:
a) fix chooser_content_view, or
b) take this into account when implementing your CreateNonClientFrameView

Archiving old bugs that haven't been actively assigned in over a year.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!