Open Bug 386605 Opened 17 years ago Updated 2 years ago

Need a delayed startup event

Categories

(Core :: General, defect, P3)

Product:
Core
Component:
General
Type:
defect

Tracking

()

People

(Reporter: sdwilsh, Unassigned)

References

Details

After talking with mconnor about Bug 384810, it was determined that we need a delayed startup event that fires shortly after the first window opens up. If I recall, places could use this as well.

This can't be a browser only thing because the download manager is a toolkit component, as well as places.

It would be really nice if this could be registered with the category manager so users of it wouldn't have to register with it for some earlier event, and then register for this one with the observer service.
Flags: blocking1.9?
See also Bug 363634
So the goal is to do work "when you get a chance", right?

Could we, instead of inventing an arbitrary point in time when "startup is done", invent a new kind of nsIEventTarget, where you post a nsIRunnable that won't get fired until there are cycles available?

I'm not sure how you'd determine that there were cycles available, of course... maybe the event system could measure eventloop frequency or wait times and react accordingly.
Not exactly - it was my impression from the discussions with mconnor that it was more along the lines of "we don't want to delay showing the user the main window, so let's do it shortly after".  It still needs to be done shortly after startup since it will also matter for cross-session resumable downloads, which we want to do as soon as possible, but still don't want to delay the main window opening up.
I don't think it'd be an arbitrary point in time, ideally.  Can we just use an nsIIdleService observer to detect when we first go idle for > 2-3 seconds, and then fire 'ui-startup-complete" at that time?  I'd rather do that in the core than have every consumer register their own idleObserver, though I don't know if it really matters, other than to have a clear and documented notification for consumers to observe.
(In reply to comment #1)
> See also Bug 363634
> 

is this bug different from bug 363634 and bug 364304? these bugs are lobbying for an event that signifies that "the first window has loaded, services not critical to startup can begin work".
(In reply to comment #4)
> Can we just use an nsIIdleService observer to detect when we first go idle for
> 2-3 seconds, and then fire 'ui-startup-complete" at that time?

nsIIdleService tracks user-idle time, not app-idle time, so that wouldn't be what we wanted.
(In reply to comment #5)
> is this bug different from bug 363634 and bug 364304? these bugs are lobbying
> for an event that signifies that "the first window has loaded, services not
> critical to startup can begin work".
Yes, because both of those are browser specific.  However, they could benefit from this.

Minusing as this isn't a crasher, dataloss, or sg: item.  Too late in the game.
Flags: blocking1.9? → blocking1.9-
Sayre's of the opinion this should block as he thinks this is essential to fix Ts.  Can people please chime in here?
Flags: blocking1.9- → blocking1.9?
There are things that we do not need to do right away, but can do at some point after we've done all our initial startup work.  This would be the easiest way to do that as far as I can tell.
(In reply to comment #9)
> Sayre's of the opinion this should block as he thinks this is essential to fix
> Ts.  Can people please chime in here?
> 

I agree this should block, need to fish or cut bait on the delayed startup issue, and make Ts not bogus.
Making P3, +'ing and assigning to sayrer.
Assignee: nobody → sayrer
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
(In reply to comment #10)
> There are things that we do not need to do right away, but can do at some point
> after we've done all our initial startup work.  This would be the easiest way
> to do that as far as I can tell.
> 

We can't separate the UI reveal and the work done in this event too much, cause there may be parts of the UI that are not usable until the event work is finished.

(In reply to comment #9)
> Sayre's of the opinion this should block as he thinks this is essential to fix
> Ts.  Can people please chime in here?
> 

Can this really fix Ts? or just change the measurement range?

Bug 364304 is needed by extensions cause they get screwed up by the browser doing work in these "delayed" events. Extensions need to be able to count on services being ready to go at a certain point. So the event that fires for this delayed event can't solve bug 36304. We'd need another event that signals that this delayed event has finished. That sounds like a hack (but it would solve bug 364304)
blocking to make sure that this isn't needed by anything, but sayrer might take it off the list if that condition is satisfied.
Flags: tracking1.9+ → blocking1.9+
Priority: P3 → P2
Sayre - still needed?
we've worked around this elsewhere, afaik
Assignee: sayrer → nobody
Flags: blocking1.9+ → wanted-next+
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.