[chromium-dev] Question about render Message between Browser and Renderer
Hi, I appreciate if someone can help me understand what is the Message send from Browser to Renderer in the case of html form submission. I think the message ViewMsg_Navigate_Params is for HTTP get only, not for HTTP post, since I dont' see any attribute in that struct to store form submission data. And I read this http://dev.chromium.org/developers/design-documents/form-auto, it said WebFrameLoaderClient::dispatchWillSubmitForm() passes the AutofillForm as the argument of its delegate's function OnAutofillFormSubmitted(). So I tried setting breakpoints in WebFrameLoaderClient::dispatchWillSubmitForm(), but it never breaks when I do a 'google search' in chromium. I only see void WebFrameLoaderClient::dispatchWillSendRequest() get breaks. Can you please tell me why is that? Thank you for any help. --~--~-~--~~~---~--~~ 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: browser/sync is moving in
- est electronix...@gmail.com wrote: not working on 4.0.202.0 (23600)? chrome.exe --enable-sync Did you enable the option in the wrench menu? See http://googlechromereleases.blogspot.com/2009/08/dev-channel-update_17.html cheers, mike --~--~-~--~~~---~--~~ 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: browser/sync is moving in
Hi est, If you happen to be using a Chromium (blue logo) build, then this is the expected behavior. The feature is currently available as a preview via the Google Chrome dev channel, but not in Chromium branded builds. Sync won't be usable in Chromium until we can build the feature entirely from source. To recap from Tim's email that started this thread: We've been working in a proprietary environment until now because of the dependency of having to build the complementary Google production server environment for syncing. As such, the code uses a small number of internal libraries that we need to open-source or replace, as well as libraries that would be redundant to what Chromium already includes. . . . We do *not* plan on ever checking in the windows-only syncapi dll to the main chromium repository. So until the dll is no longer needed, the public repository won't have all the bits to actually build Chromium with sync enabled. The glue code is out in the open already, and several of us are working on getting the sync engine library to build as a fully open source part of Chromium. - nick On Mon, Aug 17, 2009 at 10:12 PM, est electronix...@gmail.com wrote: not working on 4.0.202.0 (23600)? chrome.exe --enable-sync On Aug 1, 5:07 am, Tim Steele t...@chromium.org wrote: Hi! A bunch of us have been working on a feature to sync user data in Chromium with a Google account. (Surprise! :)) The great news is that we'll be starting to work directly in the Chromium project this week, and let me tell you, are we excited to do that! This email discusses how we're planning to get started, in detail (maybe too much detail... sorry). We have built a library that implements the client side of our sync protocol http://sites.google.com/a/chromium.org/dev/developers/design-document..., as well as the Google server-side infrastructure to serve Google Chrome users and synchronize data to their Google Account. Of course, all the code going into Chromium is open source, and the messages between the client and server use the open protobuf http://code.google.com/p/protobuf/ format and library. Check out the sync developer page http://sites.google.com/a/chromium.org/dev/developers/design-document... if you're interested in low-level goals and technical details. We will be landing this code in a few steps rather than one giant changelist for a number of reasons. First, this makes reviewing a *lot* easier; it isn't the most straightforward code by nature, so the more fine grained scrutiny the code gets, the better. Second, we've been working in a proprietary environment until now because of the dependency of having to build the complementary Google production server environment for syncing. As such, the code uses a small number of internal libraries that we need to open-source or replace, as well as libraries that would be redundant to what Chromium already includes. Removing these, and open sourcing the entire sync engine, is our highest priority and we expect this to take about three weeks. So how will we commit the code in pieces and not totally hose the build in the process? First, a little more background. You may have come across the CHROME_PERSONALIZATION #define when digging through Chromium source code. Right now, this is used in conjunction with a relatively small number of private c++ source files to conditionally build Chromium with sync enabled. These files are in fact a glue layer between Chromium and what is called the syncapi, which is the bulk of the client library I was talking about above. On windows, syncapi is built into a DLL, and when CHROME_PERSONALIZATION is defined this DLL gets placed alongside chrome.dll for use at runtime. Syncapi builds and runs on Linux, but not Mac (yet). With the initial checkin, we will leave the CHROME_PERSONALIZATION #define as-is, so the sync code will not be built by default. We'll be working hard over the coming weeks to make sure the code passes all existing test suites that are part of the regular buildbot cycle, and on removing the #define. After that, our hope is that we will be free of the DLL altogether and have all the code checked in to the repository, fully functional or not, in a few weeks. We do *not* plan on ever checking in the windows-only syncapi dll to the main chromium repository. So until the dll is no longer needed, the public repository won't have all the bits to actually build Chromium with sync enabled. That said, we want to keep the sync build running smoothly, so we will use a combination of command-line flag (to enable sync) and delay-loading syncapi.dll only when it is needed. This will allow the glue code to compile as part of the normal Chromium build without introducing a dependency on this dll, yet still make it possible to run with the dll present. On that note, we're
[chromium-dev] Re: Question about render Message between Browser and Renderer
Do you mean http://dev.chromium.org/developers/design-documents/form-autofill?If so, that is a whole other thing (form autofill, as opposed to what you are looking for - form submitting). (Sorry for not being helpful, but just a heads up so you will not read irrelevant stuff (to your case), unless you want to :P) ☆PhistucK On Tue, Aug 18, 2009 at 09:03, hap 497 hap...@gmail.com wrote: Hi, I appreciate if someone can help me understand what is the Message send from Browser to Renderer in the case of html form submission. I think the message ViewMsg_Navigate_Params is for HTTP get only, not for HTTP post, since I dont' see any attribute in that struct to store form submission data. And I read this http://dev.chromium.org/developers/design-documents/form-auto, it said WebFrameLoaderClient::dispatchWillSubmitForm() passes the AutofillForm as the argument of its delegate's function OnAutofillFormSubmitted(). So I tried setting breakpoints in WebFrameLoaderClient::dispatchWillSubmitForm(), but it never breaks when I do a 'google search' in chromium. I only see void WebFrameLoaderClient::dispatchWillSendRequest() get breaks. Can you please tell me why is that? Thank you for any help. --~--~-~--~~~---~--~~ 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: browser/sync is moving in
Thanks for the explaination, Nick Carter. I understand now, Chrome is a Google product while Chromium is a open- source project. Any thing else differs between Google Chrome and Chromium? I found dictionaries missing from Chromium. On Aug 18, 2:13 pm, Nick Carter n...@chromium.org wrote: Hi est, If you happen to be using a Chromium (blue logo) build, then this is the expected behavior. The feature is currently available as a preview via the Google Chrome dev channel, but not in Chromium branded builds. Sync won't be usable in Chromium until we can build the feature entirely from source. To recap from Tim's email that started this thread: We've been working in a proprietary environment until now because of the dependency of having to build the complementary Google production server environment for syncing. As such, the code uses a small number of internal libraries that we need to open-source or replace, as well as libraries that would be redundant to what Chromium already includes. . . . We do *not* plan on ever checking in the windows-only syncapi dll to the main chromium repository. So until the dll is no longer needed, the public repository won't have all the bits to actually build Chromium with sync enabled. The glue code is out in the open already, and several of us are working on getting the sync engine library to build as a fully open source part of Chromium. - nick On Mon, Aug 17, 2009 at 10:12 PM, est electronix...@gmail.com wrote: not working on 4.0.202.0 (23600)? chrome.exe --enable-sync On Aug 1, 5:07 am, Tim Steele t...@chromium.org wrote: Hi! A bunch of us have been working on a feature to sync user data in Chromium with a Google account. (Surprise! :)) The great news is that we'll be starting to work directly in the Chromium project this week, and let me tell you, are we excited to do that! This email discusses how we're planning to get started, in detail (maybe too much detail... sorry). We have built a library that implements the client side of our sync protocol http://sites.google.com/a/chromium.org/dev/developers/design-document..., as well as the Google server-side infrastructure to serve Google Chrome users and synchronize data to their Google Account. Of course, all the code going into Chromium is open source, and the messages between the client and server use the open protobuf http://code.google.com/p/protobuf/ format and library. Check out the sync developer page http://sites.google.com/a/chromium.org/dev/developers/design-document... if you're interested in low-level goals and technical details. We will be landing this code in a few steps rather than one giant changelist for a number of reasons. First, this makes reviewing a *lot* easier; it isn't the most straightforward code by nature, so the more fine grained scrutiny the code gets, the better. Second, we've been working in a proprietary environment until now because of the dependency of having to build the complementary Google production server environment for syncing. As such, the code uses a small number of internal libraries that we need to open-source or replace, as well as libraries that would be redundant to what Chromium already includes. Removing these, and open sourcing the entire sync engine, is our highest priority and we expect this to take about three weeks. So how will we commit the code in pieces and not totally hose the build in the process? First, a little more background. You may have come across the CHROME_PERSONALIZATION #define when digging through Chromium source code. Right now, this is used in conjunction with a relatively small number of private c++ source files to conditionally build Chromium with sync enabled. These files are in fact a glue layer between Chromium and what is called the syncapi, which is the bulk of the client library I was talking about above. On windows, syncapi is built into a DLL, and when CHROME_PERSONALIZATION is defined this DLL gets placed alongside chrome.dll for use at runtime. Syncapi builds and runs on Linux, but not Mac (yet). With the initial checkin, we will leave the CHROME_PERSONALIZATION #define as-is, so the sync code will not be built by default. We'll be working hard over the coming weeks to make sure the code passes all existing test suites that are part of the regular buildbot cycle, and on removing the #define. After that, our hope is that we will be free of the DLL altogether and have all the code checked in to the repository, fully functional or not, in a few weeks. We do *not* plan on ever checking in the windows-only syncapi dll to the main chromium repository. So until the dll is no longer needed, the public repository won't have all the bits to actually build Chromium with sync enabled. That said, we want
[chromium-dev] Re: browser/sync is moving in
Now, will there soon be a way to add a reference item in Google Docs at the Google Chrome section there?I mean, when you go to Google Docs, after you sync, there is a Google Chrome folder under My Folders. When you go into it, there are folders and the items has some sort of a reference icon. Will it be made possible to add references not through the browser? (If so, any time frame?) Thank you, this is a cool feature. ☆PhistucK On Tue, Aug 18, 2009 at 09:13, Nick Carter n...@chromium.org wrote: Hi est, If you happen to be using a Chromium (blue logo) build, then this is the expected behavior. The feature is currently available as a preview via the Google Chrome dev channel, but not in Chromium branded builds. Sync won't be usable in Chromium until we can build the feature entirely from source. To recap from Tim's email that started this thread: We've been working in a proprietary environment until now because of the dependency of having to build the complementary Google production server environment for syncing. As such, the code uses a small number of internal libraries that we need to open-source or replace, as well as libraries that would be redundant to what Chromium already includes. . . . We do *not* plan on ever checking in the windows-only syncapi dll to the main chromium repository. So until the dll is no longer needed, the public repository won't have all the bits to actually build Chromium with sync enabled. The glue code is out in the open already, and several of us are working on getting the sync engine library to build as a fully open source part of Chromium. - nick On Mon, Aug 17, 2009 at 10:12 PM, est electronix...@gmail.com wrote: not working on 4.0.202.0 (23600)? chrome.exe --enable-sync On Aug 1, 5:07 am, Tim Steele t...@chromium.org wrote: Hi! A bunch of us have been working on a feature to sync user data in Chromium with a Google account. (Surprise! :)) The great news is that we'll be starting to work directly in the Chromium project this week, and let me tell you, are we excited to do that! This email discusses how we're planning to get started, in detail (maybe too much detail... sorry). We have built a library that implements the client side of our sync protocol http://sites.google.com/a/chromium.org/dev/developers/design-document.. ., as well as the Google server-side infrastructure to serve Google Chrome users and synchronize data to their Google Account. Of course, all the code going into Chromium is open source, and the messages between the client and server use the open protobuf http://code.google.com/p/protobuf/ format and library. Check out the sync developer page http://sites.google.com/a/chromium.org/dev/developers/design-document... if you're interested in low-level goals and technical details. We will be landing this code in a few steps rather than one giant changelist for a number of reasons. First, this makes reviewing a *lot* easier; it isn't the most straightforward code by nature, so the more fine grained scrutiny the code gets, the better. Second, we've been working in a proprietary environment until now because of the dependency of having to build the complementary Google production server environment for syncing. As such, the code uses a small number of internal libraries that we need to open-source or replace, as well as libraries that would be redundant to what Chromium already includes. Removing these, and open sourcing the entire sync engine, is our highest priority and we expect this to take about three weeks. So how will we commit the code in pieces and not totally hose the build in the process? First, a little more background. You may have come across the CHROME_PERSONALIZATION #define when digging through Chromium source code. Right now, this is used in conjunction with a relatively small number of private c++ source files to conditionally build Chromium with sync enabled. These files are in fact a glue layer between Chromium and what is called the syncapi, which is the bulk of the client library I was talking about above. On windows, syncapi is built into a DLL, and when CHROME_PERSONALIZATION is defined this DLL gets placed alongside chrome.dll for use at runtime. Syncapi builds and runs on Linux, but not Mac (yet). With the initial checkin, we will leave the CHROME_PERSONALIZATION #define as-is, so the sync code will not be built by default. We'll be working hard over the coming weeks to make sure the code passes all existing test suites that are part of the regular buildbot cycle, and on removing the #define. After that, our hope is that we will be free of the DLL altogether and have all the code checked in to the repository, fully functional or not, in a few weeks. We do *not* plan on ever checking in the windows-only syncapi dll to the main chromium repository.
[chromium-dev] Re: browser/sync is moving in
Official explanation - http://blog.chromium.org/2008/10/google-chrome-chromium-and-google.html ☆PhistucK On Tue, Aug 18, 2009 at 09:19, est electronix...@gmail.com wrote: Thanks for the explaination, Nick Carter. I understand now, Chrome is a Google product while Chromium is a open- source project. Any thing else differs between Google Chrome and Chromium? I found dictionaries missing from Chromium. On Aug 18, 2:13 pm, Nick Carter n...@chromium.org wrote: Hi est, If you happen to be using a Chromium (blue logo) build, then this is the expected behavior. The feature is currently available as a preview via the Google Chrome dev channel, but not in Chromium branded builds. Sync won't be usable in Chromium until we can build the feature entirely from source. To recap from Tim's email that started this thread: We've been working in a proprietary environment until now because of the dependency of having to build the complementary Google production server environment for syncing. As such, the code uses a small number of internal libraries that we need to open-source or replace, as well as libraries that would be redundant to what Chromium already includes. . . . We do *not* plan on ever checking in the windows-only syncapi dll to the main chromium repository. So until the dll is no longer needed, the public repository won't have all the bits to actually build Chromium with sync enabled. The glue code is out in the open already, and several of us are working on getting the sync engine library to build as a fully open source part of Chromium. - nick On Mon, Aug 17, 2009 at 10:12 PM, est electronix...@gmail.com wrote: not working on 4.0.202.0 (23600)? chrome.exe --enable-sync On Aug 1, 5:07 am, Tim Steele t...@chromium.org wrote: Hi! A bunch of us have been working on a feature to sync user data in Chromium with a Google account. (Surprise! :)) The great news is that we'll be starting to work directly in the Chromium project this week, and let me tell you, are we excited to do that! This email discusses how we're planning to get started, in detail (maybe too much detail... sorry). We have built a library that implements the client side of our sync protocol http://sites.google.com/a/chromium.org/dev/developers/design-document.. ., as well as the Google server-side infrastructure to serve Google Chrome users and synchronize data to their Google Account. Of course, all the code going into Chromium is open source, and the messages between the client and server use the open protobuf http://code.google.com/p/protobuf/ format and library. Check out the sync developer page http://sites.google.com/a/chromium.org/dev/developers/design-document.. . if you're interested in low-level goals and technical details. We will be landing this code in a few steps rather than one giant changelist for a number of reasons. First, this makes reviewing a *lot* easier; it isn't the most straightforward code by nature, so the more fine grained scrutiny the code gets, the better. Second, we've been working in a proprietary environment until now because of the dependency of having to build the complementary Google production server environment for syncing. As such, the code uses a small number of internal libraries that we need to open-source or replace, as well as libraries that would be redundant to what Chromium already includes. Removing these, and open sourcing the entire sync engine, is our highest priority and we expect this to take about three weeks. So how will we commit the code in pieces and not totally hose the build in the process? First, a little more background. You may have come across the CHROME_PERSONALIZATION #define when digging through Chromium source code. Right now, this is used in conjunction with a relatively small number of private c++ source files to conditionally build Chromium with sync enabled. These files are in fact a glue layer between Chromium and what is called the syncapi, which is the bulk of the client library I was talking about above. On windows, syncapi is built into a DLL, and when CHROME_PERSONALIZATION is defined this DLL gets placed alongside chrome.dll for use at runtime. Syncapi builds and runs on Linux, but not Mac (yet). With the initial checkin, we will leave the CHROME_PERSONALIZATION #define as-is, so the sync code will not be built by default. We'll be working hard over the coming weeks to make sure the code passes all existing test suites that are part of the regular buildbot cycle, and on removing the #define. After that, our hope is that we will be free of the DLL altogether and have all the code checked in to the
[chromium-dev] Re: browser/sync is moving in
A blog posting, http://blog.chromium.org/2008/10/google-chrome-chromium-and-google.html , answers this question. - nick On Mon, Aug 17, 2009 at 11:19 PM, est electronix...@gmail.com wrote: Thanks for the explaination, Nick Carter. I understand now, Chrome is a Google product while Chromium is a open- source project. Any thing else differs between Google Chrome and Chromium? I found dictionaries missing from Chromium. On Aug 18, 2:13 pm, Nick Carter n...@chromium.org wrote: Hi est, If you happen to be using a Chromium (blue logo) build, then this is the expected behavior. The feature is currently available as a preview via the Google Chrome dev channel, but not in Chromium branded builds. Sync won't be usable in Chromium until we can build the feature entirely from source. To recap from Tim's email that started this thread: We've been working in a proprietary environment until now because of the dependency of having to build the complementary Google production server environment for syncing. As such, the code uses a small number of internal libraries that we need to open-source or replace, as well as libraries that would be redundant to what Chromium already includes. . . . We do *not* plan on ever checking in the windows-only syncapi dll to the main chromium repository. So until the dll is no longer needed, the public repository won't have all the bits to actually build Chromium with sync enabled. The glue code is out in the open already, and several of us are working on getting the sync engine library to build as a fully open source part of Chromium. - nick On Mon, Aug 17, 2009 at 10:12 PM, est electronix...@gmail.com wrote: not working on 4.0.202.0 (23600)? chrome.exe --enable-sync On Aug 1, 5:07 am, Tim Steele t...@chromium.org wrote: Hi! A bunch of us have been working on a feature to sync user data in Chromium with a Google account. (Surprise! :)) The great news is that we'll be starting to work directly in the Chromium project this week, and let me tell you, are we excited to do that! This email discusses how we're planning to get started, in detail (maybe too much detail... sorry). We have built a library that implements the client side of our sync protocol http://sites.google.com/a/chromium.org/dev/developers/design-document.. ., as well as the Google server-side infrastructure to serve Google Chrome users and synchronize data to their Google Account. Of course, all the code going into Chromium is open source, and the messages between the client and server use the open protobuf http://code.google.com/p/protobuf/ format and library. Check out the sync developer page http://sites.google.com/a/chromium.org/dev/developers/design-document.. . if you're interested in low-level goals and technical details. We will be landing this code in a few steps rather than one giant changelist for a number of reasons. First, this makes reviewing a *lot* easier; it isn't the most straightforward code by nature, so the more fine grained scrutiny the code gets, the better. Second, we've been working in a proprietary environment until now because of the dependency of having to build the complementary Google production server environment for syncing. As such, the code uses a small number of internal libraries that we need to open-source or replace, as well as libraries that would be redundant to what Chromium already includes. Removing these, and open sourcing the entire sync engine, is our highest priority and we expect this to take about three weeks. So how will we commit the code in pieces and not totally hose the build in the process? First, a little more background. You may have come across the CHROME_PERSONALIZATION #define when digging through Chromium source code. Right now, this is used in conjunction with a relatively small number of private c++ source files to conditionally build Chromium with sync enabled. These files are in fact a glue layer between Chromium and what is called the syncapi, which is the bulk of the client library I was talking about above. On windows, syncapi is built into a DLL, and when CHROME_PERSONALIZATION is defined this DLL gets placed alongside chrome.dll for use at runtime. Syncapi builds and runs on Linux, but not Mac (yet). With the initial checkin, we will leave the CHROME_PERSONALIZATION #define as-is, so the sync code will not be built by default. We'll be working hard over the coming weeks to make sure the code passes all existing test suites that are part of the regular buildbot cycle, and on removing the #define. After that, our hope is that we will be free of the DLL altogether and have all the code
[chromium-dev] Re: browser/sync is moving in
Also, I just noticed I cannot delete the items manually from Google Docs, it says they come from a read only source. This is not optimal, I want to be able to manipulate the things I have in my own Google Docs account, from within Google Docs. Will that change soon? ☆PhistucK On Tue, Aug 18, 2009 at 09:13, Nick Carter n...@chromium.org wrote: Hi est, If you happen to be using a Chromium (blue logo) build, then this is the expected behavior. The feature is currently available as a preview via the Google Chrome dev channel, but not in Chromium branded builds. Sync won't be usable in Chromium until we can build the feature entirely from source. To recap from Tim's email that started this thread: We've been working in a proprietary environment until now because of the dependency of having to build the complementary Google production server environment for syncing. As such, the code uses a small number of internal libraries that we need to open-source or replace, as well as libraries that would be redundant to what Chromium already includes. . . . We do *not* plan on ever checking in the windows-only syncapi dll to the main chromium repository. So until the dll is no longer needed, the public repository won't have all the bits to actually build Chromium with sync enabled. The glue code is out in the open already, and several of us are working on getting the sync engine library to build as a fully open source part of Chromium. - nick On Mon, Aug 17, 2009 at 10:12 PM, est electronix...@gmail.com wrote: not working on 4.0.202.0 (23600)? chrome.exe --enable-sync On Aug 1, 5:07 am, Tim Steele t...@chromium.org wrote: Hi! A bunch of us have been working on a feature to sync user data in Chromium with a Google account. (Surprise! :)) The great news is that we'll be starting to work directly in the Chromium project this week, and let me tell you, are we excited to do that! This email discusses how we're planning to get started, in detail (maybe too much detail... sorry). We have built a library that implements the client side of our sync protocol http://sites.google.com/a/chromium.org/dev/developers/design-document.. ., as well as the Google server-side infrastructure to serve Google Chrome users and synchronize data to their Google Account. Of course, all the code going into Chromium is open source, and the messages between the client and server use the open protobuf http://code.google.com/p/protobuf/ format and library. Check out the sync developer page http://sites.google.com/a/chromium.org/dev/developers/design-document... if you're interested in low-level goals and technical details. We will be landing this code in a few steps rather than one giant changelist for a number of reasons. First, this makes reviewing a *lot* easier; it isn't the most straightforward code by nature, so the more fine grained scrutiny the code gets, the better. Second, we've been working in a proprietary environment until now because of the dependency of having to build the complementary Google production server environment for syncing. As such, the code uses a small number of internal libraries that we need to open-source or replace, as well as libraries that would be redundant to what Chromium already includes. Removing these, and open sourcing the entire sync engine, is our highest priority and we expect this to take about three weeks. So how will we commit the code in pieces and not totally hose the build in the process? First, a little more background. You may have come across the CHROME_PERSONALIZATION #define when digging through Chromium source code. Right now, this is used in conjunction with a relatively small number of private c++ source files to conditionally build Chromium with sync enabled. These files are in fact a glue layer between Chromium and what is called the syncapi, which is the bulk of the client library I was talking about above. On windows, syncapi is built into a DLL, and when CHROME_PERSONALIZATION is defined this DLL gets placed alongside chrome.dll for use at runtime. Syncapi builds and runs on Linux, but not Mac (yet). With the initial checkin, we will leave the CHROME_PERSONALIZATION #define as-is, so the sync code will not be built by default. We'll be working hard over the coming weeks to make sure the code passes all existing test suites that are part of the regular buildbot cycle, and on removing the #define. After that, our hope is that we will be free of the DLL altogether and have all the code checked in to the repository, fully functional or not, in a few weeks. We do *not* plan on ever checking in the windows-only syncapi dll to the main chromium repository. So until the dll is no longer needed, the public repository won't have all the bits to actually build Chromium with sync enabled. That said, we want
[chromium-dev] Re: browser/sync is moving in
On Mon, Aug 17, 2009 at 11:46 PM, PhistucKphist...@gmail.com wrote: Also, I just noticed I cannot delete the items manually from Google Docs, it says they come from a read only source. This is not optimal, I want to be able to manipulate the things I have in my own Google Docs account, from within Google Docs. Will that change soon? I suspect we're very early in the development of this feature. We haven't even shipped a stable version of Chrome 3 yet! Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] (Solution) Are you getting svn (or gclient sync) hangs on Windows Vista?
Then, run this command (from an Administrator command prompt): netsh interface tcp set global autotuninglevel=disabled Hopefully, it will be fixed for you as it seems to be for me. Reference: http://blogs.technet.com/asiasupp/archive/2006/12/14/windows-vista-tcp-auto-tuning.aspx Dave --~--~-~--~~~---~--~~ 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: browser/sync is moving in
Is there any indication of when this feature will be available for the Linux version of Chromium? Cheers Nick On Aug 18, 8:00 am, PhistucK phist...@gmail.com wrote: Yeah, that does not mean the plan may not be to keep it a read only folder.Which is why I am asking this right now. ☆PhistucK On Tue, Aug 18, 2009 at 09:59, Adam Barth aba...@chromium.org wrote: On Mon, Aug 17, 2009 at 11:46 PM, PhistucKphist...@gmail.com wrote: Also, I just noticed I cannot delete the items manually from Google Docs, it says they come from a read only source. This is not optimal, I want to be able to manipulate the things I have in my own Google Docs account, from within Google Docs. Will that change soon? I suspect we're very early in the development of this feature. We haven't even shipped a stable version of Chrome 3 yet! Adam --~--~-~--~~~---~--~~ 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: Stack traces on layout test crashes
ObjC 2.0 apis should provide pretty clean ways to get all the data for ObjC classes, see http://code.google.com/p/google-toolbox-for-mac/source/browse/trunk/Foundation/GTMStackTrace.m(we already use some of GTM in Chrome/Chromium). TVL On Tue, Aug 18, 2009 at 12:16 AM, Viet-Trung Luu viettrung...@gmail.comwrote: I don't know what I was thinking (the only explanation: a moment of severe masochism), but I completely rewrote my Mac-stacktracing patch. It now finds Objective-C symbols too (so, in my limited testing, yields basically the same results as gdb's backtrace). Same place as before: http://codereview.chromium.org/165224 I think I need a drink. - Trung Viet-Trung Luu wrote: Here's a slightly improved (well, much improved, in that it doesn't crash[*]) version, [...] --~--~-~--~~~---~--~~ 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: DTrace/OSX links
I pasted this onto http://sites.google.com/a/chromium.org/dev/developers/debugging-on-os-x so it's not forgotten. I don't know much about this stuff so I didn't clean it up too much. On Fri, Aug 14, 2009 at 3:32 PM, Jeremy Moskovichjer...@chromium.org wrote: I've collected some useful links on DTrace [esp. for OSX], some of you probably know this cold but for those who don't: jgm's awesome introductory article: http://www.mactech.com/articles/mactech/Vol.23/23.11/ExploringLeopardwithDTrace/index.html Defining static probes on OS X: http://www.macresearch.org/tuning-cocoa-applications-using-dtrace-custom-static-probes-and-instruments http://www.brendangregg.com/dtrace.html#Examples http://blogs.sun.com/bmc/resource/dtrace_tips.pdf DTrace examples on OS X: /usr/share/examples/DTTk DanK adds: And here's my little mac dtrace tip: To get truss on Mac OS X, use dtruss. That requires root, so I often sudo dtruss -p and attach to a running nonroot program. Best regards, Jeremy --~--~-~--~~~---~--~~ 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: Does Chromium use boost library
On Sun, Aug 16, 2009 at 10:17 AM, Albert J. Wong (王重傑)ajw...@chromium.org wrote: It seems that git rm didn't delete the directories themselves. :( Thanks for fixing Mark! git doesn't distinguish between nonexistent directories and existent-but-empty directories, so as I understand it it will never delete directories from svn. (The suggested solutions if you actually *want* an empty directory in a git repo are (1) don't do that or (2) create a meaningless dotfile in the directory.) PS: Personal OKR of responding to 100% of messages mentioning git is currently green. :P --~--~-~--~~~---~--~~ 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: url_request document
Though this isn't my area of expertise, if you didn't find something on dev.chromium.org, I believe there isn't such a doc. We've done a pretty good job of moving all prior internal docs to the public site and off the top of my head I can't think of any example of post-going-public documentation remaining private. A document from you would be most welcome. On Fri, Aug 14, 2009 at 1:49 PM, Marshall Greenblattmagreenbl...@gmail.com wrote: Hi All, I've been using url_request for a while now, and I find myself consistently forgetting the relationship between the various managers/handlers and order in which the asynchronous calls take place. Does anyone currently have a document/diagram for url_request that we can put up under Design Documents on the developer wiki? If not, I'll take a shot at writing one before I forget it all for the third or fourth time :-). Regards, 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: Git and Mercurial?
I recall at some point hg didn't integrate as well as git did with svn. At least http://mercurial.selenic.com/wiki/WorkingWithSubversion (first hit for [hg svn]) claims While pushing changes back to Subversion is not officially supported yet, interoperating with it is possible with third-party tools or existing extensions. Disclaimer: not an hg user, so I could have bad info. Ob-fanatic note: hg and git are more or less equivalent; depending on which side you're biased towards, hg as compared to git either has a simpler and easier-to-understand UI or it's missing a bunch of critical features. On Sun, Aug 16, 2009 at 7:03 AM, Ben Laurieb...@chromium.org wrote: I see some people like to use git to work on chromium. How about mercurial? Has anyone tried it? Is there some reason it doesn't work so well? --~--~-~--~~~---~--~~ 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: Can't edit others' codereviews?
On Sat, Aug 15, 2009 at 11:44 PM, Nico Webertha...@chromium.org wrote: `git cl patch` reuses existing issues, so when landing stuff for other people, I used to edit the issue on codereview to add Patch by someone+usuallytru...@example.org before landing. So for me editing other people's issues is useful. $ git cl dcommit --help | grep -- -c -c CONTRIBUTOR external contributor for patch (appended to description) My typical workflow is: grep trung AUTHORS select line with full name git cl dcommit -c middle click here I think it'd be neat to somehow use git's distinction of author vs committer such that when you patch in a cl (with git cl patch) it plumbs the rietveld-side author info into the local git commit info and from there into the svn commit, but I think the mapping of rietveld username to AUTHORS username isn't very clear. PS: Personal OKR of responding to 100% of messages mentioning git remains green. :D --~--~-~--~~~---~--~~ 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] switching from hammer to make as the default build tool
I would like to make this switch, but it is not yet reliable. I don't want build bots failing because of dependency bugs. (Heh, heaven forbid we sometimes need to click a hypothetical clobber checkbox on the buildbots to work around a build system issue! :P) I'd been using the makebuild label, though most bugs have just been reported to me directly (special thanks to benl and davemoore for tracking down some problems for me): http://code.google.com/p/chromium/issues/list?can=1q=makebuild Dean told me he has his build alias just always run make twice when he builds, which is pretty tragic to me, but he says it's still faster than scons. :\ On Mon, Aug 17, 2009 at 2:07 PM, Lei Zhangthes...@chromium.org wrote: Hi, On Linux, building with make is a lot faster than build with hammer. Ever since I switched to the make build on Linux, I've never looked back. I imagine many other Linux developers are also using make, and we have been using the make build without any major problems for a few months now. So I wonder, is it time to switch our build bots to make and update the Linux build instructions? - Lei --~--~-~--~~~---~--~~ 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: browser/sync is moving in
It will be after it's completely landed in the public repository, so only after the work Tim mentioned at the beginning of this thread is complete. On Tue, Aug 18, 2009 at 2:29 AM, codfatherswcodfat...@gmail.com wrote: Is there any indication of when this feature will be available for the Linux version of Chromium? Cheers Nick On Aug 18, 8:00 am, PhistucK phist...@gmail.com wrote: Yeah, that does not mean the plan may not be to keep it a read only folder.Which is why I am asking this right now. ☆PhistucK On Tue, Aug 18, 2009 at 09:59, Adam Barth aba...@chromium.org wrote: On Mon, Aug 17, 2009 at 11:46 PM, PhistucKphist...@gmail.com wrote: Also, I just noticed I cannot delete the items manually from Google Docs, it says they come from a read only source. This is not optimal, I want to be able to manipulate the things I have in my own Google Docs account, from within Google Docs. Will that change soon? I suspect we're very early in the development of this feature. We haven't even shipped a stable version of Chrome 3 yet! Adam --~--~-~--~~~---~--~~ 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: url_request document
On Tue, Aug 18, 2009 at 8:21 AM, Evan Martin e...@chromium.org wrote: Though this isn't my area of expertise, if you didn't find something on dev.chromium.org, I believe there isn't such a doc. We've done a pretty good job of moving all prior internal docs to the public site and off the top of my head I can't think of any example of post-going-public documentation remaining private. A document from you would be most welcome. Thanks Evan. I'll create the document under http://code.google.com/p/chromium/w/list and the powers that be can then do whatever they like with it :-). On Fri, Aug 14, 2009 at 1:49 PM, Marshall Greenblattmagreenbl...@gmail.com wrote: Hi All, I've been using url_request for a while now, and I find myself consistently forgetting the relationship between the various managers/handlers and order in which the asynchronous calls take place. Does anyone currently have a document/diagram for url_request that we can put up under Design Documents on the developer wiki? If not, I'll take a shot at writing one before I forget it all for the third or fourth time :-). Regards, 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: browser/sync is moving in
On Mon, Aug 17, 2009 at 11:19 PM, estelectronix...@gmail.com wrote: Thanks for the explaination, Nick Carter. I understand now, Chrome is a Google product while Chromium is a open- source project. Any thing else differs between Google Chrome and Chromium? I found dictionaries missing from Chromium. Dictionaries are in chrome/third_party/hunspell/dictionaries You need to copy the one(s) you want to your profile dictionaries directory for them to work. Brett --~--~-~--~~~---~--~~ 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: Can't edit others' codereviews?
On Tue, Aug 18, 2009 at 5:37 AM, Evan Martine...@chromium.org wrote: I think it'd be neat to somehow use git's distinction of author vs committer such that when you patch in a cl (with git cl patch) it plumbs the rietveld-side author info into the local git commit info and from there into the svn commit, but I think the mapping of rietveld username to AUTHORS username isn't very clear. In WebKit land, our tools do exactly that. There's a python script that provides the mappings: http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/modules/committers.py Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Plugin control flow and race conditions
At Mozilla we're currently working on implementing multi-process plugin hosts similar to the model used by Chromium. However, we're having trouble working through the many potential race conditions introduced by having multiple processes (and therefore multiple flows of control). I've read http://dev.chromium.org/developers/design-documents/plugin-architecture but that doesn't seem to address most of the issues we're facing. The most obvious problem is that both processes may send a synchronous IPC message at the same time. Assuming that these don't deadlock, the native stack for the two calls would end up interleaved. What happens when the renderer process and the plugin process send conflicting messages at roughly the same time? For example: the browser finishes a network request with NPP_DestroyStream and the plugin (responding to a UI event, perhaps) calls NPN_DestroyStream simultaneously? I can't imagine that a plugin would expect to receive aa NPP_DestroyStream message after it has already called NPN_DestroyStream, and this is likely to cause erratic plugin behavior. Are the IPC delegates/stubs responsible for checking the state of each call and avoiding improper nesting? Do you have any procedure/system for detecting with racy improper nesting? For example, racing pairs NPP_Write/NPN_DestroyStream and NPN_RequestRead/NPP_DestroyStream are equally unexpected. And all these example come only from the NPStream interface; I haven't even begun to examine potential message races in the core NPP APIs or the NPObject APIs. --BDS --~--~-~--~~~---~--~~ 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: browser/sync is moving in
If the aggregate of bookmarks can be considered to be a document, doesn't the wave protocol solve the sync/coordination problem? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Mac resources and bundles
Anyone adding more resources (xibs, etc.) to the Mac, please remember always fetch them from mac_util::MainAppBundle() (base/mac_util.h) and do *not* use any Cocoa apis that assume [NSBundle mainBundle]. As part of the l10n, packaging, and updating, where resources live and what bundle is running as the main bundle isn't always what you expect. TVL --~--~-~--~~~---~--~~ 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: Plugin control flow and race conditions
Explicitly adding jam to make him notice this. (I don't know the answer to your question. As far as I know we try to avoid implementing things with synchronous messages as much as possible.) 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: url_request document
On Fri, Aug 14, 2009 at 1:49 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: Hi All, I've been using url_request for a while now, Random drive-by note: Most consumers of URLRequest would be much happier using URLFetcher (which layers atop it to provide a much simpler interface, including abstracting away threading issues, multiple callbacks, race conditions, etc.). If you are doing something like Go make this network request and give me the results, you should look into this. 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: Plugin control flow and race conditions
On Mon, Aug 17, 2009 at 2:43 PM, bsmedbergbsmedb...@gmail.com wrote: The most obvious problem is that both processes may send a synchronous IPC message at the same time. Assuming that these don't deadlock, the native stack for the two calls would end up interleaved. While there may be a possibility for deadlock (I haven't looked--jam will know more), the native stack on the plugin process side should not get interleaved (at least using the Chromium IPC mechanism. In particular, the plugin process will not process incoming IPC requests while a synchronous IPC call is outstanding. So in the case you've described, if the plugin has called NPN_DestroyStream, it will not even see the NPP_DestroyStream until NPN_DestroyStream has completed. At that point, the plugin host process may be able to determine that the stream has already been destroyed, and not even forward the call to the plugin itself. In addition, a number of operations which are normally synchronous in in-process NPAPI are asynchronous in Chromium (painting, for example). This does add complexity, but it helps avoid deadlock and improve performance. --Amanda -- Portability is generally the result of advance planning rather than trench warfare involving #ifdef -- Henry Spencer (1992) --~--~-~--~~~---~--~~ 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: url_request document
On Fri, Aug 14, 2009 at 1:49 PM, Marshall Greenblattmagreenbl...@gmail.com wrote: Hi All, I've been using url_request for a while now, and I find myself consistently forgetting the relationship between the various managers/handlers and order in which the asynchronous calls take place. Does anyone currently have a document/diagram for url_request that we can put up under Design Documents on the developer wiki? Eric Roman has a diagram that shows the relationship between URLRequest and the classes below it. He may not have published it on our website, but it is in his YouTube video on the Chromium network stack. But I suspect you're more interested in the relationship between URLRequest and its consumers. The order in which the asynchronous calls take place is documented in url_request.h, in the block comment above the Delegate class. If you find that comment unclear or out of date, please create a changelist to update it with your findings. Wan-Teh --~--~-~--~~~---~--~~ 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: new round of flakiness, IsStringASCII this time
Cool! On Mon, Aug 17, 2009 at 1:39 PM, Huan Ren hu...@google.com wrote: UI test can not walk the stack as for now. There is a script to print stack traces of all crash dumps after the test is finished. This one from the latest chromium cycle: http://build.chromium.org/buildbot/waterfall/builders/Chromium%20XP/builds/6674/steps/Process%20Dumps/logs/stdio On Mon, Aug 17, 2009 at 10:38 AM, Darin Fisherda...@chromium.org wrote: It would be great if the UI test framework printed out a stack trace when a [D]CHECK fails. -Darin On Mon, Aug 17, 2009 at 9:35 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: I'm seeing a lot of these in the logs (most important message is bold): C:\b\slave\chromium-dbg-builder\build\src\chrome\browser\sessions\session_restore_uitest.cc(385): error: Value of: last_tab-Reload() Actual: false Expected: true C:\b\slave\chromium-dbg-builder\build\src\chrome\test\ui\ui_test.cc(485): error: Value of: automation()-GetBrowserWindowCount(window_count) Actual: false Expected: true C:\b\slave\chromium-dbg-builder\build\src\chrome\test\ui\ui_test.cc(148): error: Value of: assertions.size() Actual: 1 Expected: expected_errors_ Which is: 0 The following error(s) occurred in the application during this test: [FATAL:string_util.cc(515)] Check failed: IsStringASCII(utf16). C:\b\slave\chromium-dbg-builder\build\src\chrome\test\ui\ui_test.cc(162): error: Value of: actual_crashes Actual: 1 Expected: expected_crashes_ Which is: 0 Encountered an unexpected crash in the program during this test. Do you know how this can happen? (intermittently!) Do you have some idea how to debug it? --~--~-~--~~~---~--~~ 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] switching from hammer to make as the default build tool
+1 to what Tony (and Evan and others) have said. The stated goal *is* to convert the official builds to Make, but we need to get the Make generator (gyp backend) on par with the other generators. Gyp now has a test infrastructure that we're using to characterize the various generator behaviors, and find and fix the inconsistencies. This is important for converting the buildbots to Make because, naturally enough, the Make generator has grown up around one primary goal--faster developer builds--and the buildbots have some additional requirements. Anyone who has some cycles to contribute towards this should join gyp-developers (or contact me), or as Tony said, at least open up issues so everything that has to be fixed before converting can be tracked and prioritized. --SK On Mon, Aug 17, 2009 at 3:23 PM, Tony Chang t...@chromium.org wrote: That particular bug is fixed (http://code.google.com/p/gyp/source/detail?r=559) but there are other bugs still (e.g., changes that touch grd files require running make twice to generate the right pak files). It would be good to fix these before switching to the make build on the builders. Reduced test cases and bugs on http://code.google.com/p/gyp/issues/list is the way to move this along. On Mon, Aug 17, 2009 at 3:19 PM, Lei Zhangthes...@chromium.org wrote: On Mon, Aug 17, 2009 at 3:00 PM, Antoine Labourpi...@google.com wrote: On Mon, Aug 17, 2009 at 2:07 PM, Lei Zhangthes...@chromium.org wrote: Hi, On Linux, building with make is a lot faster than build with hammer. Ever since I switched to the make build on Linux, I've never looked back. I imagine many other Linux developers are also using make, and we have been using the make build without any major problems for a few months now. So I wonder, is it time to switch our build bots to make and update the Linux build instructions? - Lei I'm all for it since that would reduce the make build breaks, but I think the dependency bug where you have to delete all your .a should be fixed first if you don't want to spend time babysitting buildbot. Antoine Is there a bug files for that? --~--~-~--~~~---~--~~ 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: Question about render Message between Browser and Renderer
Thanks. I did debug on Renderer process. As a matter for fact, This breakpoint 'WebFrameLoaderClient::dispatchWillSendRequest() breaks, but this 'WebFrameLoaderClient::dispatchWillSubmitForm()' does not. I was doing a 'google search' (i.e. enter text in search box, and click 'Search' in google home page) On Tue, Aug 18, 2009 at 5:45 AM, Evan Martin e...@chromium.org wrote: Just a guess, but since that code runs in the renderer, it's likely you're debugging the wrong process. See Multi-process issues in http://dev.chromium.org/developers/how-tos/debugging . On Mon, Aug 17, 2009 at 11:03 PM, hap 497hap...@gmail.com wrote: Hi, I appreciate if someone can help me understand what is the Message send from Browser to Renderer in the case of html form submission. I think the message ViewMsg_Navigate_Params is for HTTP get only, not for HTTP post, since I dont' see any attribute in that struct to store form submission data. And I read this http://dev.chromium.org/developers/design-documents/form-auto, it said WebFrameLoaderClient::dispatchWillSubmitForm() passes the AutofillForm as the argument of its delegate's function OnAutofillFormSubmitted(). So I tried setting breakpoints in WebFrameLoaderClient::dispatchWillSubmitForm(), but it never breaks when I do a 'google search' in chromium. I only see void WebFrameLoaderClient::dispatchWillSendRequest() get breaks. Can you please tell me why is that? Thank you for any help. --~--~-~--~~~---~--~~ 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: url_request document
On Tue, Aug 18, 2009 at 1:00 PM, Peter Kasting pkast...@chromium.orgwrote: On Fri, Aug 14, 2009 at 1:49 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: Hi All, I've been using url_request for a while now, Random drive-by note: Most consumers of URLRequest would be much happier using URLFetcher (which layers atop it to provide a much simpler interface, including abstracting away threading issues, multiple callbacks, race conditions, etc.). If you are doing something like Go make this network request and give me the results, you should look into this. Thanks, I didn't know about URLFetcher :-). I can definitely find a few uses for it... 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: url_request document
On Tue, Aug 18, 2009 at 1:47 PM, Wan-Teh Chang w...@google.com wrote: On Fri, Aug 14, 2009 at 1:49 PM, Marshall Greenblattmagreenbl...@gmail.com wrote: Hi All, I've been using url_request for a while now, and I find myself consistently forgetting the relationship between the various managers/handlers and order in which the asynchronous calls take place. Does anyone currently have a document/diagram for url_request that we can put up under Design Documents on the developer wiki? Eric Roman has a diagram that shows the relationship between URLRequest and the classes below it. He may not have published it on our website, but it is in his YouTube video on the Chromium network stack. Thanks, I'll check it out. The video is here for anyone else who's interested: http://www.youtube.com/watch?v=ZhDb42M6ZLk But I suspect you're more interested in the relationship between URLRequest and its consumers. You're correct. In this particular case we're implementing URLRequestJob to handle custom schemes in combination with URLRequest::RegisterProtocolFactory(), and we need to properly understand all of the pesky thread/race/callback issues. The order in which the asynchronous calls take place is documented in url_request.h, in the block comment above the Delegate class. If you find that comment unclear or out of date, please create a changelist to update it with your findings. The level of detail in url_request.h is great, but I think a higher-level overview would also be good. For example, see the comment at the beginning of webkit/tools/test_shell/simple_resource_loader_bridge.cc. What I would like to create for url_request is a document that explains the relationship between URLRequest, URLRequestJob, etc, at this higher level and with diagrams visually depicting the relationship between the various static methods, callbacks and delegates. Wan-Teh --~--~-~--~~~---~--~~ 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: Plugin control flow and race conditions
On Mon, Aug 17, 2009 at 11:43 AM, bsmedberg bsmedb...@gmail.com wrote: At Mozilla we're currently working on implementing multi-process plugin hosts similar to the model used by Chromium. However, we're having trouble working through the many potential race conditions introduced by having multiple processes (and therefore multiple flows of control). I've read http://dev.chromium.org/developers/design-documents/plugin-architecture but that doesn't seem to address most of the issues we're facing. For the detailed view of how we solve these issues, the best place to look at is the code. Specifically, plugin_channel.cc ipc_sync_channel.cc. To avoid deadlock, when one process is sending a synchronous message, it responds to other synchronous messages in the meantime. However to avoid unnecessary reentrancy, we disable this for synchronous messages from the plugin process unless that process is itself responding to synchronous messages. We did this because otherwise a plugin process could try to force layout while it's already happening, which is not expected in WebKit. You can find more about this in PluginChannel's constructor, we call SendUnblockingOnlyDuringDispatch which makes it so that synchronous The most obvious problem is that both processes may send a synchronous IPC message at the same time. Assuming that these don't deadlock, the native stack for the two calls would end up interleaved. What happens when the renderer process and the plugin process send conflicting messages at roughly the same time? For example: the browser finishes a network request with NPP_DestroyStream and the plugin (responding to a UI event, perhaps) calls NPN_DestroyStream simultaneously? I can't imagine that a plugin would expect to receive aa NPP_DestroyStream message after it has already called NPN_DestroyStream, and this is likely to cause erratic plugin behavior. This specific case is not really a problem. If you look at our implementation of PluginInstance::NPP_DestroyStream(), we set NPStream.ndata to NULL. The second call would early exit if it's already null. Are the IPC delegates/stubs responsible for checking the state of each call and avoiding improper nesting? Do you have any procedure/system for detecting with racy improper nesting? For example, racing pairs NPP_Write/NPN_DestroyStream and NPN_RequestRead/NPP_DestroyStream are equally unexpected. And all these example come only from the NPStream interface; I haven't even begun to examine potential message races in the core NPP APIs or the NPObject APIs. We did run into a bunch of these issues early on, but they were all easy to workaround (i.e. always checking first if the stream is destroyed, since it could be called afterwards in the situations that you describe). The hardest issues we've had to solve are related to performance. The initial release had poor performance when scrolling with lots of windowed/windowless plugins. To solve this, we moved to an asynchronous painting/scrolling model. While adding extra complexity and memory usage, the user experience when scrolling is much better. The techniques we used should be applicable in your implementation as well, we can talk more about this when you're ready (plugin lunch? :) ). --BDS --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Clobber required for Windows
If you see errors like the following, clobber your build: C:\b\slave\chromium-dbg-builder\build\src\chrome\utility\utility_thread.cc : warning C4651: '/DCOMPILING_SYNCAPI_STUB' specified for precompiled header but not for current compile ( chrome.gyp no longer defines COMPILING_SYNCAPI_STUB ) - nick --~--~-~--~~~---~--~~ 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: Can't edit others' codereviews?
On Tue, Aug 18, 2009 at 5:37 AM, Evan Martin e...@chromium.org wrote: On Sat, Aug 15, 2009 at 11:44 PM, Nico Webertha...@chromium.org wrote: `git cl patch` reuses existing issues, so when landing stuff for other people, I used to edit the issue on codereview to add Patch by someone+usuallytru...@example.org someone%2busuallytru...@example.org before landing. So for me editing other people's issues is useful. $ git cl dcommit --help | grep -- -c -c CONTRIBUTOR external contributor for patch (appended to description) My typical workflow is: grep trung AUTHORS select line with full name git cl dcommit -c middle click here I think it'd be neat to somehow use git's distinction of author vs committer such that when you patch in a cl (with git cl patch) it plumbs the rietveld-side author info into the local git commit info and from there into the svn commit, but I think the mapping of rietveld username to AUTHORS username isn't very clear. A little hacky, but you could reuse the url used for autocomplete in reviewers/CC boxes. i.e. http://codereview.chromium.org/account?q=Evan%20Martin returns e...@chromium.org (Evan Martin) PS: Personal OKR of responding to 100% of messages mentioning git remains green. :D --~--~-~--~~~---~--~~ 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: fighting the test flakiness
This is very useful. How about a link to this some where on the main builder page. -Scott On Tue, Jul 28, 2009 at 9:52 AM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: So, the flakiness dashboard is now public and updated daily, at http://build.chromium.org/buildbot/flakiness-report/ . It displays top 15 flaky test groups and tests, and relevant parts of the logs (toggle details javascript link). It has dates of the first and last flip of each test or group. It's a feature that was frequently asked for, and if you have any more feedback, I will be glad to hear it. One thing it currently does not track correctly are test crashes/timeouts I think. I'm working on that. It also doesn't track browser_tests yet. There is a label in the bug tracker FlakyTest - please use it when reporting flaky tests. One of my goals is to fix those bugs. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Flakiness and you: A set of tasks
A couple weeks ago, I wrote an email emphasizing the need to fix flakiness/crashes/etc. Since you might be having trouble figuring out how to bite off a piece of that problem, here are concrete ways you can help: * 20 people needed to fix failing LayoutTests. src/webkit/tools/layout_tests/test_expectations.txt gives a list. All kinds of experts are useful here: Mac, Windows or Linux people; WebCore hackers; Skia and graphics people. * 10 people needed to triage bugs with crash in them, determine whether they are actionable, and send them to the right people. http://code.google.com/p/chromium/issues/list?q=crash People who are good at debugging crashes anyway especially welcome here. Any of the ex-Green Border folks, like finnur or cpu, can probably help look at individual cases. * 6 people needed to rewrite ui_tests as unit_tests, in-process Browser tests, or some other less flaky kind of test. Anyone with frontend experience is especially valuable here. Talk to jcampan to find out what to do. * 3 people needed to eliminate Purify suppressions (src/chrome/test/data/purify/*) and fix related bugs. erikkay can help you with what to do. * 3 people needed to review Coverity results and fix any problems. Look at http://code.google.com/p/chromium/issues/list?q=coverity . * 2 people needed to triage leak bugs. http://code.google.com/p/chromium/issues/list?q=leak has the list. Figure out which of these we can do something about. * 2 people needed to eliminate existing valgrind suppressions (src/chrome/test/data/valgrind/*) and help track down other problems that show up in valgrind. deanm is an expert here and could help you learn how to use this powerful tool. * 2 people needed to look into http://code.google.com/p/chromium/issues/detail?id=11700 , general jank after things get swapped out (e.g. when using your computer after it's been asleep for hours). We have ideas on how to solve this, mbelshe is one of the most knowledgeable consults here. * 1 person needed to triage bugs with jank in them ( http://code.google.com/p/chromium/issues/list?q=jank ) and figure out what the magnitude of the effects are, and how to prioritize the bugs. * 1 person needed to improve infrastructure so flakiness is easier to deal with. Flakiness dashboards, stack traces on buildbots when things fail, etc. phajdan.jr and ojan have both worked in this area and might have projects you can help with, and pamg and nsylvain know a lot in general about our infrastructure and how to improve it. If you add those up, you get 50 people, each being asked to devote a significant portion of the next few months to the problem in question. And this is (IMO) a conservative estimate of what will be needed to deal with the problems at hand. If you are a Googler, go over this with your manager and figure out something you can help with. Put it on your OKRs. Earn a peer bonus from me at EOQ. Make Chrome 4 the fastest, most stable release ever. If you don't work at Google, this is a chance for you to help make the browser much better, and earn commit access (if you don't have it). 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: about:extensions?
On Tue, Aug 18, 2009 at 1:32 PM, Robert Dailey rcdai...@gmail.com wrote: Hello, I'm asking here and not in the chromium-discuss list because I'm using the very latest CI build and I am not confident anyone is going to be able to answer this except for the devs. You should have asked in chromium-discuss. Is there a special page in Chromium (Like about:plugins) to view extensions, their version, and possibly a button or so to manually force them to update or see their update status? Thanks. The closest that currently exists is chrome://extensions/ . (You have to type that in, it won't work as a link.) 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: about:extensions?
It's chrome://extensions/ On Tue, Aug 18, 2009 at 13:32, Robert Dailey rcdai...@gmail.com wrote: Hello, I'm asking here and not in the chromium-discuss list because I'm using the very latest CI build and I am not confident anyone is going to be able to answer this except for the devs. Is there a special page in Chromium (Like about:plugins) to view extensions, their version, and possibly a button or so to manually force them to update or see their update status? Thanks. --~--~-~--~~~---~--~~ 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: about:extensions?
Maybe we should alias about:extensions to point to chrome://extensions/ ? Adam On Tue, Aug 18, 2009 at 2:20 PM, Peter Kastingpkast...@chromium.org wrote: On Tue, Aug 18, 2009 at 1:32 PM, Robert Dailey rcdai...@gmail.com wrote: Hello, I'm asking here and not in the chromium-discuss list because I'm using the very latest CI build and I am not confident anyone is going to be able to answer this except for the devs. You should have asked in chromium-discuss. Is there a special page in Chromium (Like about:plugins) to view extensions, their version, and possibly a button or so to manually force them to update or see their update status? Thanks. The closest that currently exists is chrome://extensions/ . (You have to type that in, it won't work as a link.) 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] Free to good home: a chunky, non-trivial task of decoupling Chromium WebKit port from Chromium build system.
If you don't commit to WebKit, you can stop reading now. I am looking for someone to own a fairly large-sized task: bringing up WebKit-side build of our port to life. The bug for it is here: https://bugs.webkit.org/show_bug.cgi?id=28396 The big picture is here: https://trac.webkit.org/wiki/Chromium I started writing down ideas/thoughts in the comments. Any takers? :DG --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Is it possible to link Chromium to shared CRT on Windows (i.e. /MD instead of /MT)
I'm incorporating Chromium into an existing that uses the shared CRT. To minimize footprint, I'd like to experiment with linking Chromium to the shared CRT as well. I've tried changing RuntimeLibrary in common.gypi, but I'm getting numerous linker errors (I think b/c of tcmalloc's dependence on static CRT?). Does anyone know if this is a supported configuration and/or have suggestions on how to get it working. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] running reliability tests
Hi, How can I run the reliability tests, specifically the automated UI tests, locally? Thanks, James Hawkins --~--~-~--~~~---~--~~ 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: Is it possible to link Chromium to shared CRT on Windows (i.e. /MD instead of /MT)
On Tue, Aug 18, 2009 at 2:40 PM, Daniel Cowx daniel.c...@gmail.com wrote: I'm incorporating Chromium into an existing that uses the shared CRT. To minimize footprint, I'd like to experiment with linking Chromium to the shared CRT as well. I've tried changing RuntimeLibrary in common.gypi, but I'm getting numerous linker errors (I think b/c of tcmalloc's dependence on static CRT?). Does anyone know if this is a supported configuration and/or have suggestions on how to get it working. Other memory allocaters can be switched at runtime now, so I'm sure you can use another if that's the only dependency. Also, have you looked at this: http://code.google.com/p/chromiumembedded/ It's possible that's what you want and/or they have already solved this problem. (Not sure.) --~--~-~--~~~---~--~~ 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: To get your work onto 3.0 stable
Question, have all the strings been translated? I tried Spanish and saw some untranslated stuff, i.e. IDS_OPEN_FILE_DIALOG_TITLE, IDS_OMNIBOX_SEARCH_HINT_INFOBAR_TEXT, and IDS_BLACKLIST_MESSAGE. I think these all made it in before the deadline. On Wed, Aug 12, 2009 at 12:52 PM, Glen Murphyg...@chromium.org wrote: 2. String freeze was weeks ago - if you still require string changes for your 3.0 feature, you're out of luck; you may have to hack around it using existing strings, though this might be worse than not shipping your feature. --~--~-~--~~~---~--~~ 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: To get your work onto 3.0 stable
The strings are still being processed, I haven't merged in the translations yet. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Aug 18, 2009 at 5:50 PM, Lei Zhang thes...@chromium.org wrote: Question, have all the strings been translated? I tried Spanish and saw some untranslated stuff, i.e. IDS_OPEN_FILE_DIALOG_TITLE, IDS_OMNIBOX_SEARCH_HINT_INFOBAR_TEXT, and IDS_BLACKLIST_MESSAGE. I think these all made it in before the deadline. On Wed, Aug 12, 2009 at 12:52 PM, Glen Murphyg...@chromium.org wrote: 2. String freeze was weeks ago - if you still require string changes for your 3.0 feature, you're out of luck; you may have to hack around it using existing strings, though this might be worse than not shipping your feature. --~--~-~--~~~---~--~~ 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: running reliability tests
The information on how to do this is currently on the internal wiki, although it seems there's no reason it shouldn't be moved to the public wiki (not it :) ). http://wiki.corp.google.com/twiki/bin/view/Main/ChromeDebuggingChromeBotCrashes On Tue, Aug 18, 2009 at 3:42 PM, James Hawkins jhawk...@chromium.orgwrote: Hi, How can I run the reliability tests, specifically the automated UI tests, locally? Thanks, James Hawkins --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Access keys for Chrome menus, what do you prefer?
Hi all, Currently, all the functionality in Chrome toolbar has a keyboard shortcut connected to it, except for the App and Page menus. For a keyboard user, currently, you can SHIFT+ALT+T and use the right arrow key to move focus to the menus. This is not very effective and would be better to have a quick way accessing these menus from the keyboard. My suggestion would be: ALT+A for App Menu and ALT+P for Page Menu. I would like some of your suggestions before I implement and commit the change. And I would need feedback from the UI Team. The bug tracker for this would be: http://crbug.com/906 - Mohamed Mansour --~--~-~--~~~---~--~~ 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: Access keys for Chrome menus, what do you prefer?
I'm not sure about accesskeys, but my feeling is just pressing Alt should definitely hilight the one of the two menus. -Ben On Tue, Aug 18, 2009 at 8:11 PM, Mohamed Mansourm...@chromium.org wrote: Hi all, Currently, all the functionality in Chrome toolbar has a keyboard shortcut connected to it, except for the App and Page menus. For a keyboard user, currently, you can SHIFT+ALT+T and use the right arrow key to move focus to the menus. This is not very effective and would be better to have a quick way accessing these menus from the keyboard. My suggestion would be: ALT+A for App Menu and ALT+P for Page Menu. I would like some of your suggestions before I implement and commit the change. And I would need feedback from the UI Team. The bug tracker for this would be: http://crbug.com/906 - Mohamed Mansour --~--~-~--~~~---~--~~ 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: Access keys for Chrome menus, what do you prefer?
on linux we do alt+e for page menu and alt+f for wrench menu. The reasoning is that these two menus are reasonable approximations of the Edit and File menus, respectively. -- Evan Stade On Tue, Aug 18, 2009 at 8:14 PM, Ben Goodger (Google)b...@chromium.org wrote: I'm not sure about accesskeys, but my feeling is just pressing Alt should definitely hilight the one of the two menus. -Ben On Tue, Aug 18, 2009 at 8:11 PM, Mohamed Mansourm...@chromium.org wrote: Hi all, Currently, all the functionality in Chrome toolbar has a keyboard shortcut connected to it, except for the App and Page menus. For a keyboard user, currently, you can SHIFT+ALT+T and use the right arrow key to move focus to the menus. This is not very effective and would be better to have a quick way accessing these menus from the keyboard. My suggestion would be: ALT+A for App Menu and ALT+P for Page Menu. I would like some of your suggestions before I implement and commit the change. And I would need feedback from the UI Team. The bug tracker for this would be: http://crbug.com/906 - Mohamed Mansour --~--~-~--~~~---~--~~ 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: Access keys for Chrome menus, what do you prefer?
sgtm. -Ben On Tue, Aug 18, 2009 at 8:32 PM, Evan Stadeest...@chromium.org wrote: on linux we do alt+e for page menu and alt+f for wrench menu. The reasoning is that these two menus are reasonable approximations of the Edit and File menus, respectively. -- Evan Stade On Tue, Aug 18, 2009 at 8:14 PM, Ben Goodger (Google)b...@chromium.org wrote: I'm not sure about accesskeys, but my feeling is just pressing Alt should definitely hilight the one of the two menus. -Ben On Tue, Aug 18, 2009 at 8:11 PM, Mohamed Mansourm...@chromium.org wrote: Hi all, Currently, all the functionality in Chrome toolbar has a keyboard shortcut connected to it, except for the App and Page menus. For a keyboard user, currently, you can SHIFT+ALT+T and use the right arrow key to move focus to the menus. This is not very effective and would be better to have a quick way accessing these menus from the keyboard. My suggestion would be: ALT+A for App Menu and ALT+P for Page Menu. I would like some of your suggestions before I implement and commit the change. And I would need feedback from the UI Team. The bug tracker for this would be: http://crbug.com/906 - Mohamed Mansour --~--~-~--~~~---~--~~ 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: Access keys for Chrome menus, what do you prefer?
Alright, I have changed it to use alt+e and alt+f. http://codereview.chromium.org/174044/show http://codereview.chromium.org/174044/showWould be nice if a user presses just alt and it would bring up the default main menu. The page menu is used more than the app menu. Would be nice to incorporate that into Chromium. What do you all think? - Mohamed Mansour On Tue, Aug 18, 2009 at 11:32 PM, Ben Goodger (Google) b...@chromium.orgwrote: sgtm. -Ben On Tue, Aug 18, 2009 at 8:32 PM, Evan Stadeest...@chromium.org wrote: on linux we do alt+e for page menu and alt+f for wrench menu. The reasoning is that these two menus are reasonable approximations of the Edit and File menus, respectively. -- Evan Stade On Tue, Aug 18, 2009 at 8:14 PM, Ben Goodger (Google)b...@chromium.org wrote: I'm not sure about accesskeys, but my feeling is just pressing Alt should definitely hilight the one of the two menus. -Ben On Tue, Aug 18, 2009 at 8:11 PM, Mohamed Mansourm...@chromium.org wrote: Hi all, Currently, all the functionality in Chrome toolbar has a keyboard shortcut connected to it, except for the App and Page menus. For a keyboard user, currently, you can SHIFT+ALT+T and use the right arrow key to move focus to the menus. This is not very effective and would be better to have a quick way accessing these menus from the keyboard. My suggestion would be: ALT+A for App Menu and ALT+P for Page Menu. I would like some of your suggestions before I implement and commit the change. And I would need feedback from the UI Team. The bug tracker for this would be: http://crbug.com/906 - Mohamed Mansour --~--~-~--~~~---~--~~ 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: Updating a git repo?
Shouldn't `git pull gclient sync` be sufficient? That's what http://code.google.com/p/chromium/wiki/UsingGit recommends, and what I use (although my git sometimes gets confused about svn, and I have to do `rm -rf .git/svn git svn fetch` every now and then). On Tue, Aug 18, 2009 at 7:54 PM, Jeremy Moskovichjer...@chromium.org wrote: One of the nice things about git is that you can pull down a large chunk of upstream changes really fast. I have a tree checked out from git.chromium.org and the command I'm using to update is: $ git svn fetch git svn rebase gclient sync So basically I'm pulling down revisions one by one from svn which doesn't seem like the right thing to do. What is the correct way to pull down updates into a git tree? Is it possible to pull remote changes from the upstream git server while committing to the svn repo? Best regards, Jeremy --~--~-~--~~~---~--~~ 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: Access keys for Chrome menus, what do you prefer?
Is the page menu really used more than the app menu? If the keys correspond to file/edit equivs, that would suggest wrench should be default. -Ben On Tue, Aug 18, 2009 at 9:20 PM, Mohamed Mansourm...@chromium.org wrote: Alright, I have changed it to use alt+e and alt+f. http://codereview.chromium.org/174044/show Would be nice if a user presses just alt and it would bring up the default main menu. The page menu is used more than the app menu. Would be nice to incorporate that into Chromium. What do you all think? - Mohamed Mansour On Tue, Aug 18, 2009 at 11:32 PM, Ben Goodger (Google) b...@chromium.org wrote: sgtm. -Ben On Tue, Aug 18, 2009 at 8:32 PM, Evan Stadeest...@chromium.org wrote: on linux we do alt+e for page menu and alt+f for wrench menu. The reasoning is that these two menus are reasonable approximations of the Edit and File menus, respectively. -- Evan Stade On Tue, Aug 18, 2009 at 8:14 PM, Ben Goodger (Google)b...@chromium.org wrote: I'm not sure about accesskeys, but my feeling is just pressing Alt should definitely hilight the one of the two menus. -Ben On Tue, Aug 18, 2009 at 8:11 PM, Mohamed Mansourm...@chromium.org wrote: Hi all, Currently, all the functionality in Chrome toolbar has a keyboard shortcut connected to it, except for the App and Page menus. For a keyboard user, currently, you can SHIFT+ALT+T and use the right arrow key to move focus to the menus. This is not very effective and would be better to have a quick way accessing these menus from the keyboard. My suggestion would be: ALT+A for App Menu and ALT+P for Page Menu. I would like some of your suggestions before I implement and commit the change. And I would need feedback from the UI Team. The bug tracker for this would be: http://crbug.com/906 - Mohamed Mansour --~--~-~--~~~---~--~~ 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: Access keys for Chrome menus, what do you prefer?
On Tue, Aug 18, 2009 at 9:20 PM, Mohamed Mansour m...@chromium.org wrote: Would be nice if a user presses just alt and it would bring up the default main menu. The page menu is used more than the app menu. Would be nice to incorporate that into Chromium. What do you all think? Please copy Windows native behavior: pressing alt should highlight a menu (the tools menu, since that's what we're hooking alt-f to), but not actually open it. 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: Access keys for Chrome menus, what do you prefer?
btw, alt alone appears to do nothing for gtk apps. Also, I don't really care which one alt highlights, but it seems to me that alt just highlights the leftmost menu. This happens to always be File. If the File menu is not leftmost, then it's unclear which should be highlighted. -- Evan Stade On Tue, Aug 18, 2009 at 9:37 PM, Peter Kastingpkast...@google.com wrote: On Tue, Aug 18, 2009 at 9:20 PM, Mohamed Mansour m...@chromium.org wrote: Would be nice if a user presses just alt and it would bring up the default main menu. The page menu is used more than the app menu. Would be nice to incorporate that into Chromium. What do you all think? Please copy Windows native behavior: pressing alt should highlight a menu (the tools menu, since that's what we're hooking alt-f to), but not actually open it. 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: How to keep aware of bug changes for a particular label
Just so we don't waste Darin's time on administering code.google.com when he could be doing Yet Another Code Review... Please send requests for issue tracker changes --like getting automatically CC'd for a given label-- to jon@ and laforge@ (chromium.org). --Mark On Mon, Aug 17, 2009 at 11:36, Aaron Boodman a...@chromium.org wrote: Darin, can you make this list of people automatically cc'd for Area-Extensions? aa asargent nickbaum erikkay mpcomplete rafaelw - a On Mon, Aug 17, 2009 at 11:27 AM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: You need someone with admin privileged on bugtracker do that for you. For example, I'm on CC for every FlakyTest bug, and Darin helped me do that. On Mon, Aug 17, 2009 at 11:25, Aaron Boodman a...@chromium.org wrote: I would like to be cc'd on every bug that has the label: Area-Extensions. Is this possible to automate? How do other subteams keep aware of bugs changes? - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
