This is actually a webcompat issue, because sites aren't expecting window.find to throw an error, yet Fennec and GeckoView throw a "Component not found" NS_ERROR_NOT_AVAILABLE. This breaks www.fanatiz.com entirely.

Since it doesn't look like window.find is going away anytime soon (based on bug 672395 being in limbo while we try to standardize window.find instead), we should investigate fixing this or at least keeping the function from throwing.

window.find was disabled on mobile here: https://searchfox.org/mozilla-central/source/mobile/android/app/mobile.js#231 as a workaround to prevent crashes, but no follow ups were filed to fix the actual crash: https://bugzilla.mozilla.org/show_bug.cgi?id=750051

It would be a lot nicer to not throw (since that can break pages, cf. webcompat.com/issues/27934), but maybe always return false when not enabled?

Looking at https://bugs.chromium.org/p/chromium/issues/detail?id=695564, I don't see Chrome removing that any time soon (usage is 0.02% of pageloads), and we shouldn't take the compat hit by removing from desktop first.

Anne, any thoughts?

https://github.com/whatwg/html/issues/3539 is the canonical issue standards-wise, I think. Allowing user agents to return false when invoked seems reasonable to me.

I just tested it on Fenix nightly and it works great. It better do
actually, as most of the code is shared with find-in-page.

See bug 750051 for when this was blocked. I don't think that was
properly understood at the time, but at this point the divergence from
desktop seems gratuitous.

This has caused compat issues in the past.

https://hg.mozilla.org/mozilla-central/rev/695cbcabf7fe