594741 - Web Console stress test

Status: RESOLVED FIXED

(DevTools :: General, defect, P3)

Description

[Kevin Dangoor]

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]

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]]

Attachment: 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]]

Attachment: 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]]

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]

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)]

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]]

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]

mass change: filter on PRIORITYSETTING

Comment 9

[Mihai Sucan [:msucan]]

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.