date:20091020

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 ideally
not before the crash is fixed??
Btw:
$ grep CRASH test_expectations.txt | egrep -v '^//' | wc -l
  56

And many of them are fairly new.

J

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [chromium-extensions] Re: Desktop Notifications

2009-10-20 Thread John Gregg

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) toast?-Darin


 On Mon, Oct 19, 2009 at 2:17 PM, Drew Wilson atwil...@chromium.orgwrote:

 To be clear - our priority is to support HTML notifications on all
 platforms *before* investigating support for native notification platforms
 (like Growl/libnotify).
 -atw


 On Mon, Oct 19, 2009 at 11:25 AM, Ian Fette i...@chromium.org wrote:

 We're trying to come up with a way to display html notifications on these
 platforms, once we get the windows one checked in. (Likely code that we will
 have to write.)

 2009/10/19 Evan Martin e...@chromium.org


 On Mon, Oct 19, 2009 at 11:16 AM, John Gregg john...@google.com
 wrote:
  The implementation of notifications is nearly complete for Windows
 chromium
  with the final pieces being reviewed right now.  Hopefully it will be
  available on the dev channel very soon behind a command-line switch
 for
  developers to start using.
  If you have questions about the specifics of the API, let me know, I'm
 happy
  to answer them and/or provide more documentation.

 I had alluded to this before, but I don't still see a good answer:
 what is the plan on Mac/Linux when the API is called with HTML?







 



--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [chromium-extensions] Re: Desktop Notifications

2009-10-20 Thread Darin Fisher

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, Darin Fisher da...@chromium.org wrote:

 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.orgwrote:

 To be clear - our priority is to support HTML notifications on all
 platforms *before* investigating support for native notification platforms
 (like Growl/libnotify).

 -atw


 On Mon, Oct 19, 2009 at 11:25 AM, Ian Fette i...@chromium.org wrote:

 We're trying to come up with a way to display html notifications on
 these platforms, once we get the windows one checked in. (Likely code that
 we will have to write.)

 2009/10/19 Evan Martin e...@chromium.org


 On Mon, Oct 19, 2009 at 11:16 AM, John Gregg john...@google.com
 wrote:
  The implementation of notifications is nearly complete for Windows
 chromium
  with the final pieces being reviewed right now.  Hopefully it will be
  available on the dev channel very soon behind a command-line switch
 for
  developers to start using.
  If you have questions about the specifics of the API, let me know,
 I'm happy
  to answer them and/or provide more documentation.

 I had alluded to this before, but I don't still see a good answer:
 what is the plan on Mac/Linux when the API is called with HTML?







 




--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] RFC: AutoFill++ Design Document

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 describe a significant
improvement in the current form autofill feature of Google Chrome.  The
current implementation is less of a form autofill and more of a form
history.  This approach has some limitations:


   - Values are saved per-site, so a Name value saved on penguin.com will
   not be suggested for the Name field on turtle.com.
   - The form must be filled out field-by-field.


I am proposing a new approach to form filling based on the client/server
statistic-based model implemented by Google Toolbar.  This feature provides
the following benefits:


   - Forms are completely auto-filled.
   - Values are saved in user profiles, so the Name field can be auto-filled
   for a form on a site one has never visited.

Background The main problem with the current autofill feature is that
the user must move from field to field to fill out a form, even when each
field can be auto-filled.  The history is site-specific, so the user must
enter form data for each site before autofill can be useful.
 Overview

To use the AutoFill++ feature in Google Chrome, the user must enter personal
information (name, address, email, etc.) into a form on any site and submit
this form.  An infobar will ask the user if he wants to enable autofill, and
if so, AutoFill++ will parse the form data and query the autofill server for
the field types.  If the server knows the field types for the form on this
particular site, AutoFill++ will match the data with the fields; otherwise,
a heuristic based on the names of the fields and how they are layed out on
the form is used to make this match.  The map of (field, data) will then be
saved in the user form data database.  When the user starts entering
information into any other form, a list of saved profiles will be presented
to the user in a selection drop-down.  After picking a profile, AutoFill++
will autofill all fields that it knows about and has information in the
database for.


The user will be able to enter additional profile information at any time
through the AutoFill++ dialog.  This dialog will be shown after the user
first enters form information, and will also be available through the
options dialog.


Note that no personal information will be sent to the autofill server, just
the field types determined by the heuristics.
Detailed Design The first step in implementing AutoFill++ is to rename the
current AutofillForm data structures to better match their behavior:
FormFieldHistory.

Just like Toolbar AutoFill++, the client will implement some strategies to
reduce the bandwitdth on the autofill server.  These include:


   - Ignore common search forms by ignoring forms that contain only one
   textfield with an id of q.
   - Ignore forms using the GET method to submit for data.
   - Ignore forms that have the word search in the target url for that
   form.
   - Using a flag in the query response from the server to tell the client
   whether or not it should upload the data if a user submits this form.



*Data Structure*
*Description*
*AutoFillForm*
The container that holds the (field, value) pairs, parsed from HTML.
*RenderViewHostDelegate::AutoFill*
An interface implemented by a class that wants to be notified of AutoFill
events from the RenderView
*AutoFillService*
The main AutoFill++ class.  Coordinates between the RenderView, the autofill
server, and the PersonalDatabaseManager Each TabContents has one, and each
instance is lazily created.
*AutoFillQueryXMLParser
*Builds and parses XML queries that are sent to and received from the
autofill server.
*AutoFillDownloadThread*
Spins off a new thread to download/upload data to the autofill server.
*AutoFillProfileDialog*
The UI for displaying the AutoFill++ profile dialog.
*PersonalDatabaseManager*
The gateway between the AutoFillService and the profile database.
*AutoFillProfile*
Contains all available personal information provided by the user.  This is
written to and read from the database.


The following is a description of the program flow for a typical autofill
session.


   1. User fills out and submits form.
  - RenderView::willSubmitForm - An *AutoFillForm* is created using *
  AutoFillForm::**Create*, which parses the form fields and values from
  a given WebForm.
 - ViewHostMsg_AutoFillFormSubmitted - Sends an IPC to the browser's
 render view host containing a map of the fields and values.
- *RenderViewHostDelegate::AutoFill-AutoFillFormSubmitted*
   - *AutoFillService::HandleSubmit*
  - *AutoFillQueryXMLParser* - Creates the XML
  representation of the form data, in the format
specified by the autofill
  communication

[chromium-dev] Re: RFC: AutoFill++ Design Document

2009-10-20 Thread Mike Pinkerton


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 allow us to recognize and provide this info
to the form instead of requiring the user to fill out the form
completely?

On Tue, Oct 20, 2009 at 1:13 PM, James Hawkins jhawk...@chromium.org wrote:

 Hi, please read the inlined proposed design for AutoFill++.  Any feedback and 
 comments are appreciated.

--
Mike Pinkerton
Mac Weenie
pinker...@google.com

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Crashing layout tests

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 text would you add to
 http://dev.chromium.org/developers/how-tos/webkit-merge-1 to tell how to
 deal with these? Here's one idea (add it in red?):

 If you must roll WebKit DEPS and pick up new crashers, you should enter an
 individual bug for each new crasher immediately and make it P0.


 Then what about assigning. Does it go to the unlucky webkit gardener who
 happened to have the duty that day? (If they have another day of gardening,
 then these bug linger.)


If the gardener has time, sure.  If not, maybe assign it to whomever makes
the most sense.  And, when there's no obvious candidate, they can draft
someone.  (In general, I think we should empower gardeners to draft people
when there are lots of high prioirity items stacking up and/or we get really
behind ToT.)

On Tue, Oct 20, 2009 at 9:23 AM, Jeremy Orlow jor...@chromium.org wrote:

 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
 ideally not before the crash is fixed??
 Btw:
 $ grep CRASH test_expectations.txt | egrep -v '^//' | wc -l
   56

 And many of them are fairly new.

 J

  



--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] [linux] how to work around nacl errors in 64-bit build

2009-10-20 Thread Evan Martin


(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 working on fixing it, but for now builds are broken.

If you're getting errors like
  /usr/bin/ld: cannot find -lnpGoogleNaClPluginChrome
and you're on a 64-bit system then you need to do one of
  1) export GYP_DEFINES='target_arch=x64'
  2) export GYP_DEFINES='disable_nacl=1'

And then re-run gyp.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Crashing layout tests

2009-10-20 Thread David Levin

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 tell folks b/c I'm
sure not everyone checks that every time they start gardening.

dave

On Tue, Oct 20, 2009 at 10:25 AM, 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 about the crash before
 filing a bug, which clashes with this idea.
 What text would you add to
 http://dev.chromium.org/developers/how-tos/webkit-merge-1 to tell how to
 deal with these? Here's one idea (add it in red?):

 If you must roll WebKit DEPS and pick up new crashers, you should enter an
 individual bug for each new crasher immediately and make it P0.


 Then what about assigning. Does it go to the unlucky webkit gardener who
 happened to have the duty that day? (If they have another day of gardening,
 then these bug linger.)


 If the gardener has time, sure.  If not, maybe assign it to whomever makes
 the most sense.  And, when there's no obvious candidate, they can draft
 someone.  (In general, I think we should empower gardeners to draft people
 when there are lots of high prioirity items stacking up and/or we get really
 behind ToT.)

 On Tue, Oct 20, 2009 at 9:23 AM, Jeremy Orlow jor...@chromium.org wrote:

 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
 ideally not before the crash is fixed??
 Btw:
 $ grep CRASH test_expectations.txt | egrep -v '^//' | wc -l
   56

 And many of them are fairly new.

 J





 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: RFC: AutoFill++ Design Document

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 read-only?  Having the profiles out of sync is not desirable.

On Tue, Oct 20, 2009 at 10:25 AM, Mike Pinkerton pinker...@chromium.orgwrote:

 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 allow us to recognize and provide this info
 to the form instead of requiring the user to fill out the form
 completely?

 On Tue, Oct 20, 2009 at 1:13 PM, James Hawkins jhawk...@chromium.org
 wrote:
 
  Hi, please read the inlined proposed design for AutoFill++.  Any feedback
 and comments are appreciated.

 --
 Mike Pinkerton
 Mac Weenie
 pinker...@google.com


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Change to default build architecture

2009-10-20 Thread Ben Laurie


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 anyone had to, I'd be interested to know what broke.

 The default build used to be 32-bit, but it will now be
 whatever your build host architecture is. If you are on a 64-bit
 machine, and haven't explicitly been setting 'target_arch' in gyp,
 your build will switch from 32-bit to 64-bit. If this breaks anything,
 clobbering or moving your existing build directory should fix it.

 If you want to continue building 32-bit on 64-bit hosts, you can force
 it by setting GYP_DEFINES=target_arch=ia32 in the environment.

 Michael

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: RFC: AutoFill++ Design Document

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


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: RFC: AutoFill++ Design Document


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
-~--~~~~--~~--~--~---

[chromium-dev] Reminder: File bugs for behavior changes on different platforms!

2009-10-20 Thread Ben Goodger (Google)

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 PlatformParity label
- mark the new bug as blocking the original bug for the work, even if the
original bug is now or soon will be closed.

Right now we are pushing comprehensive platform parity bugs into Mstone:5.

-Ben

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Reminder: File bugs for behavior changes on different platforms!

2009-10-20 Thread Ben Goodger (Google)

+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 soon will be closed.

 Can you explain more what you mean by this? What is the way to mark a
 bug as blocking? How can the blockee be closed if it is blocked by
 another bug that is open?

 - a


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Crashing layout tests

2009-10-20 Thread Dimitri Glazkov


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. :) 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 tell folks b/c I'm
 sure not everyone checks that every time they start gardening.
 dave
 On Tue, Oct 20, 2009 at 10:25 AM, 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 about the crash
 before filing a bug, which clashes with this idea.
 What text would you add
 to http://dev.chromium.org/developers/how-tos/webkit-merge-1 to tell how to
 deal with these? Here's one idea (add it in red?):

 If you must roll WebKit DEPS and pick up new crashers, you should enter
 an individual bug for each new crasher immediately and make it P0.

 Then what about assigning. Does it go to the unlucky webkit gardener who
 happened to have the duty that day? (If they have another day of gardening,
 then these bug linger.)

 If the gardener has time, sure.  If not, maybe assign it to whomever makes
 the most sense.  And, when there's no obvious candidate, they can draft
 someone.  (In general, I think we should empower gardeners to draft people
 when there are lots of high prioirity items stacking up and/or we get really
 behind ToT.)

 On Tue, Oct 20, 2009 at 9:23 AM, Jeremy Orlow jor...@chromium.org
 wrote:

 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
 ideally not before the crash is fixed??
 Btw:
 $ grep CRASH test_expectations.txt | egrep -v '^//' | wc -l
       56
 And many of them are fairly new.
 J







 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Crashing layout tests

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 Glazkov dglaz...@chromium.orgwrote:

 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. :) 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 tell folks b/c
 I'm
  sure not everyone checks that every time they start gardening.
  dave
  On Tue, Oct 20, 2009 at 10:25 AM, 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 about the crash
  before filing a bug, which clashes with this idea.
  What text would you add
  to http://dev.chromium.org/developers/how-tos/webkit-merge-1 to tell
 how to
  deal with these? Here's one idea (add it in red?):
 
  If you must roll WebKit DEPS and pick up new crashers, you should enter
  an individual bug for each new crasher immediately and make it P0.
 
  Then what about assigning. Does it go to the unlucky webkit gardener
 who
  happened to have the duty that day? (If they have another day of
 gardening,
  then these bug linger.)
 
  If the gardener has time, sure.  If not, maybe assign it to whomever
 makes
  the most sense.  And, when there's no obvious candidate, they can draft
  someone.  (In general, I think we should empower gardeners to draft
 people
  when there are lots of high prioirity items stacking up and/or we get
 really
  behind ToT.)
 
  On Tue, Oct 20, 2009 at 9:23 AM, Jeremy Orlow jor...@chromium.org
  wrote:
 
  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
  ideally not before the crash is fixed??
  Btw:
  $ grep CRASH test_expectations.txt | egrep -v '^//' | wc -l
56
  And many of them are fairly new.
  J
 
 
 
 
 
 
 
   
 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Crashing layout tests

2009-10-20 Thread Stephen White

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 about the crash before
filing a bug, which clashes with this idea.
What text would you add to
http://dev.chromium.org/developers/how-tos/webkit-merge-1 to tell how to
deal with these? Here's one idea (add it in red?):

If you must roll WebKit DEPS and pick up new crashers, you should enter an
individual bug for each new crasher immediately and make it P0.

Then what about assigning. Does it go to the unlucky webkit gardener who
happened to have the duty that day? (If they have another day of gardening,
then these bug linger.)

If the gardener has time, sure. If not, maybe assign it to whomever makes
the most sense. And, when there's no obvious candidate, they can draft
someone. (In general, I think we should empower gardeners to draft people
when there are lots of high prioirity items stacking up and/or we get really
behind ToT.)

BTW, determining who makes the most sense was the goal of this
spreadsheet:
http://spreadsheets.google.com/a/chromium.org/ccc?key=0AmBv0BNymMh5dHlHZnJDSjR1X0ZzNnRYOFZTVWtvb0Ehl=en.
So test breakage can be assigned to someone more familiar with that area of
the code (since svn blame doesn't really work for layout tests).

Of course, the spreadsheet is only 30% assigned as yet, so whether this will
work is TBD (maybe we need an adopt-a-layout-test program). If we decide
this is workable, we should put a link to it in the gardening docs.

Stephen

On Tue, Oct 20, 2009 at 9:23 AM, Jeremy Orlow jor...@chromium.org wrote:

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
ideally not before the crash is fixed??
Btw:
$ grep CRASH test_expectations.txt | egrep -v '^//' | wc -l
56

And many of them are fairly new.

--
All truth passes through three stages. First, it is ridiculed. Second, it is
violently opposed. Third, it is accepted as being self-evident. --
Schopenhauer

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Reminder: File bugs for behavior changes on different platforms!

2009-10-20 Thread Anthony LaForge

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, enter the blockers in the Blocked by line at the bottom.

 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 soon will be closed.
 
  Can you explain more what you mean by this? What is the way to mark a
  bug as blocking? How can the blockee be closed if it is blocked by
  another bug that is open?
 
  - a
 
  
 

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Reminder: File bugs for behavior changes on different platforms!

2009-10-20 Thread Aaron Boodman


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 just hate having bugs linger for a long time with tons of
changes against them.

- a

On Tue, Oct 20, 2009 at 11:49 AM, Anthony LaForge lafo...@google.com wrote:
 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, enter the blockers in the Blocked by line at the bottom.

 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 soon will be closed.
 
  Can you explain more what you mean by this? What is the way to mark a
  bug as blocking? How can the blockee be closed if it is blocked by
  another bug that is open?
 
  - a
 
  
 

 



--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Reminder: File bugs for behavior changes on different platforms!

2009-10-20 Thread Nico Weber


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 too (having e.g. one bug per platform that each says
See issue XXX and YYY for windows and mac part of this change is
hard to create and error-prone).

On Tue, Oct 20, 2009 at 11:56 AM, Aaron Boodman a...@chromium.org wrote:
 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 just hate having bugs linger for a long time with tons of
 changes against them.

 - a

 On Tue, Oct 20, 2009 at 11:49 AM, Anthony LaForge lafo...@google.com wrote:
 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, enter the blockers in the Blocked by line at the bottom.

 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 soon will be closed.
 
  Can you explain more what you mean by this? What is the way to mark a
  bug as blocking? How can the blockee be closed if it is blocked by
  another bug that is open?
 
  - a
 
  
 

 




--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: RFC: AutoFill++ Design Document


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 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



--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: RFC: AutoFill++ Design Document

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 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 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
 
 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: RFC: AutoFill++ Design Document


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 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 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
 
 

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [linux] how to work around nacl errors in 64-bit build


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 we don't need to explicitly set
 GYP_DEFINES for the build to work again?

  -Scott

 On Tue, Oct 20, 2009 at 10:29 AM, Evan Martin e...@chromium.org wrote:

 (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 working on fixing it, but for now builds are broken.

 If you're getting errors like
  /usr/bin/ld: cannot find -lnpGoogleNaClPluginChrome
 and you're on a 64-bit system then you need to do one of
  1) export GYP_DEFINES='target_arch=x64'
  2) export GYP_DEFINES='disable_nacl=1'

 And then re-run gyp.

 


 



--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: RFC: AutoFill++ Design Document

2009-10-20 Thread Darin Fisher

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, so you have to
be careful.  I wonder if a solution already exists to support Safari's
autofill.

-Darin


On Tue, Oct 20, 2009 at 10:13 AM, James Hawkins jhawk...@chromium.orgwrote:

 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 describe a significant
 improvement in the current form autofill feature of Google Chrome.  The
 current implementation is less of a form autofill and more of a form
 history.  This approach has some limitations:


- Values are saved per-site, so a Name value saved on penguin.com will
not be suggested for the Name field on turtle.com.
- The form must be filled out field-by-field.


 I am proposing a new approach to form filling based on the client/server
 statistic-based model implemented by Google Toolbar.  This feature provides
 the following benefits:


- Forms are completely auto-filled.
- Values are saved in user profiles, so the Name field can be
auto-filled for a form on a site one has never visited.

 Background The main problem with the current autofill feature is that
 the user must move from field to field to fill out a form, even when each
 field can be auto-filled.  The history is site-specific, so the user must
 enter form data for each site before autofill can be useful.
  Overview

 To use the AutoFill++ feature in Google Chrome, the user must enter
 personal information (name, address, email, etc.) into a form on any site
 and submit this form.  An infobar will ask the user if he wants to enable
 autofill, and if so, AutoFill++ will parse the form data and query the
 autofill server for the field types.  If the server knows the field types
 for the form on this particular site, AutoFill++ will match the data with
 the fields; otherwise, a heuristic based on the names of the fields and how
 they are layed out on the form is used to make this match.  The map of
 (field, data) will then be saved in the user form data database.  When the
 user starts entering information into any other form, a list of saved
 profiles will be presented to the user in a selection drop-down.  After
 picking a profile, AutoFill++ will autofill all fields that it knows about
 and has information in the database for.


 The user will be able to enter additional profile information at any time
 through the AutoFill++ dialog.  This dialog will be shown after the user
 first enters form information, and will also be available through the
 options dialog.


 Note that no personal information will be sent to the autofill server, just
 the field types determined by the heuristics.
 Detailed Design The first step in implementing AutoFill++ is to rename the
 current AutofillForm data structures to better match their behavior:
 FormFieldHistory.

 Just like Toolbar AutoFill++, the client will implement some strategies to
 reduce the bandwitdth on the autofill server.  These include:


- Ignore common search forms by ignoring forms that contain only one
textfield with an id of q.
- Ignore forms using the GET method to submit for data.
- Ignore forms that have the word search in the target url for that
form.
- Using a flag in the query response from the server to tell the client
whether or not it should upload the data if a user submits this form.



 *Data Structure*
 *Description*
 *AutoFillForm*
 The container that holds the (field, value) pairs, parsed from HTML.
 *RenderViewHostDelegate::AutoFill*
 An interface implemented by a class that wants to be notified of AutoFill
 events from the RenderView
 *AutoFillService*
 The main AutoFill++ class.  Coordinates between the RenderView, the
 autofill server, and the PersonalDatabaseManager Each TabContents has one,
 and each instance is lazily created.
 *AutoFillQueryXMLParser
 *Builds and parses XML queries that are sent to and received from the
 autofill server.
 *AutoFillDownloadThread*
 Spins off a new thread to download/upload data to the autofill server.
 *AutoFillProfileDialog*
 The UI for displaying the AutoFill++ profile dialog.
 *PersonalDatabaseManager*
 The gateway between the AutoFillService and the profile database.
 *AutoFillProfile*
 Contains all available personal information provided by the user.  This is
 written to and read from the database.


 The following is a description of the program flow for a typical autofill
 session.


1. User fills out and submits form.
   - RenderView::willSubmitForm - An *AutoFillForm* is

[chromium-dev] Re: RFC: AutoFill++ Design Document

2009-10-20 Thread Ben Goodger (Google)

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 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, so you have
 to be careful.  I wonder if a solution already exists to support Safari's
 autofill.

 -Darin


 On Tue, Oct 20, 2009 at 10:13 AM, James Hawkins jhawk...@chromium.orgwrote:

 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 describe a significant
 improvement in the current form autofill feature of Google Chrome.  The
 current implementation is less of a form autofill and more of a form
 history.  This approach has some limitations:


- Values are saved per-site, so a Name value saved on penguin.com will
not be suggested for the Name field on turtle.com.
- The form must be filled out field-by-field.


 I am proposing a new approach to form filling based on the client/server
 statistic-based model implemented by Google Toolbar.  This feature provides
 the following benefits:


- Forms are completely auto-filled.
- Values are saved in user profiles, so the Name field can be
auto-filled for a form on a site one has never visited.

 Background The main problem with the current autofill feature is that
 the user must move from field to field to fill out a form, even when each
 field can be auto-filled.  The history is site-specific, so the user must
 enter form data for each site before autofill can be useful.
  Overview

 To use the AutoFill++ feature in Google Chrome, the user must enter
 personal information (name, address, email, etc.) into a form on any site
 and submit this form.  An infobar will ask the user if he wants to enable
 autofill, and if so, AutoFill++ will parse the form data and query the
 autofill server for the field types.  If the server knows the field types
 for the form on this particular site, AutoFill++ will match the data with
 the fields; otherwise, a heuristic based on the names of the fields and how
 they are layed out on the form is used to make this match.  The map of
 (field, data) will then be saved in the user form data database.  When the
 user starts entering information into any other form, a list of saved
 profiles will be presented to the user in a selection drop-down.  After
 picking a profile, AutoFill++ will autofill all fields that it knows about
 and has information in the database for.


 The user will be able to enter additional profile information at any time
 through the AutoFill++ dialog.  This dialog will be shown after the user
 first enters form information, and will also be available through the
 options dialog.


 Note that no personal information will be sent to the autofill server,
 just the field types determined by the heuristics.
 Detailed Design The first step in implementing AutoFill++ is to rename
 the current AutofillForm data structures to better match their behavior:
 FormFieldHistory.

 Just like Toolbar AutoFill++, the client will implement some strategies to
 reduce the bandwitdth on the autofill server.  These include:


- Ignore common search forms by ignoring forms that contain only one
textfield with an id of q.
- Ignore forms using the GET method to submit for data.
- Ignore forms that have the word search in the target url for that
form.
- Using a flag in the query response from the server to tell the
client whether or not it should upload the data if a user submits this 
 form.



 *Data Structure*
 *Description*
 *AutoFillForm*
 The container that holds the (field, value) pairs, parsed from HTML.
 *RenderViewHostDelegate::AutoFill*
 An interface implemented by a class that wants to be notified of AutoFill
 events from the RenderView
 *AutoFillService*
 The main AutoFill++ class.  Coordinates between the RenderView, the
 autofill server, and the PersonalDatabaseManager Each TabContents has one,
 and each instance is lazily created.
 *AutoFillQueryXMLParser
 *Builds and parses XML queries that are sent to and received from the
 autofill server.
 *AutoFillDownloadThread*
 Spins off a new thread to download/upload data to the autofill server.
 *AutoFillProfileDialog*
 The UI for displaying the AutoFill++ profile dialog.
 *PersonalDatabaseManager*
 The gateway between the AutoFillService and the profile database.
 *AutoFillProfile*
 Contains all

[chromium-dev] Re: RFC: AutoFill++ Design Document

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.
Thanks,
James

On Tue, Oct 20, 2009 at 12:43 PM, Darin Fisher da...@chromium.org wrote:

 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, so you have
 to be careful.  I wonder if a solution already exists to support Safari's
 autofill.

 -Darin


 On Tue, Oct 20, 2009 at 10:13 AM, James Hawkins jhawk...@chromium.orgwrote:

 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 describe a significant
 improvement in the current form autofill feature of Google Chrome.  The
 current implementation is less of a form autofill and more of a form
 history.  This approach has some limitations:


- Values are saved per-site, so a Name value saved on penguin.com will
not be suggested for the Name field on turtle.com.
- The form must be filled out field-by-field.


 I am proposing a new approach to form filling based on the client/server
 statistic-based model implemented by Google Toolbar.  This feature provides
 the following benefits:


- Forms are completely auto-filled.
- Values are saved in user profiles, so the Name field can be
auto-filled for a form on a site one has never visited.

 Background The main problem with the current autofill feature is that
 the user must move from field to field to fill out a form, even when each
 field can be auto-filled.  The history is site-specific, so the user must
 enter form data for each site before autofill can be useful.
  Overview

 To use the AutoFill++ feature in Google Chrome, the user must enter
 personal information (name, address, email, etc.) into a form on any site
 and submit this form.  An infobar will ask the user if he wants to enable
 autofill, and if so, AutoFill++ will parse the form data and query the
 autofill server for the field types.  If the server knows the field types
 for the form on this particular site, AutoFill++ will match the data with
 the fields; otherwise, a heuristic based on the names of the fields and how
 they are layed out on the form is used to make this match.  The map of
 (field, data) will then be saved in the user form data database.  When the
 user starts entering information into any other form, a list of saved
 profiles will be presented to the user in a selection drop-down.  After
 picking a profile, AutoFill++ will autofill all fields that it knows about
 and has information in the database for.


 The user will be able to enter additional profile information at any time
 through the AutoFill++ dialog.  This dialog will be shown after the user
 first enters form information, and will also be available through the
 options dialog.


 Note that no personal information will be sent to the autofill server,
 just the field types determined by the heuristics.
 Detailed Design The first step in implementing AutoFill++ is to rename
 the current AutofillForm data structures to better match their behavior:
 FormFieldHistory.

 Just like Toolbar AutoFill++, the client will implement some strategies to
 reduce the bandwitdth on the autofill server.  These include:


- Ignore common search forms by ignoring forms that contain only one
textfield with an id of q.
- Ignore forms using the GET method to submit for data.
- Ignore forms that have the word search in the target url for that
form.
- Using a flag in the query response from the server to tell the
client whether or not it should upload the data if a user submits this 
 form.



 *Data Structure*
 *Description*
 *AutoFillForm*
 The container that holds the (field, value) pairs, parsed from HTML.
 *RenderViewHostDelegate::AutoFill*
 An interface implemented by a class that wants to be notified of AutoFill
 events from the RenderView
 *AutoFillService*
 The main AutoFill++ class.  Coordinates between the RenderView, the
 autofill server, and the PersonalDatabaseManager Each TabContents has one,
 and each instance is lazily created.
 *AutoFillQueryXMLParser
 *Builds and parses XML queries that are sent to and received from the
 autofill server.
 *AutoFillDownloadThread*
 Spins off a new thread to download/upload data to the autofill server.
 *AutoFillProfileDialog*
 The UI for displaying the AutoFill++ profile dialog.

[chromium-dev] External protocol dialog checkbox

2009-10-20 Thread Evan Stade


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 Cancel is supposed to not do
anything, hence it can't honor the Remember my choice for all links
of this type option. So that checkbox should either be renamed
Always allow this protocol, and not allow the user to always block
that protocol, or the cancel button should be renamed to don't launch
app or equivalent.

-- Evan Stade

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Survey: Please read and respond!

2009-10-20 Thread Peter Kasting

(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 created a short
survey (linked below) to try and determine how we can best help you, the
Chromium community, to improve Chromium.  Please visit the link below and
respond.  Thanks!

https://spreadsheets.google.com/viewform?formkey=dEp1QzJIbGg1MmVwN2szY2pZZ3ZadkE6MA
Notes: Please only fill out the survey once.  Your answers are anonymous.
 If anything is unclear or you have comments that aren't captured by the
form, let me know.

PK

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: External protocol dialog checkbox

2009-10-20 Thread Avi Drissman

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:


 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 Cancel is supposed to not do
 anything, hence it can't honor the Remember my choice for all links
 of this type option. So that checkbox should either be renamed
 Always allow this protocol, and not allow the user to always block
 that protocol, or the cancel button should be renamed to don't launch
 app or equivalent.

 -- Evan Stade

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: External protocol dialog checkbox

2009-10-20 Thread Glen Murphy


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 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 Cancel is supposed to not do
 anything, hence it can't honor the Remember my choice for all links
 of this type option. So that checkbox should either be renamed
 Always allow this protocol, and not allow the user to always block
 that protocol, or the cancel button should be renamed to don't launch
 app or equivalent.

 -- Evan Stade


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: External protocol dialog checkbox

2009-10-20 Thread Mark Mentovai


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 is that in general Cancel is supposed to not do
 anything, hence it can't honor the Remember my choice for all links
 of this type option. So that checkbox should either be renamed
 Always allow this protocol, and not allow the user to always block
 that protocol, or the cancel button should be renamed to don't launch
 app or equivalent.

I agree with this 100%.  When Avi implemented this dialog on the Mac,
I was really mean about it and I wouldn't let him make the remember
checkbox actually remember anything as long as the button's text
remained Cancel.

The button label should change to Don't Launch or something along
those lines.  Leaving it at Cancel is ambiguous.

Mark

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: RFC: AutoFill++ Design Document

2009-10-20 Thread Nick Baum

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 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.
 Thanks,
 James

 On Tue, Oct 20, 2009 at 12:43 PM, Darin Fisher da...@chromium.org wrote:

 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, so you have
 to be careful.  I wonder if a solution already exists to support Safari's
 autofill.

 -Darin


 On Tue, Oct 20, 2009 at 10:13 AM, James Hawkins jhawk...@chromium.orgwrote:

 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 describe a significant
 improvement in the current form autofill feature of Google Chrome.  The
 current implementation is less of a form autofill and more of a form
 history.  This approach has some limitations:


- Values are saved per-site, so a Name value saved on penguin.comwill 
 not be suggested for the Name field on
turtle.com.
- The form must be filled out field-by-field.


 I am proposing a new approach to form filling based on the client/server
 statistic-based model implemented by Google Toolbar.  This feature provides
 the following benefits:


- Forms are completely auto-filled.
- Values are saved in user profiles, so the Name field can be
auto-filled for a form on a site one has never visited.

 Background The main problem with the current autofill feature is
 that the user must move from field to field to fill out a form, even when
 each field can be auto-filled.  The history is site-specific, so the user
 must enter form data for each site before autofill can be useful.
  Overview

 To use the AutoFill++ feature in Google Chrome, the user must enter
 personal information (name, address, email, etc.) into a form on any site
 and submit this form.  An infobar will ask the user if he wants to enable
 autofill, and if so, AutoFill++ will parse the form data and query the
 autofill server for the field types.  If the server knows the field types
 for the form on this particular site, AutoFill++ will match the data with
 the fields; otherwise, a heuristic based on the names of the fields and how
 they are layed out on the form is used to make this match.  The map of
 (field, data) will then be saved in the user form data database.  When the
 user starts entering information into any other form, a list of saved
 profiles will be presented to the user in a selection drop-down.  After
 picking a profile, AutoFill++ will autofill all fields that it knows about
 and has information in the database for.


 The user will be able to enter additional profile information at any time
 through the AutoFill++ dialog.  This dialog will be shown after the user
 first enters form information, and will also be available through the
 options dialog.


 Note that no personal information will be sent to the autofill server,
 just the field types determined by the heuristics.
 Detailed Design The first step in implementing AutoFill++ is to rename
 the current AutofillForm data structures to better match their behavior:
 FormFieldHistory.

 Just like Toolbar AutoFill++, the client will implement some strategies
 to reduce the bandwitdth on the autofill server.  These include:


- Ignore common search forms by ignoring forms that contain only one
textfield with an id of q.
- Ignore forms using the GET method to submit for data.
- Ignore forms that have the word search in the target url for that
form.
- Using a flag in the query response from the server to tell the
client whether or not it should upload the data if a user submits this 
 form.



 *Data Structure*
 *Description*
 *AutoFillForm*
 The container that holds the (field, value) pairs, parsed from HTML.
 *RenderViewHostDelegate::AutoFill*
 An interface implemented by a class that wants to be notified of AutoFill
 events from the RenderView
 *AutoFillService*
 The main AutoFill++ class.  Coordinates between the RenderView, the
 autofill server, and the PersonalDatabaseManager Each TabContents has one,
 and each instance is lazily created.
 *AutoFillQueryXMLParser
 *Builds and parses

[chromium-dev] WebKit API wrapper for Document

2009-10-20 Thread Marshall Greenblatt

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
broader Chromium community for having a Document wrapper as part of the
WebKit API?

Thanks,
Marshall

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: WebKit API wrapper for Document

2009-10-20 Thread Adam Barth


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 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
 broader Chromium community for having a Document wrapper as part of the
 WebKit API?

 Thanks,
 Marshall

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: WebKit API wrapper for Document

2009-10-20 Thread Marshall Greenblatt

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 the most
reasonable approach.  This means:

1. The ability to walk the DOM hierarchy by following parent/child
relationships.
2. The ability to get/set DOM attributes.
3. The ability to create/delete DOM objects at any level in the hierarchy.
4. The ability to set event listeners on DOM objects (perhaps using a
v8::Function as the listener).

Inputs would need to be sanity-checked by the API based on the underlying
object context, but I don't think we need to provide separate API
classes/methods for each possibility.


 Adam


 On Tue, Oct 20, 2009 at 1:55 PM, Marshall Greenblatt
 magreenbl...@gmail.com wrote:
  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
  broader Chromium community for having a Document wrapper as part of the
  WebKit API?
 
  Thanks,
  Marshall
 
   
 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Valgrind + 64bit binaries

2009-10-20 Thread DanKegel


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 tries to use
 v8,
 with the same error you had.

 I guess v8 isn't happy with valgrind on 64 bits yet; I'll report this
 upstream.
 - Dan

 On 16 Sep., 21:20, Joel Stanley j...@jms.id.au wrote:



  Hello,

  While attempting to run x64 unit_tests under valgrind I am hitting an error:

  vex: priv/guest_amd64_toIR.c:14600 (disInstr_AMD64_WRK): Assertion `sz
  == 2 || sz == 4' failed.
  vex storage: T total 4600074960 bytes allocated
  vex storage: P total 816 bytes allocated

  valgrind: the 'impossible' happened:
     LibVEX called failure_exit().
  ==25306==    at 0x3802ADC4: report_and_quit (m_libcassert.c:145)
  ==25306==    by 0x3802AE29: panic (m_libcassert.c:227)
  ==25306==    by 0x3802AEA2: vgPlain_core_panic_at (m_libcassert.c:232)
  ==25306==    by 0x3802AEC1: vgPlain_core_panic (m_libcassert.c:237)
  ==25306==    by 0x380433F2: failure_exit (m_translate.c:674)
  ==25306==    by 0x380B2AE8: vex_assert_fail (main_util.c:220)
  ==25306==    by 0x38117CCE: disInstr_AMD64_WRK (guest_amd64_toIR.c:14600)
  ==25306==    by 0x3811BB42: disInstr_AMD64 (guest_amd64_toIR.c:16116)
  ==25306==    by 0x380C0BA1: bb_to_IR (guest_generic_bb_to_IR.c:229)
  ==25306==    by 0x380B135C: LibVEX_Translate (main_main.c:420)
  ==25306==    by 0x380410B5: vgPlain_translate (m_translate.c:1517)
  ==25306==    by 0x38062F68: vgPlain_scheduler (scheduler.c:844)
  ==25306==    by 0x3808AF74: run_a_thread_NORETURN (syswrap-linux.c:91)

  Has anyone had success valgrinding 64bit binaries?

  Cheers,

  Joel
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: SVN Stable Tree Path for 3.0.195.25

2009-10-20 Thread Amit Kishnani


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

http://src.chromium.org/svn/releases/3.0.195.27/src/DEPS

it was choking gclient to sync due to svn://chrome-svn - could not
resolve this.

src/third_party/WebKit/LayoutTests:
svn://chrome-svn/chrome/branches/WebKit/195/layoutte...@22623,

so i changed it point to http://src.chromium.org/svn/releases/3.0.195.27
instead (NOTE without /src in the end this time) - it worked better
and was able to get all the right dependent versions.

the second thing i stumbled on was gclient runhooks --force - it was
complaining about branding as undefined variable in \src\third_party
\ffmpeg\ffmpeg.gyp in the below line

From

 'ffmpeg_branding%': '(branding)',


To

  'ffmpeg_branding%': 'Chromium',

then , it was able to generate all the VC .sln/vcproj file.

this is an quick update/experience when syncing with svn repository
for 3.0.195.27.

Thanks again for quick turnaround.
Amit.


On Oct 16, 4:48 am, PhistucK phist...@gmail.com wrote:
 Your question was probably answered already (or you have given up), but the
 releases folder was updated, it seems and the sources you were looking for
 are there now.
 The specific one you were looking for 
 -http://src.chromium.org/viewvc/chrome/releases/3.0.195.25/
 The latest one -http://src.chromium.org/viewvc/chrome/releases/3.0.195.27/

 ☆PhistucK

 On Tue, Oct 6, 2009 at 21:34, Amit Kishnani akish...@adobe.com wrote:

  Hey Guys,

  what is difference between these releases 3.0.190.2  3.0.195.25

  i can get to SVN source tree to read access for code tree
  3.0.190.2 using the following svn repository url

 http://src.chromium.org/svn/releases/3.0.190.2/src/

  i want to make sure i am getting the latest stable source tree , is
  there a better svn url to get latest 3.0.195.25. please advise.

  Thanks,
  Amit.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: WebKit API wrapper for Document