Closed
Bug 601260
Opened 14 years ago
Closed 14 years ago
Cache all messages in the ConsoleStorageService once all web console observers are running
Categories
(DevTools :: General, defect, P1)
DevTools
General
Tracking
(blocking2.0 betaN+)
RESOLVED
DUPLICATE
of bug 611032
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
People
(Reporter: ddahl, Assigned: ddahl)
References
Details
There is a new cache/storage service landing with bug 568629. we should send all messages that emanate from the httpActivityObserver, nsIConsoleService Observer to the new storage service so that when a console is opened we can view any errors that happened previous to opening the web console.
Assignee | ||
Comment 1•14 years ago
|
||
Actually, by default, we should only cache console API messages as well as errors and css parsing errors. Perhaps with a pref we can also listen for http activity.
This bug is basically breaking out our nsIConsoleService observer into a small service (in a JSM loaded at final-ui-startup) that knows how to record all error messages per window into the ConsoleStorageService.
This will then allow users to open the console and see all of the errors that have already happened.
Comment 2•14 years ago
|
||
Holding on to script and CSS errors that come through while the console is closed at least is a blocker, given the expectations that people have established with the Error Console.
Blocks: devtools4b8
blocking2.0: --- → ?
Updated•14 years ago
|
Assignee: nobody → ddahl
Updated•14 years ago
|
blocking2.0: ? → beta8+
Updated•14 years ago
|
Depends on: lazy-console
Comment 3•14 years ago
|
||
What about memory/perf concerns? Is it being limited to 250? Or is is not a factor anymore?
Comment 4•14 years ago
|
||
I believe the service hangs on to 200 events and does not (or will not -- there may be a patch outstanding there) keep request/response bodies unless told to do so.
Updated•14 years ago
|
Assignee: ddahl → rcampbell
Updated•14 years ago
|
Keywords: dev-doc-needed
Comment 6•14 years ago
|
||
we won't be keeping request/response bodies by default, no.
200 events may be small for a service like this. We'll have to experiment a little.
Assignee | ||
Comment 8•14 years ago
|
||
(In reply to comment #6)
> we won't be keeping request/response bodies by default, no.
>
> 200 events may be small for a service like this. We'll have to experiment a
> little.
it is 200 events per tab. the existing error console is 300 total per browser. Perhaps we should make this configurable?
Comment 9•14 years ago
|
||
since beta8 is tomorrow and the lazy console which this depends on hasn't landed yet, I'm hoping we can push this to next beta.
Updated•14 years ago
|
blocking2.0: beta8+ → betaN+
Updated•14 years ago
|
Comment 11•14 years ago
|
||
mass change: filter on PRIORITYSETTING
Comment 12•14 years ago
|
||
assigning this to david. This should probably now be a dupe of bug 612658 since there is no work here.
Assignee: rcampbell → ddahl
Assignee | ||
Comment 14•14 years ago
|
||
(In reply to comment #12)
> assigning this to david. This should probably now be a dupe of bug 612658 since
> there is no work here.
actually this is a dupe of bug 611032
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Updated•13 years ago
|
Keywords: dev-doc-needed
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•