Bug 52561 – Changing innerHTML gets progressively slower, spinning in updateStyleSelector()

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: CSS

[Aymeric Vitte]

We have noticed this problem with webkit since a long time, now we report it.

It happens on all platform and causes the browser to slow down more and more, and sometimes to block it on mobile devices for example.

The issue is that when you perform several test.innerHTML=xxx one after another, the more you do it, the more the time increases for the browser to do it, up to 40s, 50s , 60s etc just to set this simple property.

It cane be seen easily on : www.extractwidget.com/mindex2bug.php

Just enter "parquet castorama", then OK

The purpose of the interface is to retrieve interesting gadgets from the url matching the keywords "parquet castorama"

Each time the interface will ask for a gadget to the server, you will see an alert "retrieve"

Then you will see an alert "0" before the innerHTML, then alert "1" after

The code in api/ewbug.js is just simply :

alert("0");

var tmp2=$$('DIV');
tmp2.$s.width=w_w[1]+'px';
tmp2.$s.height=w_w[2]+'px';
tmp2.innerHTML=boi;
if (w_w[4]!='') {tmp2.$s.overflow='hidden';};
tmp2.$s.background='white';
tmp.$a(tmp2);

alert("1");

You will see that after the 4th or 5th "retrieve" the time between "0" and "1" does increase extraordinarly, and this continues to increase and increase

Looks like a memory leak or something like that

It does not happen on non webkit browsers

[Alexey Proskuryakov]

Created attachment 79188 [details]
Safari sample

Confirmed with Safari/WebKit 5.0.3.

[Alexey Proskuryakov]

CSS style calculation gets very slow. As a wild guess, repeated insertion and removal of CSS style sheets leaves something behind.

[Aymeric Vitte]

Do you know a workaround ?

Like inserting the css tags/code separately as objects instead of mixing them with the html code injected via innerHTML ?

[Alexey Proskuryakov]

I don't even know the cause for sure. We'll need to make a test case that can be easily modified, and that would ideally run from a local file, not via http. If you can make and attach such, that would certainly help.

[Aymeric Vitte]

Created attachment 79218 [details]
InnerHTML bug

As you mention it's probably due to CSS.

See the attached file gadgets.txt, locally you can try to set innerHTML for gadgets 1 to 6, it should reproduce the problem

Put before in the begining of the HEAD section of your page the base tag <BASE href="http://www.castorama.fr/store/">

Please let me know if it does not work, trying the ulr I gave above will give you now the html code of the gadgets in a textarea

[Aymeric Vitte]

There is a workaround : if we remove the CSS from the html, then change innerHTML with this new html and append to the head the removed CSS html transformed as objects, the problem disappear.

Even while loading several gadgets by the same method and removing/appending the correct CSS for each gadget.

[Alexey Proskuryakov]

The test case at <http://www.extractwidget.com/mindex2bug.php> is dysfunctional now - could you please restore it? I can't easily recreate the problem from the description alone.

[Aymeric Vitte]

Yes, I have reactivated http://www.extractwidget.com/mindex2bug.php

[Alexey Proskuryakov]

The main cause of bad performance is that the script leaks <link> elements. If you open the test page and enter the following in address bar, you can see that the number of stylesheets grows, quickly reaching hundreds:

javascript:alert(document.getElementsByTagName("link").length)

And with this, you can see the current DOM:

javascript:alert((new XMLSerializer).serializeToString(document.documentElement))

It would be good to create a small test case to see what exactly is slow in WebKit - Firefox also shows the growth, but it doesn't get so slow. I suspect that it's an edge case though, and unfortunately I don't have more time to work on this now.

[Aymeric Vitte]

See Bug 52711, maybe the two bugs can be merged.

The test case is reduced, we now insert the main CSS once in the head (instead of doing it each time for each gadget) and then attach the specific CSS for each gadget to the head.

Bug 52711 clearly shows that CSS insertion (probably LINK) is very slow in webkit compared to other browsers, on mobile devices it becomes dramatically slow.

This does not look like a minor issue, there is really something wrong in terms of performances.

[Alexey Proskuryakov]

Let's mark it as duplicate, but the other bug is also very difficult to take action on.

What we need to fix a bug like this is a test case that runs from a local file without accessing the network, making it possible to modify it, experimenting and cutting unimportant parts. It's most obviously not your job, and filing a bug is appreciated in any case.

However, the existing test case is still quite complicated, dynamically loading large external scripts and content, and I personally found it time prohibitive to reduce. Since you know the code in and out, going the extra mile to make a simpler test case may be the best path to resolution.

*** This bug has been marked as a duplicate of bug 52711 ***

[Aymeric Vitte]

I have made a reduced test case here : http://www.extractwidget.com/bug.html

You can put it in local.

If we load the CSS without using a timeout it is fast.

Now while loading the CSS after a certain time using a timeout we reproduce the problem (check time between the two alerts 175ms on my PC against 3 with FF)

Apparently inserting CSS after the page has been loaded and rendered provokes the issue.

It is a generic problem, not due to specific manipulation from us.

[Alexey Proskuryakov]

I think that this test just shows that WebKit resolves styles right away upon link element insertion, while Firefox delays that until some later time. Taking 100-200 ms to load and apply 40 stylesheets doesn't sound bad to me.

[Aymeric Vitte]

Maybe, but from my standpoint it should not block js execution and it is better if the rendering is delayed or asynchron.

As I mentioned, on mobile devices we are not talking about 100-200 ms but 3 to 4 seconds, so in our case if we insert 10 gadgets it can take up to 40s

[Aymeric Vitte]

Try this please : http://www.extractwidget.com/mindex3.php

Then enter in the input "lit enfant 3suisses", then "OK", then pass the mouse over the search results, you will see appearing an iframe for each result with gadgets inside being loaded.

You will notice that quickly the browser seems to be blocked, scrolling on the iframes is not working well and while moving the mouse on the links the iframe does not change.

With webkit on a normal PC with ADSL it takes 3mn and 20 s with this test for the browser to recover and finish the job.

With FF it takes 1mn and 20 s and during that time you can use the scrolling and move from an iframe to another without the browser looking to be blocked.

Sorry to insist, there is really a performance problem somewhere, we have optimized everything on our side, we are not talking now about seconds on mobile devices against ms on a PC but about minutes on a PC connected to internet via adsl