1126635 - firefox is extremely slow when highlighting search matches in dom when using a page-provided search widget on http://palmeral.github.io/scratchpad/

Status: NEW

(Core :: General, defect)

Description

[bgstandaert]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150122214805

Steps to reproduce:

Open http://palmeral.github.io/scratchpad/, enter a long (~1000 words) amount of text in the contenteditable. Click the magnifying glass to search in page, type something over a couple of characters.


Actual results:

Anytime something is over 2-3 characters and the text in the contenteditable is longish, firefox completely freezes. Sometimes is shows the "unresponsive script" message, most of the time it doesn't.


Expected results:

There should be very little lag. Safari and Chrome are able to do this with almost no visible lag, even with long text and a long search term.

Comment 1

[bgstandaert]

Also occurs on latest nightly (2015-01-27)

Comment 2

[Boris Zbarsky [:bzbarsky]]

So just to make sure, we're talking about the site's search, not Firefox's built-in search?

I see no lag at all with a _long_ search term that I paste in.  It comes back pretty immediately as 0 matches.

The one case I see lag in is when going from something with few matches to something with a lot of matches and back.  So for example, if I type "e" there is a lag as all the matches are highlighted, then if I type "y" there's a lag as they're all unhighlighted.

I'm looking into the highlighting/unhighlighting issue, but if you have more precise steps to reproduce the "slow to search for a long search text" bit (e.g. the exact search text and exact corpus to be entered into the scratchpad), that would be much appreciated.

Comment 3

[Boris Zbarsky [:bzbarsky]]

So looking at a profile of the highlight/unhighlight, there's a bunch of splitText/normalize/replaceChild calls.  A lot of their time (50%+) is spent notifying ranges...

Comment 4

[bgstandaert]

Yes, this is the page provided find in page.

The exact text doesn't seem to matter, I usually just use a long string of lorem ipsum like http://pastebin.com/7UVEY9qe. This is much better with the (faster) computer I'm testing on today, but still noticeable - some examples:

type "e": ~5 seconds lag before matches appear, browser freezes for another 5 seconds, then back to normal (in safari, appears as soon as typed with no lag)

same amount of lag when deleting the "e" from the search box.

type "eu" - no lag. Then delete the "u" so the search term is just "e". ~20 seconds of freezing (none in safari)

Comment 5

[Boris Zbarsky [:bzbarsky]]

OK, so that matches what I'm seeing: the lag is only when going from highlighted to not, and has nothing to do with the length of the text being searched for, right?  Just want to make very sure we're talking about the same issue and there isn't a second issue here as well.

Comment 6

[bgstandaert]

I think so. If you type in a longer search term manually, the lag is much worse. On thinking about this though, this is because it removes the old highlights and creates new ones on every keyup, meaning that it is going from highlighted to not and back again several times very quickly.

Comment 7

[bgstandaert]

Actually, this appears to be tied to the fact that the element that is being searched has contenteditable. If the contenteditable attribute of the element is set to false, the lag goes away.

Comment 8

[bgstandaert]

I've updated this page with a temporary workaround by removing the contenteditable while the text is searched. New testcase is at http://palmeral.github.io/scratchpad/index.html#debug

Comment 9

[Boris Zbarsky [:bzbarsky]]

Olli, do you have time to look at this?  It's weird that contenteditable would have something to do with this per se, unless editor is what's making all those ranges that I was seeing in the profile....

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Mats might have this stuff better in mind atm.

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

(but please mats needinfo? me if you don't have time to look at this.)

Comment 12

[Mats Palmgren (inactive)]

(In reply to Boris Zbarsky [:bz] from comment #9)
> unless editor is what's making all those ranges that I was seeing in the profile....

I suspect those ranges comes from the spellchecker.  Highlighting seems to have
good performance for me even on large chunks of text as long as it doesn't contain
spelling errors.

@bgstandaert - does toggling spellcheck="false"/"true" (instead of the contenteditable
attribute) also fix the problem?

If that's the problem then it's probably something we could optimize internally,
if we can detect that we're being hosed with DOM mutations.

Comment 13

[Mats Palmgren (inactive)]

(BTW, the text at the URL is white-on-white for me (on Linux).)

Comment 14

[bgstandaert]

Removing the spellchecking solves 60-70% of the problem. The lag gets much better, but there is still a noticeable amount.

Comment 15

[bgstandaert]

(In reply to Mats Palmgren (:mats) from comment #13)
> (BTW, the text at the URL is white-on-white for me (on Linux).)

Sorry about that! Should be fixed now.

Comment 16

[arni2033]

@bgstandaert: Have you cloned that "scratchpad" somewhere? It appears to be deleted...

Comment 17

[bgstandaert]

(In reply to arni2033 from comment #16)
> @bgstandaert: Have you cloned that "scratchpad" somewhere? It appears to be
> deleted...

Yes, here's a link that works:

https://standaert.net/archive/DocLayer-2afade5560e5522c1342ec122c6a88c86dd91fb4/index.html