Last Comment Bug 594741 - Web Console stress test
: Web Console stress test
Status: RESOLVED FIXED
[console-2]
:
Product: Firefox
Classification: Client Software
Component: Developer Tools (show other bugs)
: unspecified
: All All
: P3 normal (vote)
: ---
Assigned To: Mihai Sucan [:msucan]
:
:
Mentors:
Depends on:
Blocks: devtools4 devtools4b8
  Show dependency treegraph
 
Reported: 2010-09-09 05:57 PDT by Kevin Dangoor
Modified: 2012-11-08 07:19 PST (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
stress test (8.91 KB, patch)
2010-09-13 12:43 PDT, Mihai Sucan [:msucan]
no flags Details | Diff | Splinter Review
stress tests (30.58 KB, patch)
2010-09-16 06:03 PDT, Mihai Sucan [:msucan]
no flags Details | Diff | Splinter Review

Description Kevin Dangoor 2010-09-09 05:57:36 PDT
The goal of this bug is to try to make the Web Console leak (or to demonstrate comfortably that it does not).

Examples of ways to do this:

1. go to sites (or create a page) that generates lots of log output, ideally of varied kinds

2. go to a site (or create a page) that frequently rotates an image or something like that and see if there are leaks over an extended period of time (24 hours, say)
Comment 1 Kevin Dangoor 2010-09-10 11:02:03 PDT
One more test would involve opening/closing the console repeatedly and switching between sites to see how that reacts over time.
Comment 2 Mihai Sucan [:msucan] 2010-09-13 12:43:11 PDT
Created attachment 474776 [details] [diff] [review]
stress test

This is the first test which goes through the top sites listed by Alexa. I used timeouts for practical reasons, I hope this can go through review. If I must find another way, please let me know. I can switch to nsIWebProgressListeners, if it's required. With regards to UI stuff ... if DOMNodeInserted is never fired ... what can I do?

The test works for me in debug and opt builds. The patch should apply cleanly on mozilla-central. It can only fail on the Makefile.in, which is trivial to fix.

Thanks! Looking forward to your results.
Comment 3 Mihai Sucan [:msucan] 2010-09-16 06:03:21 PDT
Created attachment 475828 [details] [diff] [review]
stress tests

Updated patch. Changes:

- made a fix for the first test that goes through top sites.

- added a new test that opens two tabs in two windows (or how many we want), and toggles the Web Console often such that we may catch failures. I constructed an HTML+JS page which spews quite a few tons of errors - both JS and CSS errors.


Findings:

- the first test that goes through top sites failed badly because of bug 583476, which is gladly now fixed. Yay!

- the second test now fails badly due to errors in HUDService.deactivateHUDForContext().

- window.onerror event handler is "leaked", in the sense that it's never cleared when the Web Console is closed, and it throws whenever an exception in the web page occurs, because the window.onerror event handler tries to send to the message to the inexistent Web Console. We need to clear the event handler.

- the HUDConsoleObserver remains active forever after the Web Console is open, even after closing. which means the code in the HUDService is always executed when nsIConsoleMessages are sent. This doesn't throw because we have a failsafe, but still we should remove the observer when the last Web Console is closed.

- the HUDService.deactivateHUDForContext(tab) fails (throws) when the given tab is not from the focused window.

- for some reason the Web Console fails to open to it's complete height. It opens but only a few pixels, sometimes.

- when I quickly open/close the Web Console while scripts execute in the web page ... I get random throws/exceptions. Example: Math.random is undefined and so on. *Very* weird.

- HUDService.activateHUDForContext(tab) calls registerActiveContext(nBox.id), while other code uses hudId for (un)registerActiveContext().

Shall I report any of the above findings as bugs? I can try and fix them, one by one.
Comment 4 Mihai Sucan [:msucan] 2010-09-16 06:25:29 PDT
Another finding:

Exceptions thrown from event handlers executed by synthetically dispatched events are not shown in the Web Console, in Firebug nor in the Error Console. See bug 574941.
Comment 5 Kevin Dangoor 2010-11-03 12:56:40 PDT
FWIW, I'm not sure if we would check in stress tests (or where we would). The intention is just to really exercise the web console and ensure that it doesn't behave badly when it is so exercised.

We might want to do another round after the lazy console service lands. Your first round seems to have shaken out a bit of bad behavior. Thanks Mihai!
Comment 6 Rob Campbell [:rc] (:robcee) 2010-11-04 05:39:34 PDT
agreed, not sure we'd want to check these in. By their very nature, they're designed to throw errors and do bad things to see if they show up on the console. That could get messy.

Then again, if the browser can't handle it in the testing farm, maybe it'd be good for showing up other browser failures?

Either way, this is good stuff and we should make sure to run these from time-to-time.
Comment 7 Mihai Sucan [:msucan] 2010-11-04 06:01:08 PDT
Thanks for your comments guys!

Definitely, after the lazy console stuff is checked in ... we must, must run these (rebased) stress tests and see the results. I expect we'll shake out some bad behavior/failures.
Comment 8 Kevin Dangoor 2010-11-22 11:42:08 PST
mass change: filter on PRIORITYSETTING
Comment 9 Mihai Sucan [:msucan] 2011-06-21 12:36:20 PDT
Marking this as fixed (as per discussion with Kevin), since we did Web Console stress tests, had some bug reports that were fixed, and now the Web Console code is out in the wild - best stress test.

Note You need to log in before you can comment on or make changes to this bug.