On Thu, Aug 25, 2011 at 3:23 PM, Ian Hickson i...@hixie.ch wrote:
Will the methods above adequately handle this?
I believe from Gmail's perspective, yes.
Notifications shouldn't require any clicks at all. They should just work,
initially constrained to the browser page, with an
For rPH, please don't require a user-initiated click for the call. That's
one very annoying thing about notifications - it takes users two clicks to
enable them, and every app has to find some suitable in-page UI to ask users
to make the first click. Since both notifications and rPH are confirmed
On Tue, Jul 5, 2011 at 1:14 PM, Boris Zbarsky bzbar...@mit.edu wrote:
so I don't think the same standards should apply.
If anything, persistent permission grants should have a _higher_ bar than
opening a temporary pop-up window...
Granting permission, yes. But just asking for permission?
On Tue, Jul 5, 2011 at 2:00 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/5/11 4:48 PM, Michael Davidson wrote:
Granting permission, yes. But just asking for permission?
If the asking for permission can happen in a context in which the user
can't tell what's being asked for, it's a really
Has anyone seen a site that refuses to work unless notifications are active?
I suggest that we follow the notification model since it seems to work well
for both site authors and users.
I imagine that if sites force users to accept notifications or protocol
handlers, those sites won't have many
From my perspective on Gmail, I would prefer to know if the user hasn't
registered because they declined previously or haven't been asked. If
they've declined previously, then calling registerProtocolHandler() in
today's UAs will not do anything. If I can't detect that state, then they'll
keep
On Fri, Jul 1, 2011 at 3:03 PM, Ojan Vafai o...@chromium.org wrote:
I'm not sure what the privacy issue here is given that we restrict to
same-domain. You're already using the site, so it's just whether they can
tell that you use them as a protocol handler. I don't see a problem with
exposing
On Sat, Jan 23, 2010 at 2:30 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 12 Jan 2010, Michael Davidson wrote:
The table in section 7.9.3 says that the DataTransfer object should be
empty for dragenter and dragover events.
Clearly this is not the case - the example in 7.9.1 shows
I don't have comments on the particulars, but I would love to see an easier
way to go from Canvas to XHR. We'd use it in Gmail for resizing/editing
photos before attaching or placing inline in an email.
Michael
(Grabbing from the end...)
On Sat, Aug 29, 2009 at 2:40 PM, Ian Hickson i...@hixie.ch wrote:
implementation experience before specifying it. But I really don't think
it is the direction we should be taking the platform in. Granted,
programmers today don't want to use threads -- but, well,
On Tue, Jul 28, 2009 at 10:58 PM, Maciej Stachowiakm...@apple.com wrote:
Here's some security risks I've thought about, for persistent workers and
persistent background pages:
great list of risks
Thanks for the list, Maciej. However, Firefox extensions today have
all of the same problems. Do
On Wed, Jul 29, 2009 at 5:38 PM, Maciej Stachowiakm...@apple.com 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
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
On Wed, Jul 29, 2009 at 11:38 AM, Tab Atkins Jr.jackalm...@gmail.com wrote:
On Wed, Jul 29, 2009 at 1:34 PM, Michael Davidsonm...@google.com 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
On Wed, Jul 29, 2009 at 1:53 PM, Jeremy Orlowjor...@chromium.org 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
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
On Tue, Jul 28, 2009 at 4:19 PM, Michael Nordmanmicha...@google.com 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
On Tue, Jul 28, 2009 at 9:34 PM, Peter Kastingpkast...@google.com 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
On Tue, Jul 28, 2009 at 9:44 PM, Peter Kastingpkast...@google.com wrote:
On Tue, Jul 28, 2009 at 9:39 PM, Michael Davidson m...@google.com 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
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
20 matches
Mail list logo
