Add proposal for runtime.onEnabled and runtime.onExtensionLoaded events #729
Conversation
|
Thanks for writing the formal proposal and sponsoring the implementation. |
| export type OnLoadedReason = 'enabled' | | ||
| 'installed' | | ||
| 'updated' | | ||
| 'profileStart' | |
There was a problem hiding this comment.
I don’t think “profile” should be in the name here. I think this should be started (to be consistent with the other -ed words). Not all browsers have profiles, and many users only use a single profile, so referencing “profile” could create unnecessary confusion or imply a narrower scope than intended.
All the other reasons — enabled, installed, updated, and reload — also apply to profiles since these actions occur within a specific profile context, but they avoid explicitly mentioning profiles.
Similarly, using a name like started ensures consistency with the other past-tense reason names while keeping the terminology universal and clear.
There was a problem hiding this comment.
Makes sense. I have renamed it to started.
There was a problem hiding this comment.
I don't think we should use "started", because it's ambiguous what "started" means -- without additional explanation, that could also mean the background context started, or the extension got an active process, or any number of other things.
Maybe "browserStart"? Technically, that's not strictly true, since in the case of browsers that support profiles, the browser may have already been running -- but given extensions are scoped to profiles, I think this abstraction is okay.
WDYT?
There was a problem hiding this comment.
@rdcronin browserStart also introduces ambiguity. It suggests the event is tied directly to the browser process starting, which as you say, isn’t strictly true, especially with multiple profiles (the opposite problem of the original profileStart). This can mislead developers into thinking the event is narrower in scope than it is and does not apply to profiles.
My main concern with “profile” (besides the tense and camel case — we really need to be consistent with value strings) is that this is, as far as I know, the first mention of profiles in the extension API. While the other enum values equally apply to profiles, they don’t mention profiles — and they shouldn’t. (If all enum values equally apply to the same context, explicitly mentioning the context in the values is redundant and unnecessary.) Hence, why I still think started is perfectly fine since it applies to the profile just like all the other reasons.
If started isn’t acceptable, another option would be initialized. It’s clear, concise, and consistent with past-tense naming conventions like enabled, installed, and updated. It has the connotation that it only happens once per profile load, while keeping the terminology flexible enough to apply across different scenarios, such as profile or browser-level startup.
There was a problem hiding this comment.
@xeenon the reason I'm okay with the ambiguity of browserStart is that, from the extension's POV, it is the browser start -- no other existing windows or behavior is exposed to the extension, so it shouldn't know or care about them. There could always be other browser instances running (multiple channels or running completely different browsers), so I don't think any extension should ever assume that, even with "browserStart", it means "there are definitely no other browser-like things running". That said, if we wanted to avoid browserStart, how about sessionStart? That has its own set of ambiguity ("session" on the web means something different), but is perhaps more clear?
Agreed we need to come to a conclusion on the value strings. Let's plan on discussing that soon. I don't think it's a scalable solution to say we'll only add one-word enum values : )
In the interest of parallelizing this work, WDYT about adding a specific note that this name is TBD, but otherwise allowing this to proceed (perhaps merge with an explicit TODO or similar)? We can be sure to finalize the name before we launch the API in any browser.
There was a problem hiding this comment.
Personally, I like the word init, startup or firstStart. It is the starting point of the extension's lifecycle. We already use the name in runtime.onStartup().
browserStart is OK for me. I don't like the word session , it's ambiguous for me.
There was a problem hiding this comment.
@xeenon To clarify, I'm suggesting we unblock implementation work, not that we ship this in any browser. We would absolutely have it be a requirement to finalize all names before shipping anything. But if the only remaining bit is bikeshedding the name, I think Sohail could get a start on the implementation while we discuss, rather than blocking that. Does that sound reasonable? (Though, maybe moot, depending on below)
@hanguokai I like startup, which is subtly different IMO from started, and as you pointed out, has precedence with runtime.onStartup. I don't think firstStart makes sense, because it's ambiguous what "first" is related to ("firstStart" could also mean "install"), and I think "init" is generally unclear.
Anyone else have thoughts on startup vs browser-start vs session-start?
There was a problem hiding this comment.
🎉 Thanks for the suggestion, @hanguokai , and for the discussion, @xeenon !
There was a problem hiding this comment.
Yes, having startup makes sense as it is similar to runtime.onStartup. I have updated the proposal. Thank you for the inputs here @rdcronin, @xeenon and @hanguokai 😄
| There is currently `chrome.runtime.onInstalled`, and `chrome.runtime.onStartup`. | ||
| These API have gaps in listening that are addressed by these two events. In | ||
| short, `chrome.runtime.onEnabled`, covers the remaining status that developers | ||
| care to know, and `chrome.runtime.onExtensionLoaded` encapsulates them all | ||
| together with a single listener. |
There was a problem hiding this comment.
Should the other events be soft deprecated now and slated for removal in the next manifest version bump? (I think so, as they are redundant now.)
There was a problem hiding this comment.
The impression I got from past discussions is that we see some value in having discrete events, for the cases where you do only want to listen to a particular part of the lifecycle. While I agree they are technically redundant, since we already have them I'm not sure if we should go out of our way to remove them.
There was a problem hiding this comment.
I agree that the old events are now technically redundant. If we want to soft-deprecate them, I think we can discuss that separately. What do you think?
|
@Rob--W - Can you also take a look at this one? |
Creating a proposal for #353. This is based on @justinlulejian's proposal document here:
https://docs.google.com/document/d/1Fpqg-cQRoNkQVL-hoQi5fqhVoOEdjOiGoQXWdw_yFxo/edit?tab=t.0