Thanks for your great feedbacks. Please see my comments below. On Oct 29, 2:03 pm, "Nick Baum" <[EMAIL PROTECTED]> wrote: > *Permissions:* I agree with Brian that drag-n-drop is somewhat clumsy for > granting permissions (see how well that works for bookmarklets...). I'm > syncing up with Mike Smith on this tomorrow, and Glen and I will work on a > better > solution.
We're still in active discussion on a better (more discoverable and simple) opt-in mechanism. We're discussed click for permission dialog, install wizard and drag-and-drop. Once we come to a better solution, I will update the spec. > > Also, what happens next time I visit the app? Is it authorized to launch the > background task, or do I have to re-authorize it? When the background task is allowed to start, it will continue to run even when the browser is exited. Next time when the system is started and the user logs in, the background task will run automatically without any re-authorization since the permission has already been granted last time. > > *Lifetime:* Do we need the "start on browser launch" option? What's the use > case for this? We'll remove this option from the API. However, to address concern from those people with limited bandwidth or lack of resource, the browser can add an option to let the user choose between start-on- login and start-on-browser-launch. > > *Process model:* Are there cases when a background task would need to > communicate with the tab that created it? For example, opening an event in > an existing calendar window. Yes, the host page can talk to the background task through cross- process MessagePort communication. > > Overall, this seems like a well thought-out proposal! > > -Nick > > On Wed, Oct 29, 2008 at 1:11 PM, Dmitry Titov <[EMAIL PROTECTED]> wrote: > > Good idea about OK delay... > > That part of the proposal is indeed the most controversial. Some folks love > > it, some hate it. Modal dialog can provide UI for "learn more...", ask for > > specific permissions, perhaps even capture credentials to use while running > > in the background. On the other side, "Allow/Deny" dialogs are sometimes > > bad because they basically shift blame to the user w/o transparency on > > what's going on. > > So we do expect opt-in mechanism will perhaps change - please voice any > > idea you like more. > > > Dmitry > > > On Tue, Oct 28, 2008 at 6:43 PM, Brian Rakowski <[EMAIL PROTECTED]>wrote: > > >> Drag and drop seems like a clumsy and unfamiliar mechanism for granting > >> this capability. A modal dialog would be better. We can inject a delay on > >> making the OK button active if we are worried about clever attacks that get > >> users to click on an OK that appears underneath the cursor. > >> -Brian > > >> On Tue, Oct 28, 2008 at 5:55 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED] > >> > wrote: > > >>> Hi all, > > >>> Here is a draft of a design doc for Background Browser Task: > > >>>http://docs.google.com/View?docid=dd6rm2wb_3fmz8pnnp > > >>> Your feedback is appreciated. > > >>> Thanks, > > >>> Jian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
