On Tue, Jul 28, 2009 at 3:22 PM, Aaron Boodman <[email protected]> wrote:
> On Tue, Jul 28, 2009 at 12:20 PM, Aaron Boodman<[email protected]> wrote: > >> We'll always know what extension the onConnectExternal event will be > fired > >> at when the connectExternal() call is made, so at the very least we > could > >> promise that no onConnectExternal event will be fired at an extension > until > >> its background page, if there is one, has fully loaded. Queuing until > all > >> extensions' background pages load is a simpler way to guarantee the same > >> thing. > >> > >> Using the manifests could be a way to have a clever implementation, but > in > >> general the best you can get out of manifests is a partial order of > >> extensions and you might get cycles. > > > > True. I guess I am worried about blocking an extension from > > communicating with, eg, itself, until all other extensions have loaded > > their background pages. This doesn't seem fair. > > I like your other proposal best, of just queuing onConnect events > fired at an extension until its background page has loaded. We should > do this for extensions talking to themselves, too. > > - a Cool. I added some language to the wiki page to extend the Events api so that all events (onConnect, onConnectExternal, etc) are enqueued until the background has a chance to load so that all extensions have safe way to register handlers. - James --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
