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"
>
> >
> > 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 post a task
> to close the RenderViewHost asynchronously.
> * When all the windows/tabs are closed, the Chrome is still running
> when there is an active background task. This is done by adding a
> reference count to g_browser_process to keep it live.
> * When a background task is set to start-on-user-login, we will add a
> registry value to HKCU\Software\Microsoft\Windows\CurrentVersion\Run
> to start Chrome executable with "--startup" option. This option tells
> Chrome to load and start background tasks. When there is no longer a
> background task configured to start-on-user-login, the added registry
> value will be removed.
>
> We also implemented systray icon, added bb element and drag-and-drop
> support.
It sounds like the design doc should be updated to contain all of this new
information and to address some of the issues we discussed here.
This background task stuff seems really neat. Thanks for putting so much
thought into it!
-Darin
>
>
> >
> > -Darin
> >
> > On Tue, Oct 28, 2008 at 4: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
-~----------~----~----~----~------~----~------~--~---
