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)

defect

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.
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.
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: --- → ?
Blocks: 601175
Assignee: nobody → ddahl
blocking2.0: ? → beta8+
What about memory/perf concerns? Is it being limited to 250? Or is is not a factor anymore?
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.
Assignee: ddahl → rcampbell
marking as assigned.
Status: NEW → ASSIGNED
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.
(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?
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.
Depends on: 611032
blocking2.0: beta8+ → betaN+
Blocks: devtools4
No longer blocks: devtools4b8
Blocks: 609890
Blocks: 602199
mass change: filter on PRIORITYSETTING
Priority: -- → P1
mass change: filter on PRIORITYSETTING
assigning this to david. This should probably now be a dupe of bug 612658 since there is no work here.
Assignee: rcampbell → ddahl
mass change: filter mail on BLOCKERSETTING
Severity: normal → blocker
(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
No longer blocks: 609890
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.