Closed Bug 1442466 Opened 2 years ago Closed 1 year ago

Browser completely crashes/hangs up if window.find finds the term in <input> value


(Core :: DOM: Core & HTML, defect, P2)




Tracking Status
firefox-esr52 --- wontfix
firefox-esr60 --- wontfix
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox64 --- wontfix
firefox65 --- wontfix
firefox66 --- fixed


(Reporter: rogerwrite, Assigned: emilio)



(4 keywords)


(2 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.90 Safari/537.36 Vivaldi/1.91.867.38

Steps to reproduce:

1. Go to: and click on one of the results. You are now on a topic page.

2. On the topic page, click on some link (could be on the logo/home page).

3. Now click on the back browser button. Everything crashes (most likely due to incorrect cache of localStorage and/or window.find usage).

Actual results:

No crash (works with Chrome, Opera).

Expected results:

Total browser crash.
I can reproduce.
Nightly60.0a1 x64 freezes with huge cpu, 100% memory usage. I must kill it :(
Ever confirmed: true
Keywords: crash, hang, reproducible
Even a simpler way to reproduce: Go to, click on some found link and now reload the page - CPU 100%, computer crash.
Cannot reproduce.
build: 60.0a1 (2018-03-02) (64-bit)
OS: windows 10 V1709
(In reply to brunoais from comment #3)
> Cannot reproduce.
> build: 60.0a1 (2018-03-02) (64-bit)

I can still reproduce the hang on Nightly60.0a1 Win10 x64 with new profile.
It definitely crashes everything and can be reproduced by the easy steps I described above; never seen it before, Windows 10 recovers for minutes (had to refresh Firefox).
Attached file minimum html
browser hangs up if window.find finds the term in <input> value
Component: Untriaged → DOM
Product: Firefox → Core
Summary: Browser completely crashes when using the back button (cached localStorage / window.find elements) → Browser completely crashes/hangs up if window.find finds the term in <input> value
Version: 58 Branch → Trunk
Yes, it must be it BUT it's not only <input> -- it's also <textarea> (and possibly other input elements).
Regression window for attachment 8955771 [details]:

Regressed by:
 f353b4ec86ff	Neil Deakin — Bug 544146, when focusing at the caret position, if the caret is not set or at the root, don't look for a node to focus, r=smaug
Blocks: 544146
Keywords: regression
So uh, that regressed 8 years ago...Probably not worth tracking as a regression. Let's let Overholt prioritize accordingly.
Flags: needinfo?(overholt)
Keywords: regression
I'd like to get this fixed but given we haven't had many reports of this, we can't make it a P1.
Flags: needinfo?(overholt) → needinfo?(bugs)
Priority: -- → P2
Please fix it asap to regain FF popularity which it deserves. People who experience such bugs won't report anything - they will just move to Chrome.
Assignee: nobody → bugs
Flags: needinfo?(bugs)
(In reply to Roger from comment #2)
> Even a simpler way to reproduce: Go to
> php?phrase=poland&where=1&forum=&action=search&searchGo=1, click on some
> found link and now reload the page - CPU 100%, computer crash.

I can't reproduce it this way, but alice's test cases shows the issue.
I was in contact with the site's owners and they tried to temporarily fix it by checking Firefox agent and focusing user below the input area. BUT the issue can still be reproduced on the main site (not archive), ie. you can go to, then in the top-right corner enter a search term (eg. Poland). Then click on some found link. Then go down to the post form and enter the word   Poland into the text area. NOW reload the page - the browser and your computer becomes useless. : (
Flags: needinfo?(emilio)
Depends on: 1510485
So I took a look at this before landing my patch for bug 1510485.

What's going on is that nsWebBrowserFind finds the start range based off effectively window.getSelection(), which just doesn't work when you're selecting text in a text control.

Furthermore it tries first to use the focused element, but in this case the previous invocation of find() doesn't focus it, so the focused element is null and we restart the search for the whole document.

Bug 1510485 will fix this by preventing such ranges to be found in this case...
Flags: needinfo?(emilio)
Which actually explains the regression from bug 544146, since nsWebBrowserFind uses MOVEFOCUS_CARET, which before that patch would've focused the <input>.

OH, and actually, that's supposedly handled already, somehow...
And that code makes no sense at all.
Assignee: bugs → emilio
This is ultimately the root cause of the issue. I'm landing a test to ensure we
notice the behavior change if we make it, in addition to a test for this issue
itself, to ensure that we don't get stuck, since after bug 1510485 we don't
return such nodes from nsFind when window.find is called anyway.

This code made no sense, it only returned true if the binding parent is the node
itself, which as far as I can tell cannot happen, so it was just a very
expensive way to return false.
Pushed by
Fix bogus IsInNativeAnonymousSubtree function in nsWebBrowserFind. r=bzbarsky
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
Still a regression, even though it was an old one.
Has Regression Range: --- → yes
Keywords: regression
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.