So I understand that the JS would navigate to another entry, ignoring the "dirty form" state, and by adding this condition, it makes it skip the JS navigation vianavigateTreeView and instead trigger a full-page load with the dirty checking done insidebeforeunload by jquery.are-you-sure.

A better solution would be to makenavigateTreeView perform the dirty checking and warning itself. That way, it will work without a disruptive full-page load when the user wants to discard their changes.

A better solution would be to makenavigateTreeView perform the dirty checking and warning itself. That way, it will work without a disruptive full-page load when the user wants to discard their changes.

I don't think it is a must at the moment.are-you-sure.js module has many internal logic, since it is there, we should reuse that module, but not re-invent the wheel and write a new "are-you-sure" from scratch, unless you would replace the legacy "are-you-sure.js" completely

The "dirty check" (document.querySelector('.repo-view-content .form.dirty')) can be a helper function exported from theare-you-sure.js to make the code more stable and maintainable.

The real logic is here:

unless you would replace the legacy "are-you-sure.js" completely

Yes I think it's best to completely replace it with custom logic eventually. The plugin only works for full page navigation, while here we have a case of JS-based navigation (pushState and replaceState). It needs to support both forms of navigation.

The "dirty check" (document.querySelector('.repo-view-content .form.dirty')) can be a helper function exported from the are-you-sure.js to make the code more stable and maintainable.

Yes, this would be a good way to expose the dirty checking as a function used for JS-based navigation.

Oh and I still think the "unsaved warning" should eventually be replaced by a mechanism that automatically saves and restores unsaved content (based on URL) if the user decides to navigate back. E.g. likehttps://github.com/github/session-resume.