Developer Tools
7 years ago
5 years ago


(Reporter: Kevin Dangoor, Assigned: msucan)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [console-2])


(1 attachment, 1 obsolete attachment)



7 years ago
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

7 years ago
One more test would involve opening/closing the console repeatedly and switching between sites to see how that reacts over time.

Comment 2

7 years ago
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, which is trivial to fix.

Thanks! Looking forward to your results.
Attachment #474776 - Flags: feedback?(ddahl)


7 years ago
OS: Mac OS X → All
Hardware: x86 → All

Comment 3

7 years ago
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.


- 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(, 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.
Attachment #474776 - Attachment is obsolete: true
Attachment #475828 - Flags: feedback?(ddahl)
Attachment #474776 - Flags: feedback?(ddahl)

Comment 4

7 years ago
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

7 years ago
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!
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

7 years ago
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

7 years ago
mass change: filter on PRIORITYSETTING
Blocks: 593956
Priority: -- → P3


7 years ago
Whiteboard: [console-2]

Comment 9

6 years ago
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.
Last Resolved: 6 years ago
Resolution: --- → FIXED


5 years ago
Attachment #475828 - Flags: feedback?(ddahl)
You need to log in before you can comment on or make changes to this bug.