1799557 - Add a custom 404 page for `/source/` endpoint tip/head revisions which have been moved/renamed/deleted/removed

Status: NEW

(Webtools :: Searchfox, enhancement)

Description

[Andrew Sutherland [:asuth] (he/him)]

Right now the UX for files that have been moved, renamed, or deleted/removed is not great when you have a link to the HEAD revision via /source/. This is quite notably happening right now in the migration from .jsm files to .sys.mjs files.

From a UX perspective, we have a few options available:

• Attempt to find the most recent revision for the given path that did exist and show that
• Have a mapping that knows if the file, by git copy/move detection, was moved/copied elsewhere, and in that case either:
  • Automatically shows the successor file, possibly with a note like when wikipedia redicts the user via an alias/etc.
  • Shows the oldest revision that existed from the previous bullet, but provides a link for the move/copy.
• Support some kind of per-repo tombstone/redirect mechanism for when a file does not exist:
  • Pattern-based matching, like indicating that we should apply the s/\.jsm$/\.sys\.mjs/ transform.
  • Explicit per-file tombstones for cases where the refactoring was more in depth.

From a web-serving implementation perspective, there's a few options:

• Use nginx's try_files to include a failover. There's some tutorial docs that cover this a little that jumped out at me.
• Use nginx's error_page mechanism to more explicitly create a custom 404 experience.

From a searchfox implementation perspective, there's a few options:

• When do we handle things?:
  • Do things dynamically by bouncing to a dynamic server request when we can't find the file; this can then potentially be cached.
  • Serve a static 404 html page that does know the original source request and then can do some JS based dynamic queries which themselves can then be queried. This probably works best for UX approaches where we want the user to make a decision and where we expect more contributions from people who are likely to want to work primarily in client-side JS. I don't think this would be the optimal UX otherwise.
  • Pre-render tombstones for files that did exist in the tree but no longer exist in the tree. This would assume blame-building would accumulate data on this for us somehow.
• Searchfox primitives that could be involved:
  • Find the last known revision of a file (possibly on a branch?)
  • In the vicinity of bug 1725330, compute forward information for blame when looking at things in a specific revision. Although since this would be at the granularity of a whole file, this is a bit easier, especially because getting a git log for a file is going with the grain as far as git is concerned.