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: https://polishforums.com/archives/2005-2009/index.php?phrase=poland+travel&where=1&forum=&action=search&searchGo=1 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 :(

Even a simpler way to reproduce: Go to https://polishforums.com/archives/2005-2009/index.php?phrase=poland&where=1&forum=&action=search&searchGo=1, 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).

browser hangs up if window.find finds the term in <input> value

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]: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0fc982aa8276&tochange=a29d44f196a6 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

So uh, that regressed 8 years ago...Probably not worth tracking as a regression. Let's let Overholt prioritize accordingly.

I'd like to get this fixed but given we haven't had many reports of this, we can't make it a P1.

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.

(In reply to Roger from comment #2) > Even a simpler way to reproduce: Go to > https://polishforums.com/archives/2005-2009/index. > 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 PolishForums.com, 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. : (

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

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... https://searchfox.org/mozilla-central/rev/fd62b95c187a40b328d9e7fd9d848833a6942b57/toolkit/components/find/nsWebBrowserFind.cpp#319

And that code makes no sense at all.

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 ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/7b87897daca2 Fix bogus IsInNativeAnonymousSubtree function in nsWebBrowserFind. r=bzbarsky

Still a regression, even though it was an old one.