[chromium-dev] Re: Design doc: Background Browser Task
On Fri, Oct 31, 2008 at 3:11 PM, [EMAIL PROTECTED] [EMAIL PROTECTED]wrote: 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. Is this spelled out anywhere? E.g. it's not exactly natural for something tied to your browser to keep running after you close your browser. I fear this may be quite un-expected for users. How does a user know that their notification will keep running after they close the browser? How do they stop that if they want? Does end task correspond to revoke my permission to run this notification and don't launch it again or does it mean just stop it now, but it may re-start at any 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 chromium-dev@googlegroups.com 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Design doc: Background Browser Task
... 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. Is this spelled out anywhere? E.g. it's not exactly natural for something tied to your browser to keep running after you close your browser. I fear this may be quite un-expected for users. How does a user know that their notification will keep running after they close the browser? In my mock-up [1] the first notification asks the user: (icon) www.calendardemo.net will be able to notify you. will be always on Allow / Cancel This notification should show that it originates from the tray icon (*). That way, as long as the tray icon stays it should be quite clear what always-on means? For this purpose it is important that the tray icon always stays in the tray area while background tasks are running, i.e. not appear only when Chrome is closed like it has been suggested. (The word always-on could be maybe be explained with tooltips or by clicking the word in the notification. Also able to notify you could benefit from some more explanation.) (*) ideas how to show that: maybe by animating the tray icon when notifications appear and when they close, or make the notification bubble into a cartoon speech bubble originating from the tray icon How do they stop that if they want? Does end task correspond to revoke my permission to run this notification and don't launch it again or does it mean just stop it now, but it may re-start at any time? There are rumoured settings, either user-wide or per background task, about whether to allow tasks to run before and after the normally visible browser. The easiest would be to simply let the user decide if they can spare (want to pay for) CPU and bandwidth also when the browser is closed. If done well, that could limit the amount of misunderstandings (and complaints) about Chrome not closing properly. [1] http://sites.google.com/site/chromiumdev/notifications --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Design doc: Background Browser Task
why i can't download the doc??? On 10月29日, 上午8时55分, [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 chromium-dev@googlegroups.com 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Design doc: Background Browser Task
I do not have any problem to open the document. Could you please try again? Thanks. On Nov 5, 6:43 am, bzero [EMAIL PROTECTED] wrote: why i can't download the doc??? On 10月29日, 上午8时55分, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi all, Here is a draft of a design doc forBackgroundBrowserTask: 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 chromium-dev@googlegroups.com 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Design doc: Background Browser Task
On Nov 4, 9:11 am, Darin Fisher [EMAIL PROTECTED] wrote:
Some comments:
1. Returns the port for the host page to communicate with the background
task. Null is returned if the task is not started. -- How do you find out
when the task is started?
We used to provide a DOM event onStart. For the purpose of keeping
the addition to bb element simple, we decide to remove it.
2. When there is any background task running and all Chrome windows are
closed, Chrome will put up a systray icon to indicate that there are some
number of background tasks being running. When the user clicks the systray
icon, Chrome will be launched with the background tab opened. -- What is
the background tab?
I forgot to remove background tab from the latest design doc. I will
remove it and replace with launch the task manager.
3. In task manager, all active background tasks are also listed and have a
button for the tasks to be ended and removed. -- Task manager only
provides options to kill a plugin process or a process hosting a collection
of tabs. As is, I'm not sure that it would be a good background task
manager.
Thanks for advising. I think we can still list background tasks in
task manager and the user can kill them from there. We will put the
end and remove functionality in systray menu.
4. What happens if a background task calls
window.{alert,prompt,confirm,showModalDialog}?
The actions will be simply ignored except alert. For alert, we can
route it to the notification.
5. The background task should detect this and show a notification message
to tell the user to launch a sign-in page. -- What is the mechanism to
show a notification message?
We also have a design doc for notification. The background task page
could call the notification API to do it.
6. When there is any fatal error happening during loading or executing the
background task, or the task just crashes or hangs, a notification message
will be shown from the sys-tray icon and the user could clicks on the
message to go to the help page of the host site to find out more
information. -- This doesn't sound like the right behavior in the case of
crashes or hangs. In the case of a hang, Chrome should probably just kill
the background task if it remains unresponsive for some amount of time. In
that case or if the tab experiences a crash, Chrome should do something like
Sad tab to inform the user of the error, giving the user the ability to
restart the background task perhaps?
Since the background task is running invisibly, I think it might be
better to inform the user of the error via notification message,
instead of sad tab. We can give the user the ability to restart the
background task.
7. Incognito support: If a web page is running under incognito mode, it
cannot start any background task. This is because we respect the user's
privacy in this mode and will not permit any hidden things to be
performed. -- Incognito mode tries not to break the web. Maybe it is OK
to allow background tasks from incognito windows provided the incognito
window is still alive. Once the last incognito window closes, then we could
kill all associated background tasks. This way if background tasks are
required by some website, they could still be used when incognito.
Sounds reasonable.
8. It feels like background task is just a hidden tab feature. It might be
good if there were UI to force background tasks to be opened as normal
visible tabs. In other words, it seems like background tasks do not need to
be hidden to function. It is just preferred UI to have them hidden by
default.
Yes, it acts like a hidden tab. However, it is still alive when the
browser is exited. In addition, it is auto-started on user login. It
is indeed more like a service. We can add the UI to bring it to
foreground but we're not sure if this is really useful for a
service.
I have many questions about implementation. I don't see much discussion
about implementation in the design doc, yet it seems from the volume of
changes that you are probably well into the implementation. Can you comment
on your implementation approach?
Our implementation is checked into the branch
svn://chrome-svn/chrome/branches/background_tasks/src/.
Here are what we currently implemented for managing background tasks:
* BackgroundTaskManager is responsible to manage all background tasks
for a profile.
* To register a background task, BackgroundTaskManager::RegisterTask
should be called. In addition to the info kept in the manager class,
the task info is also written into the preferences store of the
profile.
* To start a background task, BackgroundTaskManager::StartTask should
be called. An instance of BackgroundTaskRunner, that implements
RenderViewHostDelegate, is created and it then creates RenderViewHost
and use it to render the page.
* To end a background task, BackgroundTaskManager::EndTask should be
called. Then BackgroundTaskRunner::Shutdown is called to
[chromium-dev] Re: Design doc: Background Browser Task
On Tue, Nov 4, 2008 at 11:01 AM, [EMAIL PROTECTED] [EMAIL PROTECTED]wrote:
On Nov 4, 9:11 am, Darin Fisher [EMAIL PROTECTED] wrote:
Some comments:
1. Returns the port for the host page to communicate with the
background
task. Null is returned if the task is not started. -- How do you find
out
when the task is started?
We used to provide a DOM event onStart. For the purpose of keeping
the addition to bb element simple, we decide to remove it.
But how does one access the port to the background task? Do they have to
use setTimeout to write code to poll for it?
2. When there is any background task running and all Chrome windows are
closed, Chrome will put up a systray icon to indicate that there are some
number of background tasks being running. When the user clicks the
systray
icon, Chrome will be launched with the background tab opened. -- What
is
the background tab?
I forgot to remove background tab from the latest design doc. I will
remove it and replace with launch the task manager.
Hmm... the idea of background tasks being representable as real tabs seemed
appealing to me. To the application, why should it matter how the
background task is rendered? To the user, it could be a powerful feature
to be able to expose the window of background tasks as a normal browser
window where each background task is represented by a normal tab. You could
even have a user option to minimize a tab to the systray which would just
cause it to become a background task / tab.
3. In task manager, all active background tasks are also listed and
have a
button for the tasks to be ended and removed. -- Task manager only
provides options to kill a plugin process or a process hosting a
collection
of tabs. As is, I'm not sure that it would be a good background task
manager.
Thanks for advising. I think we can still list background tasks in
task manager and the user can kill them from there. We will put the
end and remove functionality in systray menu.
I see.
4. What happens if a background task calls
window.{alert,prompt,confirm,showModalDialog}?
The actions will be simply ignored except alert. For alert, we can
route it to the notification.
OK
5. The background task should detect this and show a notification
message
to tell the user to launch a sign-in page. -- What is the mechanism to
show a notification message?
We also have a design doc for notification. The background task page
could call the notification API to do it.
OK
6. When there is any fatal error happening during loading or executing
the
background task, or the task just crashes or hangs, a notification
message
will be shown from the sys-tray icon and the user could clicks on the
message to go to the help page of the host site to find out more
information. -- This doesn't sound like the right behavior in the case
of
crashes or hangs. In the case of a hang, Chrome should probably just
kill
the background task if it remains unresponsive for some amount of time.
In
that case or if the tab experiences a crash, Chrome should do something
like
Sad tab to inform the user of the error, giving the user the ability to
restart the background task perhaps?
Since the background task is running invisibly, I think it might be
better to inform the user of the error via notification message,
instead of sad tab. We can give the user the ability to restart the
background task.
Yeah... i didn't mean to literally show a sad tab. I was just imaging UI
that evoked a similar effect. Maybe the notification would show an icon of
some sort indicative of a sad background task.
7. Incognito support: If a web page is running under incognito mode, it
cannot start any background task. This is because we respect the user's
privacy in this mode and will not permit any hidden things to be
performed. -- Incognito mode tries not to break the web. Maybe it is
OK
to allow background tasks from incognito windows provided the incognito
window is still alive. Once the last incognito window closes, then we
could
kill all associated background tasks. This way if background tasks are
required by some website, they could still be used when incognito.
Sounds reasonable.
8. It feels like background task is just a hidden tab feature. It might
be
good if there were UI to force background tasks to be opened as normal
visible tabs. In other words, it seems like background tasks do not need
to
be hidden to function. It is just preferred UI to have them hidden by
default.
Yes, it acts like a hidden tab. However, it is still alive when the
browser is exited. In addition, it is auto-started on user login. It
is indeed more like a service. We can add the UI to bring it to
foreground but we're not sure if this is really useful for a
service.
It might help users feel more comfortable about the idea of hidden tabs
[chromium-dev] Re: Design doc: Background Browser Task
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 chromium-dev@googlegroups.com 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Design doc: Background Browser Task
First thoughts: 1. It would be good if this proposal converged in some way with HTML 5 workers 2. There needs to be a way to name and communicate with these tasks (perhaps HTML 5 worksers have such a thing?) 3. I also don't see a need for the start on browser launch option 4. I don't think we should make any process/thread guarantees in the API. That should be an implementation detail 5. Please get feedback from Aaron Boodman and Chris Prince who have done extensive work on ... uh... workers. Linus On Wed, Oct 29, 2008 at 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. 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? Lifetime: Do we need the start on browser launch option? What's the use case for this? 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. 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 chromium-dev@googlegroups.com 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Design doc: Background Browser Task
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? Surely it has to stay authorized. Someone I asked even expected that authorization to follow them between different computers! *Lifetime:* Do we need the start on browser launch option? What's the use case for this? *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. About Lifetime: users that pay for bandwidth, or have lack of RAM, might want to be able to close this process together with the browser. Those poor on RAM might also want the process to not start on Login, but only after the browser is started. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Design doc: Background Browser Task
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 chromium-dev@googlegroups.com 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 -~--~~~~--~~--~--~---
