After some internal discussions, I've sent a quite updated proposal which
includes use cases we've looked at ("Global Script"). We've got some
experience of talking with app developers and it seems having a concept of
'application context' or 'global script' is a recurring theme.. The unwanted
seri
On Thu, Aug 13, 2009 at 5:13 AM, Mike Wilson wrote:
>
> Maybe I'm mistaken, but I think Drew wanted handling of
> "live" objects, where each window gets access to the same
> concrete objects (possibly protected by private proxy
> objects) so the graph can be walked without cloning.
To be honest
On Thu, Aug 13, 2009 at 4:07 AM, Ian Hickson wrote:
>
> > Sure, although I'd say that "persistent storage is addressed by the Web
> > Storage and Web Database features". Shared state is also addressed, but
> > that's not the primary goal. If I have a tree of objects that I'd like
> > to share bet
On Thu, Aug 13, 2009 at 4:07 AM, Ian Hickson wrote:
>
> > Additionally, any server-side-feed-based solution has the implication
> > that it won't work for offline apps. If I am using a web calendar, I
> > want my event notifications regardless of whether I'm online or offline
> > (the event may h
Ian Hickson wrote:
>
> On Tue, 4 Aug 2009, Drew Wilson wrote:
> > Sure, although I'd say that "persistent storage is
> > addressed by the Web Storage and Web Database
> > features". Shared state is also addressed, but that's
> > not the primary goal. If I have a tree of objects
> > that I'd li
On Tue, 4 Aug 2009, Drew Wilson wrote:
> On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson wrote:
> >
> > It seems like a direct solution to these would be to have a way for
> > Web pages to expose a service that clients could subscribe to, which
> > could send up database updates and notifications. T
From: John Gregg
Sent: Monday, August 10, 2009 2:34 PM
Michael Kozakewich wrote:
Are notifications really a renderer problem, as opposed to a browser-UI
problem? (e.g. 'Safari' or 'Chromium', rather than 'Webkit')
Also, I don't know of any notifications (Outlook, Messenger, AVG,
Twe
Michael Kozakewich wrote:
> Are notifications really a renderer problem, as opposed to a browser-UI
> problem? (e.g. 'Safari' or 'Chromium', rather than 'Webkit')
> Also, I don't know of any notifications (Outlook, Messenger, AVG,
> TweetDeck, etc.) that require permissions, so I'd argue that requ
From: John Gregg
Sent: Monday, August 10, 2009 12:54 PM
I think it's appeared on this thread before, but I'm currently working on an
API to provide desktop notifications. A patch has been proposed to WebKit at
https://bugs.webkit.org/show_bug.cgi?id=25463.
I had originally proposed it to
> TO SUMMARIZE:
> -There are many other existing ways to notify
> -I'd suggest browsers have a Notification process with which open tabs
> register.
> -Registered open tabs could tell the browser to pop up a notification,
> perhaps with title text, body text, and image
> -Clicking the notification
2009/8/7 Michael Kozakewich
>
>
> TO SUMMARIZE:
> -There are many other existing ways to notify
> -I'd suggest browsers have a Notification process with which open tabs
> register.
> -Registered open tabs could tell the browser to pop up a notification,
> perhaps with title text, body text, and im
On Wed, 29 Jul 2009, Michael Kozakewich wrote:
>
> How many applications do we expect any one user to have open? I would
> imagine one would do fine on the Taskbar or in the Notification Area,
> like other programs, but a manager would be good if a user had a great
> deal of applications running at
From: "Jonas Sicking"
Sent: Friday, August 07, 2009 5:07 PM
2009/7/30 Ian Fette :
That being said, I think there are valid use cases for out-of-band
notifications, for example for calendar events or "status update" type
applications such as Facebook or Twitter.
I'd like to explore whether we c
2009/7/30 Ian Fette (イアンフェッティ) :
>> That being said, I think there are valid use cases for out-of-band
>> notifications, for example for calendar events or "status update" type
>> applications such as Facebook or Twitter.
>>
>> I'd like to explore whether we can accommodate this notification use ca
On Tue, Aug 4, 2009 at 10:47 AM, Jeremy Orlow wrote:
>
> Which use case is this related to? If the shared worker is creating UI
> elements for the page, then composing HTML and sicking it into a div's
> .innerHTML is actually (sadly) the fastest way to go at the moment. Besides
> that, I can't
It seems "persistent" and "preloading" aspects of the
proposal are very hard to do considering security bounds of web
browsing, there are scalability issues and people sometimes don't like
the cost/benefit
or obscurity (Netscape 6 etc).
What about the "shared context with DOM access" idea which, ev
On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson wrote:
> For example, we could base this on the EventSource mechanism or the
> WebSocket mechanism, and define a protocol by which the server can at any
> time send up either:
>
> An INSERT, UPDATE, or DELETE SQL statement
> A string and a URL to sh
On Tue, Aug 4, 2009 at 12:48 PM, Drew Wilson wrote:
> Yeah, this is an interesting idea, although I'm envisioning apps that
> support offline use requiring what amounts to a sync process with
> app-specific conflict resolution, etc - I think this would be difficult to
> support with this kind of ge
On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson wrote:
>
> It seems like a direct solution to these would be to have a way for Web
> pages to expose a service that clients could subscribe to, which could
> send up database updates and notifications. That way, no script runs on
> the client, but the s
On Tue, Aug 4, 2009 at 1:08 AM, Mike Wilson wrote:
> Michael Nordman wrote:
> > On Mon, Aug 3, 2009 at 2:37 PM, Mike Wilson wrote:
> > > Btw, another reflection is that this mail thread is about
> > > introducing a client/server model in the browser. Some
> > > mentions of complex code in the bac
Michael Nordman wrote:
> On Mon, Aug 3, 2009 at 2:37 PM, Mike Wilson wrote:
> > Btw, another reflection is that this mail thread is about
> > introducing a client/server model in the browser. Some
> > mentions of complex code in the background page, f ex building
> > the HTML for the visible window
On Mon, 27 Jul 2009, Michael Davidson wrote:
>
> -- Slow startup: When a user navigates to mail.google.com, multiple
> server requests are required to render the page. The Javascript is
> cacheable, but personal data (e.g. the list of emails to show) is not.
> New releases of Gmail that require
On Mon, Aug 3, 2009 at 2:37 PM, Mike Wilson wrote:
> Michael Nordman wrote:
>>
>> On Mon, Aug 3, 2009 at 3:05 AM, Mike
>> Wilson wrote:
>> >
>> > Assuming this shared state doesn't require a full
>> > JavaScript global context, and could do with some
>> > root object or collection, would it be poss
Michael Nordman wrote:
>
> On Mon, Aug 3, 2009 at 3:05 AM, Mike
> Wilson wrote:
> >
> > Assuming this shared state doesn't require a full
> > JavaScript global context, and could do with some
> > root object or collection, would it be possible to
> > extend Web Storage to support this task?
>
> A
On Mon, Aug 3, 2009 at 3:05 AM, Mike Wilson wrote:
> Drew Wilson wrote:
>>
>> SharedWorkers are overloaded to provide a way for
>> pages under the same domain to share state, but
>> this seems like an orthogonal goal to "parallel
>> execution" and I suspect that we may have ended
>> up with a clean
Drew Wilson wrote:
>
> SharedWorkers are overloaded to provide a way for
> pages under the same domain to share state, but
> this seems like an orthogonal goal to "parallel
> execution" and I suspect that we may have ended
> up with a cleaner solution had we decided to
> address the "shared st
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/30/09 7:26 PM, Michael Davidson wrote:
> On Wed, Jul 29, 2009 at 5:38 PM, Maciej Stachowiak wrote:
>> * Notification Feeds *
>>
>> Often, web applications would like to give users the option to subscribe to
>> notifications that occur at specific
2009/7/29 Maciej Stachowiak
>
> On Jul 27, 2009, at 11:50 AM, Michael Davidson wrote:
>
> Hello folks -
>>
>> I'm an engineer on the Gmail team. We've been working on a prototype
>> with the Chrome team to make the Gmail experience better. We thought
>> we'd throw out our ideas to the list to ge
So use an out-of-band extension mechanism to establish trust and
permissioning for capabilities that fall out of bounds of the 'regular' web
model.
So lets put that to practice on this particular two-part proposal...
> Our proposed solution has two parts.
This first part (below) falls within the
On Thu, Jul 30, 2009 at 3:49 PM, Dmitry Titov wrote:
> I think I almost get this distinction :-) you are saying that HTML+JS could
> be made more powerful with new APIs, but only if it is done sufficiently far
> from the 'regular web page browsing' experience (or model). Say, if it is a
> "browser
I think I almost get this distinction :-) you are saying that HTML+JS could
be made more powerful with new APIs, but only if it is done sufficiently far
from the 'regular web page browsing' experience (or model). Say, if it is a
"browser extension" or a prism-like app it's ok - only (or mostly) bec
I think the error here is viewing this as a UX issue - if it were just a UX
issue, then the responses from people would be along the lines of "Oh, this
sounds dangerous - make sure you wrap it with the same permissions UI that
we have for extensions, plugins, and binary downloads".
The realization
On Thu, Jul 30, 2009 at 3:51 PM, Dmitry Titov wrote:
> This concern is clear. But what could be a direction to the solution?
> Assuming one of the goals for html5 is reducing a gap in capabilities
> between web apps and native apps, how do we move forward with more powerful
> APIs?
>
Giving web
It seems the biggest concern in this discussion is around "BotNet
Construction Kit" as Machej succulently called it, or an ability to run
full-powered platform API persistently in the background, w/o a visible
'page' in some window.
This concern is clear. But what could be a direction to the soluti
On Wed, Jul 29, 2009 at 5:38 PM, Maciej Stachowiak wrote:
> * Notification Feeds *
>
> Often, web applications would like to give users the option to subscribe to
> notifications that occur at specific times or in response to server-side
> events, and for the user to get these UI notifications with
On Jul 27, 2009, at 11:50 AM, Michael Davidson wrote:
Hello folks -
I'm an engineer on the Gmail team. We've been working on a prototype
with the Chrome team to make the Gmail experience better. We thought
we'd throw out our ideas to the list to get some feedback.
THE PROBLEM
We would like t
On Wed, Jul 29, 2009 at 1:53 PM, Jeremy Orlow wrote:
> On Wed, Jul 29, 2009 at 11:43 AM, Michael Davidson wrote:
>
>> On Wed, Jul 29, 2009 at 11:38 AM, Tab Atkins Jr.
>> wrote:
>> > On Wed, Jul 29, 2009 at 1:34 PM, Michael Davidson
>> wrote:
>> >> With a hidden page that's accessible to all Goog
On Wed, Jul 29, 2009 at 1:53 PM, Jeremy Orlow wrote:
> I understand that this isn't helpful for existing web apps like Gmail, but I
> think a MVC type model will work pretty nicely with shared workers. It's
> just the transition phase that's going to be painful.
In most MVC frameworks that I'm aw
On Wed, Jul 29, 2009 at 11:43 AM, Michael Davidson wrote:
> On Wed, Jul 29, 2009 at 11:38 AM, Tab Atkins Jr.
> wrote:
> > On Wed, Jul 29, 2009 at 1:34 PM, Michael Davidson wrote:
> >> With a hidden page that's accessible to all Google Finance visible
> >> pages, they could share a connection to t
On Wed, Jul 29, 2009 at 11:38 AM, Tab Atkins Jr. wrote:
> On Wed, Jul 29, 2009 at 1:34 PM, Michael Davidson wrote:
>> With a hidden page that's accessible to all Google Finance visible
>> pages, they could share a connection to the server. Even if the hidden
>> page is closed when the last Google F
On Wed, Jul 29, 2009 at 1:34 PM, Michael Davidson wrote:
> Here's something that hidden pages can help with that this solution can't:
>
> Let's say you're watching ten stocks on Google Finance, each in their
> own window.
>
> Right now, each page has to have its own connection to the server.
> Sinc
As another data point, the aforementioned Jetpack addon for Firefox
actually *does* run in a hidden page. "about:jetpack" is *always*
present while the add-on is installed, but hidden if you haven't
explicitly pointed a tab at that url.
This doesn't allow it to persist outside of the browser, but
Here's something that hidden pages can help with that this solution can't:
Let's say you're watching ten stocks on Google Finance, each in their
own window.
Right now, each page has to have its own connection to the server.
Since these are polling connections, the experience is going to be
very b
From: Drew Wilson
Sent: Wednesday, July 29, 2009 11:56 AM
On Wed, Jul 29, 2009 at 6:32 AM, Michael Kozakewich
wrote:
-- Notifications: I don't think I've ever had Outlook notify me of new mail
when it's not running. It usually starts up with Windows, and it runs in the
background. If you
On Wed, Jul 29, 2009 at 12:54 PM, Drew Wilson wrote:
> My understanding (when I looked at Prism a while back) was that it was
> essentially no different than a desktop shortcut that ran the page in a
> separate profile. Has this changed?
It runs a webpage in a separate process, in a special enviro
My understanding (when I looked at Prism a while back) was that it was
essentially no different than a desktop shortcut that ran the page in a
separate profile. Has this changed?
-atw
On Wed, Jul 29, 2009 at 10:21 AM, timeless wrote:
> On Wed, Jul 29, 2009 at 7:56 PM, Drew Wilson wrote:
> > What
On Wed, Jul 29, 2009 at 7:56 PM, Drew Wilson wrote:
> What I'd like, as a user, is some way to pin selected apps to run in the
> background - whether that's something I initiate through the UI myself, or
> via a prompt from the application is really a matter of UX.
in my book, you're definitely as
On Wed, Jul 29, 2009 at 6:32 AM, Michael Kozakewich <
mkozakew...@icosidodecahedron.com> wrote:
>
>> It sounds like the "hidden page" idea is just the solution you thought up
> to the problem of keeping a page running. How many other reasons are there
> for it?
Not sure what other motivations th
On Wed, Jul 29, 2009 at 7:19 AM, Tab Atkins Jr. wrote:
>
>
> Firefox's Jetpack addon (essentially Greasemonkey turned up to 11)
> exposes a super-convenient jetpack.notifications.show() function for
> doing exactly that. It pops up an attractive notification in the
> lower right-hand corner of th
On Wed, Jul 29, 2009 at 8:32 AM, Michael
Kozakewich wrote:
> From: "Michael Davidson"
> Tuesday, July 28, 2009 11:24 PM
>>
>> Having some sort of desktop presence is important for parity
>> with desktop apps. Perhaps the install UI could look and feel more
>> like the UI for installing a native ap
From: "Michael Davidson"
Tuesday, July 28, 2009 11:24 PM
Having some sort of desktop presence is important for parity
with desktop apps. Perhaps the install UI could look and feel more
like the UI for installing a native app?
Michael
If you're going to have an installation, why not make it a
On Jul 27, 2009, at 8:23 PM, Aryeh Gregor wrote:
On Mon, Jul 27, 2009 at 9:39 PM, Maciej Stachowiak
wrote:
Persistent workers are even more of a security risk, since they are
supposed
to persist even after the browser has been restarted, or after the
system
has been rebooted. Persistent w
It feels like this has become a discussion of which dangerous feature is
more dangerous
Several browsers (or browser like things) have mechanisms for allowing the
installation of potentially dangerous things.
For example, FireFox has the extension install mechanism. Google Chrome
has/must hav
On Wed, Jul 29, 2009 at 4:47 PM, Michael Davidson wrote:
> I agree 100%. I'm only trying to argue that from a user perspective,
> access that we currently have acceptable UI for, e.g. camera hardware,
> is about as scary as agreeing to let a web app run in the background.
> The consequences of a
On Tue, Jul 28, 2009 at 9:47 PM, Michael Davidson wrote:
> I agree 100%. I'm only trying to argue that from a user perspective,
> access that we currently have acceptable UI for, e.g. camera hardware,
> is about as scary as agreeing to let a web app run in the background.
The whole point is pre
Michael Davidson wrote:
I didn't realize this. So you think that everything on
addons.mozilla.org is vetted enough to not include malware?
We try... Note that given the extension model you don't have to put a
binary blob in the extension either, since extensions can make HTTP
requests and wr
On Tue, Jul 28, 2009 at 9:44 PM, Peter Kasting wrote:
> On Tue, Jul 28, 2009 at 9:39 PM, Michael Davidson wrote:
>>
>> Personally, I'd rather have my CPU and RAM used to send spam than to
>> have pictures of me in my underwear publicly placed on Facebook.
>
> The rest of the world would rather not
On Tue, Jul 28, 2009 at 9:38 PM, Boris Zbarsky wrote:
> I don't think it is, no. Taking a picture is a one-time activity; the user
> knows exactly what he's getting into. And once the picture is taken, no
> more picture-taking until the user says so explicitly.
FYI, this is not the case. Flash c
On Tue, Jul 28, 2009 at 9:39 PM, Michael Davidson wrote:
> Personally, I'd rather have my CPU and RAM used to send spam than to
> have pictures of me in my underwear publicly placed on Facebook.
The rest of the world would rather not receive that spam, and would probably
rather we didn't write
On Tue, Jul 28, 2009 at 9:34 PM, Peter Kasting wrote:
> Not at all. Malware can't set up a darknet using cameras. Your CPU, disk
> and RAM are much more valuable to a malicious coder than your camera.
Personally, I'd rather have my CPU and RAM used to send spam than to
have pictures of me in my
Michael Davidson wrote:
- As for persistence beyond browser lifetime, I understand the
reticence. However, similar problems have been solved in the past.
Flash asks the user for access to hardware like cameras. Surely being
able to take pictures of users is as scary as running code after the
brow
On Tue, Jul 28, 2009 at 9:24 PM, Michael Davidson wrote:
> These are true, but leave out the part that rewriting large apps to
> the worker API is nontrivial. A major advantage of a hidden page (as
> you mention below) is that the programming model is well known, and
> easy for web developers to
On Tue, Jul 28, 2009 at 4:19 PM, Michael Nordman wrote:
> What if a sharedContext isn't gauranteed to be a singleton in the browser. A
> browser can provide best effort at co-locating pages and sharedContexts, but
> it can't gaurantee that, and the spec respects that.
> The lesser gaurantee is that
Sorry for starting and then dropping out of the discussion for a few days.
- I agree with everyone else that there are two parts to the proposal.
The first, less controversial part is a shared context that lives
inside of the browser. As Aaron points out, this is very similar to
Chromium extension
On Tue, Jul 28, 2009 at 2:12 AM, Jonas Sicking wrote:
> On Tue, Jul 28, 2009 at 1:38 AM, Maciej Stachowiak wrote:
> >
> > On Jul 27, 2009, at 10:51 PM, David Levin wrote:
> >
> > It sounds like most of the concerns are about the 2nd part of this
> proposal:
> > allowing a background page to conti
On Tue, Jul 28, 2009 at 1:38 AM, Maciej Stachowiak wrote:
>
> On Jul 27, 2009, at 10:51 PM, David Levin wrote:
>
> It sounds like most of the concerns are about the 2nd part of this
> proposal: allowing a background page to continue running after the visible
> page has been closed.
>
> However, t
On Tue, Jul 28, 2009 at 1:01 PM, Drew Wilson wrote:
> So (and forgive me for restating), it seems like hidden page addresses the
> following problems that gmail and other large web apps are having:
>
> 1) Loading large amounts of Javascript is slow, even from cache.
>
2) Loading application state
On Tue, Jul 28, 2009 at 2:23 PM, Adam de Boor wrote:
>
>
> 2009/7/28 Jonas Sicking
>>
>> The only concern I see with this is that it permanently forces all
>> windows from the same domain to run in the same process. As things
>> stand today, if the user opens two tabs (or windows) and navigates to
could the botnet concern be addressed by restricting network access from the
background page when there is no foreground page referencing it? e.g.
restrict it to requests to the same origin, no matter how those requests are
made? wouldn't let gmail precache linked images, when fetching new mail, bu
2009/7/28 Jonas Sicking
>
> The only concern I see with this is that it permanently forces all
> windows from the same domain to run in the same process. As things
> stand today, if the user opens two tabs (or windows) and navigates to
> the two different pages on www.example.com, then a browser
On Mon, Jul 27, 2009 at 11:50 AM, Michael Davidson wrote:
> Hello folks -
>
> I'm an engineer on the Gmail team. We've been working on a prototype
> with the Chrome team to make the Gmail experience better. We thought
> we'd throw out our ideas to the list to get some feedback.
>
> THE PROBLEM
>
>
To clarify - I said that *persistent workers* could restrict x-domain
network access. I didn't mean to imply that you could apply this same
reasoning to hidden pages - I haven't thought about hidden pages enough to
comment about the implications of that, since as you mention there are many
more net
On Tue, Jul 28, 2009 at 1:01 PM, Drew Wilson wrote:
> I've been kicking around some ideas in this area. One thing you could do
> with persistent workers is restrict network access to the domain of that
> worker if you were concerned about botnets.
How would that work for background pages, though?
I've been kicking around some ideas in this area. One thing you could do
with persistent workers is restrict network access to the domain of that
worker if you were concerned about botnets. That doesn't address the "I
installed something in my browser and now it's constantly sucking up my CPU"
issu
Michael Davidson wrote:
...
WHY NOT SHARED WORKERS
Shared workers and persistent workers are designed to solve similar
problems, but don't meet our needs. The key difference between what
we're proposing and earlier proposals for persistent workers is that
background pages would be able to laun
Minimizing to the notification area is about the only thing, I think, that
we can't already do in a modern browser. If the page persists, it must be
visible (maybe with a user option to make it completely invisible). This
way, the user could at any time click the weblication and choose the 'clos
On Tue, Jul 28, 2009 at 3:02 AM, Jonas Sicking wrote:
> Google Chrome (and I think other browsers) allow pages to be
> "installed" as web applications which run in a separate window. It
> would be interesting to look at the UI for that feature. However
> installApp allows something even more powerf
On Tue, Jul 28, 2009 at 1:38 AM, Maciej Stachowiak wrote:
>
> On Jul 27, 2009, at 10:51 PM, David Levin wrote:
>
> It sounds like most of the concerns are about the 2nd part of this proposal:
> allowing a background page to continue running after the visible page has
> been closed.
> However, the f
On Jul 27, 2009, at 10:51 PM, David Levin wrote:
It sounds like most of the concerns are about the 2nd part of this
proposal: allowing a background page to continue running after the
visible page has been closed.
However, the first part sounds like it alone would be useful to web
applica
On Mon, Jul 27, 2009 at 5:53 PM, Maciej Stachowiak wrote:
> On Jul 27, 2009, at 6:42 PM, Robert O'Callahan wrote:
>> On Tue, Jul 28, 2009 at 6:50 AM, Michael Davidson wrote:
>>> As mentioned in earlier discussions about persistent workers,
>>> permissioning UI is a major issue.
>>
>> Indeed, the m
On Mon, Jul 27, 2009 at 9:51 PM, David Levin wrote:
> It sounds like most of the concerns are about the 2nd part of this proposal:
> allowing a background page to continue running after the visible page has
> been closed.
> However, the first part sounds like it alone would be useful to web
> appli
It sounds like most of the concerns are about the 2nd part of this proposal:
allowing a background page to continue running after the visible page has
been closed.
However, the first part sounds like it alone would be useful to web
applications like GMail:
The first, which should begenerally usef
On Mon, Jul 27, 2009 at 11:50 AM, Michael Davidson wrote:
THE PROBLEM
feature parity with desktop applications.
A SOLUTION
hidden HTML/JS page running
in the background that can access the DOM of visible windows.
KNOWN ISSUES
As mentioned in earlier discussions about persistent workers,
On Mon, Jul 27, 2009 at 9:39 PM, Maciej Stachowiak wrote:
> Persistent workers are even more of a security risk, since they are supposed
> to persist even after the browser has been restarted, or after the system
> has been rebooted. Persistent workers should be renamed to "BotNet
> Construction Ki
On Jul 27, 2009, at 7:13 PM, Aryeh Gregor wrote:
I'm not clear how the UI requirements here are different from
persistent workers, though. Those also persist after the user
navigates away, right?
Persistent workers are even more of a security risk, since they are
supposed to persist even a
On Mon, Jul 27, 2009 at 8:42 PM, Robert O'Callahan wrote:
> Indeed, the most difficult issue here is security and the permissions UI,
> which you haven't addressed at all.
One obvious solution would be to have installation UI like extensions,
but somewhat less scary (no signing requirements, count
On Jul 27, 2009, at 6:42 PM, Robert O'Callahan wrote:
On Tue, Jul 28, 2009 at 6:50 AM, Michael Davidson
wrote:
As mentioned in earlier discussions about persistent workers,
permissioning UI is a major issue.
Indeed, the most difficult issue here is security and the
permissions UI, which y
On Tue, Jul 28, 2009 at 6:50 AM, Michael Davidson wrote:
> As mentioned in earlier discussions about persistent workers,
> permissioning UI is a major issue.
>
Indeed, the most difficult issue here is security and the permissions UI,
which you haven't addressed at all.
Currently, when you close
On Mon, Jul 27, 2009 at 11:50 AM, Michael Davidson wrote:
> THE PROBLEM
>
>
> feature parity with desktop applications.
>
>
> A SOLUTION
>
>
> hidden HTML/JS page running
> in the background that can access the DOM of visible windows.
>
>
> KNOWN ISSUES
>
> As mentioned in earlier discussions
>
> 2) For multi-process browsers like Chrome, there seem to be limitations as
> to what can actually be accessed between processes (direct DOM access across
> process boundaries seems problematic for example). Do you have ideas about
> how to address this, since assumedly the page calling getInsta
This sounds really powerful, and seems like a natural evolution of some of
the stuff we've discussed previously for persistent workers. A few
comments/notes:
1) It sounds like this background page would act like any other web page
with respect to its processing model (i.e. like other pages, script
Hello folks -
I'm an engineer on the Gmail team. We've been working on a prototype
with the Chrome team to make the Gmail experience better. We thought
we'd throw out our ideas to the list to get some feedback.
THE PROBLEM
We would like to enable rich internet applications to achieve feature
par
92 matches
Mail list logo
