1253868 - "Search HTML" affects the web page (temporarily stops animations and stuff)

Status: NEW

(DevTools :: Inspector, defect, P2)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 47, 32bit, ID 20160229030448
STR:
1. Open http://www.valuewalk.com/
2. Open Inspector
3. Type  [src*='bootstrap']  in the field "Search HTML"
4. Hold Enter for 5 seconds or press Enter 10 times in 5 seconds.

AR:  Animations on the page stop when inspector is doing its stuff
ER:  Web page shouldn't be affected, just like it wasn't in earlier versions

Note:
 In bug 1240632 I learned that transitions run in different processes (Content/Parent)
 depending on transition property. _Probably_ that is connected somehow.
 But I thought that devtools currently only use resources of Parent process.

This is regression from bug 835896. Regression range:
> https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f00a24682d57e48a287e11bcfc72e562929fd007&tochange=961911623a6f2ec1d036c7b12a5117ebbeff45d8

Comment 1

[arni2033]

This also happens in single-process mode (of course)
Screencast (animations lag for >= 0.3s each time when I press Enter)
> https://dl.dropboxusercontent.com/s/er60imyuvb0vlcz/screencast%201%20-%20%27Search%20HTML%27%20affects%20the%20web%20page.webm?dl=0

Comment 2

[Patrick Brosset <:pbro>]

The HTML search works by indexing the current document. The code responsible for indexing is C:\Usersdevtools\server\actors\utils\walker-search.js
Now, everytime a markup mutation occurs in the document, then that code re-indexes it, to make sure it knows about the latest attributes and textContents and tags, etc...

Indexing happens lazily, whenever we first need to search. Once indexed, the data is stored until the next mutation.

It turns out that on this particular site, there are constant markup mutations. For instance the node dl#ticker has its style attribute being mutated all the time. This is how the header animation is done.

This means that the indexed data is cleared every time, and so, every time we search, we re-index.
Indexing is a costly operation that walks the whole DOM of the document.

We could:
- make indexing less performance intensive
- index fewer times

Turns out that on this site, it's pretty useless to index. The content of the style attribute changes, but that's not going to make any difference to the search functionality. So we sure could be a lot smarter in how often we index.

CCing Brian who worked on the search tool.

Comment 3

[Brian Grinstead [:bgrins]]

A couple thoughts:

* The jank on the page should be lessened by e10s
* We could be smarter about partially clearing the index on certain mutations (we'd need to start by profiling what's taking up most of the time to get a sense of where any optimizations should happen).  A couple of first ideas:
** if it was an attribute mutation then clear out all attributeName and attributeValue data.  I'm not sure how much that'd help since we'd still need to do the big loop through the DOM (although could skip text nodes, for instance)
** maybe we could change the structure of the index to make it easier to clear out data from a single DOM node (and it's children)

Comment 4

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Platform triage meeting decision is that we will not be fixing this in Fx47. Devtools team will nominate patch for uplift when ready.

Comment 5

[arni2033]

Not reproducible on the last build before bug 835896. Reproducible on the 1st build after bug 835896.
First bad   437545b472e74a71ca112f4b4a300ae0a646288b (fx-team)
Last good   f00a24682d57e48a287e11bcfc72e562929fd007 (mozilla-inbound)
Also good   43f23a377c8510f29aa9546453b3b3bcb7810b07 (fx-team)
> regression-range 1 (mozilla-inbound)  https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f00a24682d57e48a287e11bcfc72e562929fd007&tochange=961911623a6f2ec1d036c7b12a5117ebbeff45d8
> regression-range 2 (fx-team)          https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=43f23a377c8510f29aa9546453b3b3bcb7810b07&tochange=437545b472e74a71ca112f4b4a300ae0a646288b