On Wed, Apr 22, 2009 at 5:07 PM, Nick Baum <[email protected]> wrote:
> On Wed, Apr 22, 2009 at 4:38 PM, Aaron Boodman <[email protected]> wrote:
>>
>> So Finnur is looking at the Page Actions API
>>
>> (http://dev.chromium.org/developers/design-documents/extensions/page-actions-api).
>> Right now, the proposed API for creating one of these bad boys is:
>>
>> create({string name, [string javascript], [string faviconUrl], [bool
>> executeInPage]}, [function callback(PageAction new)])
>>
>>
>> I would like to change two main things about this:
>>
>> a) Usually page actions are associated with a tab. When you switch
>> tabs, they should automatically be switched. The extension developer
>> shouldn't have to manually manage that. There are also page actions
>> which apply to every page, but we could support that separately.
>
> I think we should probably provide both. The API you propose looks good for
> the per-tab case. We could have the same API without a tabID for the
> cross-tab case.
I agree both seem useful. I'm only considering the per-tab case here.
But I think that it is trivial to make this work cross-tab by just not
specifying a tab ID. Another way to do the same would be to register
them in the manifest, but I haven't thought too hard about how that
would work.
>> b) I would like the callback to be in the form of a function, not a
>> string of JavaScript. Functions are better because they can have
>> closures that allow you to keep references to local state, and are
>> just more JavaScripty in general.
>
> Where would this function execute? In the extension context or the page
> context?
> A lot of the bookmarklet-like use cases are easier to implement in the page
> context.
That is part of what is cool about using a function -- is clears up
this confusion. It only makes sense for a function to execute in the
context it came from (because of closures) so that is where it must
execute. We don't need to document it.
It is true that a lot of these things may want to get at the page
context, but I think that it may make more sense to have them do an
extra API call for that (executeScriptInTab() or whatever).
One reason is that in order to register this page action, you already
had to have code running in the extension. It is therefore really
natural to just have the callback be an actual function, running in
the same context you made the call from.
Another reason is that page actions which interact with pages may have
already had to run a content script in order to figure out they were
active. So they may not actually need to run code again in the page at
invocation time since they already learned whatever it was they needed
to. That is the case anyway with an RSS icon: it already got the info
it needed at page load time; it doesn't need to go back to the page at
click time.
>> So I would change it to something like:
>>
>> create({string name, int tabId, string iconUrl, function onExecute()},
>> [function callback(PageAction new)])
>
> How about get/delete/update? We talked about limiting these to actions
> created by the extension.
Yeah, those functions seem more straightforward (and also less
important). Right now I'm just concerned with creation.
- a
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected]
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
