Matplotlib's website is built upon a vendored version of the sphinx_rtd_theme, which was forked years ago. This fact already led to some problems with search in the past, see #12216.
If you know a future-proof solution, you are very welcome to add it here.

I wouldn't worry about older versions.

Forgot the type="text/javascript" on the previous commit, sorry about that.

A more future-proof version would probably be to follow sphinx-doc/sphinx@55c5168 and replace the whole:

<script type="text/javascript">
    jQuery(function() { Search.loadIndex("searchindex.js"); });
</script>
<script type="text/javascript" id="searchindexloader"></script>

with:

<script type="text/javascript" src="{{ pathto('searchindex.js', 1) }}" defer></script>

That way, loading searchindex.js will no longer be dependent on AJAX or searchtools.js (which is, even in sphinx_rtd_theme, inherited from the sphinx basic theme template), which may in future versions of sphinx again remove the loadIndex method (as was done in the mentioned commit, but then reverted again in sphinx-doc/sphinx@a6e3170).

Referenced the correct pull request this time.

This solution removes the need for searchtools.js or ajax for loading searchindex.js altogether (after loading, searchindex.js itself does depend on searchtools.js, but both are updated with the version of sphinx that is used, unlike this template).

From the author: sphinx-doc/sphinx#3620 (comment), the argument for using ajax to load searchindex.js seems to have been that it is a large file (~1.5 MB currently) and might block loading the page. But since the template block had already been moved to the very bottom of the page, just before </body> and including the defer keyword, that will probably not be a problem.

Also in the pull request sphinx-doc/sphinx#6091 the conclusion seems to be that it works fine on all browsers.

Did a bit more digging and found that this issue became visible mainly as the result of Jupyterlab iframe containing a sandbox attribute with no allow-same-origin, triggering the CORS preflight OPTIONS request that the website is incorrectly configured for. I have reported it at jupyterlab#7506.

This same issue also affects documentation for Numpy, Scipy, Pandas, Sympy, IPython and even the main Python.org docs. None of them however return no results, which is why this fix should still be merged in Matplotlib. It also allows loading search results when opened as a local file:/// page.

A note about our website hosting: It is primarily hosted through githubpages and proxied through cloudflare. It looks like CF passes through CORS headers (https://support.cloudflare.com/hc/en-us/articles/200308847-Using-cross-origin-resource-sharing-CORS-with-Cloudflare ) so to fix this on the server side we would have to figure out how to configure github pages.

Thanks!

I set this to backport back to the 2.2.x docs so the docs of all of our currently supported versions will be fixed.

https://26552-1385122-gh.circle-artifacts.com/0/home/circleci/project/doc/build/html/search.html?q=plot <- link to built docs, verified it works.

Thanks @jeroonk Congratulations on your first PR into Matplotilb 🎉 Hopefully we will hear from you again!

Thanks for merging!

I also monkey-patched the built https://26552-1385122-gh.circle-artifacts.com/0/home/circleci/project/doc/build/html/search.html into the offending Jupyterlab iframe src. There are still XHR errors on the snippets, but at least the results list loads now.

I guess the server configuration can wait. The SymPy, Pandas, IPython and Python.org docs all have the same problem. jupyterlab#7506 should also mostly mitigate it.