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

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
mozilla80
Webcompat Priority P3
Tracking Status
firefox80 --- fixed

People

(Reporter: mconley, Assigned: emilio)

References

(Blocks 1 open bug, Regression)

Details

(Whiteboard: [webcompat])

Attachments

(1 file)

STR:

1) Visit https://developer.mozilla.org/en-US/docs/Web/API/Window/find
2) Scroll down to the "Example", and click on any of the "Search for" buttons

ER:

Alert modals should come up giving search results.

AR:

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

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: 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?

Flags: needinfo?(miket) → needinfo?(annevk)

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.

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
Status: NEW → ASSIGNED
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/695cbcabf7fe
Enable window.find on GeckoView. r=geckoview-reviewers,snorp
Status: ASSIGNED → RESOLVED
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.