Bug 52561

Summary: Changing innerHTML gets progressively slower, spinning in updateStyleSelector()
Product: WebKit Reporter: Aymeric Vitte <avitte>
Component: CSSAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: ap, koivisto, mitz
Priority: P2 Keywords: NeedsReduction
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
URL: http://www.extractwidget.com/mindex2bug.php
Attachments:
Description Flags
Safari sample
none
InnerHTML bug none

Aymeric Vitte
Reported 2011-01-17 01:55:40 PST
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
Attachments
Safari sample (218.41 KB, text/plain)
2011-01-17 10:38 PST, Alexey Proskuryakov 		no flags
Details
InnerHTML bug (53.17 KB, text/plain)
2011-01-17 14:38 PST, Aymeric Vitte 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2011-01-17 10:38:54 PST
Created attachment 79188 [details] Safari sample Confirmed with Safari/WebKit 5.0.3.
Alexey Proskuryakov
Comment 2 2011-01-17 10:42:59 PST
CSS style calculation gets very slow. As a wild guess, repeated insertion and removal of CSS style sheets leaves something behind.
Aymeric Vitte
Comment 3 2011-01-17 12:45:16 PST
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
Comment 4 2011-01-17 13:00:11 PST
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
Comment 5 2011-01-17 14:38:10 PST
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
Comment 6 2011-01-19 01:48:55 PST
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
Comment 7 2011-01-23 13:03:02 PST
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
Comment 8 2011-01-24 00:06:26 PST
Yes, I have reactivated http://www.extractwidget.com/mindex2bug.php
Alexey Proskuryakov
Comment 9 2011-01-24 23:01:28 PST
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
Comment 10 2011-01-25 00:16:55 PST
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
Comment 11 2011-01-25 00:49:47 PST
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
Comment 12 2011-01-25 03:09:15 PST
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
Comment 13 2011-01-25 20:56:58 PST
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
Comment 14 2011-01-26 01:00:36 PST
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
Comment 15 2011-01-26 13:41:42 PST
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
Note You need to log in before you can comment on or make changes to this bug.