Closed Bug 1358633 Opened 4 years ago Closed 3 months ago

window.find does not work in Firefox for Android and throws NS_ERROR_NOT_AVAILABLE


(Core :: DOM: Core & HTML, enhancement, P5)




Webcompat Priority P3
Tracking Status
firefox80 --- fixed


(Reporter: mconley, Assigned: emilio)


(Blocks 1 open bug, Regression)


(Whiteboard: [webcompat])


(1 file)


1) Visit
2) Scroll down to the "Example", and click on any of the "Search for" buttons


Alert modals should come up giving search results.


Nothing happens.

I don't actually think this is a big deal. window.find is non-standard, and we've got a bug on file to get rid of it in bug 672395. I'm really just filing this so I have a bug to refer to when I disable a test that exercises window.find for Android.
Thanks Mike for the clear statement. Setting P5 as this is not a standard and there's a bug to get rid of it.
Priority: -- → P5
Component: DOM → DOM: Core & HTML

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 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.

Flags: webcompat?
Whiteboard: [webcompat]
Webcompat Priority: --- → ?
Flags: webcompat?
Blocks: 672395
Summary: window.find does not work in Firefox for Android → window.find does not work in Firefox for Android and throws NS_ERROR_NOT_AVAILABLE
Webcompat Priority: ? → P3
Flags: needinfo?(miket)

window.find was disabled on mobile here: as a workaround to prevent crashes, but no follow ups were filed to fix the actual crash:

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

Looking at, 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?

Flags: needinfo?(miket) → needinfo?(annevk) is the canonical issue standards-wise, I think. Allowing user agents to return false when invoked seems reasonable to me.

Flags: needinfo?(annevk)
Duplicate of this bug: 1465387
Regressed by: 750051

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.

Assignee: nobody → emilio
Pushed by
Enable window.find on GeckoView. r=geckoview-reviewers,snorp
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla80
You need to log in before you can comment on or make changes to this bug.