Closed
Bug 594741
Opened 14 years ago
Closed 13 years ago
Web Console stress test
Categories
(DevTools :: General, defect, P3)
DevTools
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: dangoor, Assigned: msucan)
References
Details
(Whiteboard: [console-2])
Attachments
(1 file, 1 obsolete file)
30.58 KB,
patch
|
Details | Diff | Splinter Review |
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)
Reporter | ||
Comment 1•14 years ago
|
||
One more test would involve opening/closing the console repeatedly and switching between sites to see how that reacts over time.
Assignee | ||
Comment 2•14 years ago
|
||
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.
Attachment #474776 -
Flags: feedback?(ddahl)
Assignee | ||
Updated•14 years ago
|
Status: NEW → ASSIGNED
OS: Mac OS X → All
Hardware: x86 → All
Assignee | ||
Comment 3•14 years ago
|
||
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.
Attachment #474776 -
Attachment is obsolete: true
Attachment #475828 -
Flags: feedback?(ddahl)
Attachment #474776 -
Flags: feedback?(ddahl)
Assignee | ||
Comment 4•14 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.
Reporter | ||
Comment 5•14 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!
Comment 6•14 years ago
|
||
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.
Assignee | ||
Comment 7•14 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.
Reporter | ||
Comment 8•14 years ago
|
||
mass change: filter on PRIORITYSETTING
Blocks: devtools4
Priority: -- → P3
Updated•14 years ago
|
Whiteboard: [console-2]
Assignee | ||
Comment 9•13 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.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Attachment #475828 -
Flags: feedback?(ddahl)
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•