html_docScroll testSpeed fails on IE8 with developer toolbar open when run from dojo/tests/runTests.html

[bill]

html_docScroll.html works when run standalone, but when run from runTests.html on IE8, results are that t0=2703, t1=1985 (-37% improvement).

I got those numbers by adding additional console.log() output and removing tests after html_docScroll.

Also, the dojo.window.scroll tests take about 10 minutes to run, rather than a few seconds like on other browsers, might indicate a problem.

[Douglas Hays]

I ran dojo/tests/_base/runTests.html 4 times on IE8 and those problems never showed up. It took about a minute to run all the tests. I do get 2 different errors
1) [object Error] in html.html::scrollingStrictIframeBoth
2) test timeout in xhr.html::xhrPost

[bill]

dojo.window is not part of _base, so you need to run dojo/tests/runTests.html, not dojo/tests/_base/runTests.html.

But it turns out both problems only happen when the developer tooblar is opened, or has been opened and then closed (hit F12 key). Can you reproduce it in that case?

Of course, anyone that know and remembers can run the tests after closing the developer toolbar and restarting their browser, but it would be nice to fix to avoid spurious test failures.

[Douglas Hays]

I'm not sure what to do with this ticket. I cannot recreate either problem even with the dev toolbar opened (I was watching console messages being logged in real-time). There were several seemingly unrelated problems. The very first test bootstrap::hasConsole always fails (which seems odd since I saw the message logged to the console). tests.cache locked up the browser. However, when the IE8 browser initially GAed, I remember the scrollIntoView tests taking a really long time when the dev toolbar was opened. But I haven't seen that in a long time and I assumed it was just a problem with early versions of IE8. It seems fast now. But I suppose it could be some setting. I suspect the IE8 process is probably consuming a lot of resources (toolbar maing it worse) and by the time that the scrollIntoView tests happen at the end of the runTests, some resource (memory?) is gone, causing the tests.cache lockup as well which is also near the end.

[Douglas Hays]

Is this still a problem? I cannot recreate it. I would guess that IE8 has some kind of leak and if you quit the browser completely and then reopen, the performance should be much better. I also noticed that [24206] made the scroll tests much faster on IE8.

[bill]

I checked again, it only seems to be happening now when the console is actually open. In that case I still get the failures, but it's not worth worrying about.