Is this accomplished by embedding a TabContents in a custom drawn (using
Views) toast?
-Darin
On Mon, Oct 19, 2009 at 2:17 PM, Drew Wilson atwil...@chromium.org wrote:
To be clear - our priority is to support HTML notifications on all
platforms *before* investigating support for native
Today I noticed a bunch of recently added CRASH test expectations for layout
tests. I know that we sometimes have to roll in a crasher or two, but
aren't we supposed to be filing p0-p1, dev channel release blockers at least
until we can prove the crash is not exploitable in the browser and
Not precisely embedding a TabContents; I'm drawing a custom toast using
views and putting a RenderViewHost+RenderWidgetHostView in it.
-John
On Tue, Oct 20, 2009 at 12:27 AM, Darin Fisher da...@chromium.org wrote:
Is this accomplished by embedding a TabContents in a custom drawn (using
Views)
OK, that sounds reasonable to me.
-Darin
On Tue, Oct 20, 2009 at 9:51 AM, John Gregg john...@google.com wrote:
Not precisely embedding a TabContents; I'm drawing a custom toast using
views and putting a RenderViewHost+RenderWidgetHostView in it.
-John
On Tue, Oct 20, 2009 at 12:27 AM,
Hi, please read the inlined proposed design for AutoFill++. Any feedback
and comments are appreciated.
Thanks,
James Hawkins
*AutoFill++*
*Status:* *Draft* (as of 2009-10-16)
*James Hawkins** jhawk...@chromium.org
Modified: Fri Oct 16 2009
*
Objective The purpose of this document is to
Mac browsers (Safari and Camino, at least) allow the user to auto-fill
from their me card in the OS X Address Book application, containing
name, address, and phone number. This would be a nice feature to
provide to users who have grown accustomed to the functionality.
Is there any mechanism to
On Tue, Oct 20, 2009 at 10:19 AM, David Levin le...@google.com wrote:
That sounds like a reasonable policy.
Hmm...I thought this was the policy. I guess not? :-)
There is the current idea of figuring out something about the crash before
filing a bug, which clashes with this idea.
What
(Since I've been contacted by a bunch people independently about this
problem already, here's one mail to hopefully point others who have
the same problem.)
Though we auto-detect your system architecture when we build, for
reasons opaque to me this doesn't work with nacl. I imagine someone
is
If it isn't written here
http://dev.chromium.org/developers/how-tos/webkit-merge-1, then (imo) it
isn't policy for gardener. :) Given that not everyone is in the same place,
if it isn't written in the standard place, how will folks know?
Even then, if you add something new, it would be nice to
For the mac case, we can probably query this service to populate the
autofill database before the first form is filled out. The major question I
have is, what happens when the user edits our copy of the personal
information (or the other after we've copied it)? Should we make these
copies
On Fri, Oct 16, 2009 at 1:28 AM, Michael Moss mm...@chromium.org wrote:
http://codereview.chromium.org/271113 may require a clobber for Linux
builds.
I should belatedly observe that the Linux make build, at least, is
supposed to detect command line changes and so should not need a
clobber. If
Sorry, the text isn't very clear about that. For lack of a better name
(yet), it's a new database that contains the autofill profiles.
On Tue, Oct 20, 2009 at 10:56 AM, Scott Violet s...@chromium.org wrote:
What is the 'profile database' ? The webdb?
-Scott
What is the 'profile database' ? The webdb?
-Scott
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
I know I sent this out a few weeks ago but I'm still hearing that it's a
problem so:
When you change the behavior of the UI on one platform, please file a
separate bug for each platform that doesn't implement this behavior change.
Please make the following modifications to the new bug:
- add the
+laforge
I'll let Anthony explain.
-Ben
On Tue, Oct 20, 2009 at 11:21 AM, Aaron Boodman a...@chromium.org wrote:
On Tue, Oct 20, 2009 at 11:16 AM, Ben Goodger (Google) b...@chromium.org
wrote:
- mark the new bug as blocking the original bug for the work, even if the
original bug is now or
Yaar and I discussed making changes to that effect last week, he's
working on that.
:DG
On Tue, Oct 20, 2009 at 10:33 AM, David Levin le...@chromium.org wrote:
If it isn't written
here http://dev.chromium.org/developers/how-tos/webkit-merge-1, then (imo)
it isn't policy for gardener. :)
What do you mean by that? Updating the doc?
Btw, the original reason why I asked was that I wanted to confirm we all
agreed with this policy. I guess it sounds like everyone does and the only
question is making sure everyone starts following it?
J
On Tue, Oct 20, 2009 at 11:28 AM, Dimitri
On Tue, Oct 20, 2009 at 1:25 PM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Oct 20, 2009 at 10:19 AM, David Levin le...@google.com wrote:
That sounds like a reasonable policy.
Hmm...I thought this was the policy. I guess not? :-)
There is the current idea of figuring out something
Nico beat me to it, but that's precisely correct, you just need to add the
child bug ids to the blocked by line in the parent bug.
Kind Regards,
Anthony Laforge
Technical Program Manager
Mountain View, CA
On Tue, Oct 20, 2009 at 11:30 AM, Nico Weber tha...@chromium.org wrote:
In the blockee,
But is it correct chromium practice to actually close the blockee
while it is being blocked?
To cut to the chase, I'm against having a master bug that represents
a UI change on all platforms. I've found it works better for me to
have one bug for each platform that are all independent.
I guess I
I'm against having completely independent bugs for the same feature.
That makes it hard to figure out if a change has been done on all
platforms etc. Having a closed parent bug for the 3 platform bugs is a
bit weird, but makes it easy to navigate the bug for all platforms and
is easy to create
Do we really want another database file and associated thread?
Shouldn't we put this in the web db?
-Scott
On Tue, Oct 20, 2009 at 10:58 AM, James Hawkins jhawk...@chromium.org wrote:
Sorry, the text isn't very clear about that. For lack of a better name
(yet), it's a new database that
I've been looking at this since you brought it up, and I agree that these
values should go into the web db.
On Tue, Oct 20, 2009 at 12:09 PM, Scott Violet s...@chromium.org wrote:
Do we really want another database file and associated thread?
Shouldn't we put this in the web db?
-Scott
On
Cool, thanks.
-Scott
On Tue, Oct 20, 2009 at 12:11 PM, James Hawkins jhawk...@chromium.org wrote:
I've been looking at this since you brought it up, and I agree that these
values should go into the web db.
On Tue, Oct 20, 2009 at 12:09 PM, Scott Violet s...@chromium.org wrote:
Do we
Awesome.
Thanks!
-Scott
On Tue, Oct 20, 2009 at 12:19 PM, Michael Moss mm...@chromium.org wrote:
I'm working on it.
On Tue, Oct 20, 2009 at 12:15 PM, Scott Violet s...@chromium.org wrote:
I want to say this bug has existed for around a week now. Is anyone
working on making it so that
One security concern:
Autofill should not give users information to the page until the user makes
some gesture to accept the autofill choices.
For the existing autofill, this is done by having the user choose from the
drop down menu.
The page can read the value of an INPUT field once it is set,
The theory is that you would start typing in one of the fields, the
traditional autofill UI (dropdown) would appear and selecting an item would
be equivalent to granting the form to be filled out.
-Ben
On Tue, Oct 20, 2009 at 12:43 PM, Darin Fisher da...@chromium.org wrote:
One security
The current design keys off autofill after the user enters a value in the
name field. A drop down menu is shown allowing the user to select which
profile to autofill. If the user does not select a profile, the form will
not be autofilled (using AutoFill++). I'll try to clarify this in the doc.
There's a checkbox in the external protocol dialog with the text
Remember my choice for all links of this type. (On windows and
linux, this is not actually implemented, but there are bugs out to fix
that) The options are then Cancel and Launch Application. The
conflict here is that in general
(If you are a Google employee who works full-time on Chromium, you can skip
this message.)
Already a number of you triage bugs, contribute patches, answer user
questions, or contribute to Chromium in other ways. We really appreciate
this! We'd love to see even more people contribute. We've
The latter in fact is how it's implemented on the Mac, though without the
renaming of the checkbox that would make it clear what's going on. I'd
support either version, and would alter my code to make it happen.
Avi
On Tue, Oct 20, 2009 at 4:01 PM, Evan Stade est...@chromium.org wrote:
I'm more in favor of renaming cancel.
[ ] Remember my choice for links of this type
[ Launch application ] [ Do not launch application ]
(or even 'Do nothing')
On Tue, Oct 20, 2009 at 1:01 PM, Evan Stade est...@chromium.org wrote:
There's a checkbox in the external protocol dialog with the
Evan Stade wrote:
There's a checkbox in the external protocol dialog with the text
Remember my choice for all links of this type. (On windows and
linux, this is not actually implemented, but there are bugs out to fix
that) The options are then Cancel and Launch Application. The
conflict here
The mocks also show a preview of all the fields when hovering over or
arrowing to one of the drop-down options.
Is there a way to do that without showing the values to the page?
-Nick
On Tue, Oct 20, 2009 at 12:46 PM, James Hawkins jhawk...@chromium.orgwrote:
The current design keys off
Hi All,
The Chromium WebKit API does not currently provide a wrapper for the
WebCore::Document object associated with a WebCore::Frame. CEF (
http://code.google.com/p/chromiumembedded), which also uses the WebKit API,
would like access to this object at the C++ level. Is there interest in the
It seems like we need to draw the line somewhere. Otherwise, we'll
end up exposing the whole DOM via the WebKit API. Where do you think
the optimum cut-off is?
Adam
On Tue, Oct 20, 2009 at 1:55 PM, Marshall Greenblatt
magreenbl...@gmail.com wrote:
Hi All,
The Chromium WebKit API does not
On Tue, Oct 20, 2009 at 5:33 PM, Adam Barth aba...@chromium.org wrote:
It seems like we need to draw the line somewhere. Otherwise, we'll
end up exposing the whole DOM via the WebKit API. Where do you think
the optimum cut-off is?
I think treating the DOM as an XML-ish object tree would be
http://codereview.chromium.org/306020
should generate a valgrind that gets past that problem.
On 20 Okt., 15:10, DanKegel daniel.r.ke...@gmail.com wrote:
Hi Joel,
I'm just starting to plow through the problems. I think
base_unittests
is about ok now, but net_unittests explodes wherever it
yeah, thanks for follow-up, i was able to sync and get it working but
as fyi - i did stumble on the way using gclient
since i was syncing to this svn end point :
http://src.chromium.org/svn/releases/3.0.195.27/src/
which has different DEPS file
Darin knows for sure, but I'm not aware of any intentions on Google's part
to engineer such an elaborate API. As long as it didn't add a
major maintenance burden (i.e. exposed things similar to one of the other
WebKit APIs) I'd imagine patches would be welcome though.
I believe only Darin can
Open web leads, was there any further discussion of this?
-Nick
On Sun, Oct 4, 2009 at 8:33 PM, Alex faab...@mozilla.com wrote:
That seems like a good plan. Has anyone ever tried formalizing it and
floating it around to other vendors?
I figured I should jump into the thread since I can
Seems like everyone agrees that Cancel should become Don't launch
On Tue, Oct 20, 2009 at 1:07 PM, Mark Mentovai m...@chromium.org wrote:
Evan Stade wrote:
There's a checkbox in the external protocol dialog with the text
Remember my choice for all links of this type. (On windows and
I didn't see any, but we had discussed a couple of possible ways to
get there at an earlier meeting.
The first was to perhaps use AppCache manifests to declare this sort
of metadata. You might have some sort of header in the manifest that
describes the page as persistently bless-able (much like
fyi: http://codereview.chromium.org/306017/show
-- Evan Stade
On Tue, Oct 20, 2009 at 5:41 PM, Brian Rakowski br...@chromium.org wrote:
Seems like everyone agrees that Cancel should become Don't launch
On Tue, Oct 20, 2009 at 1:07 PM, Mark Mentovai m...@chromium.org wrote:
Evan Stade
On Tue, Oct 20, 2009 at 6:35 PM, Alex Russell slightly...@google.com wrote:
The first was to perhaps use AppCache manifests to declare this sort
of metadata. You might have some sort of header in the manifest that
describes the page as persistently bless-able (much like Ben's
description),
45 matches
Mail list logo
