1. 08 Sep, 2009 21 commits
  2. 07 Sep, 2009 14 commits
  3. 06 Sep, 2009 5 commits
    • ananta@chromium.org's avatar
      Chrome side of the fix for http://b/issue?id=1694574, which is a bug caused... · 632fbb17
      ananta@chromium.org authored
      Chrome side of the fix for http://b/issue?id=1694574, which is a bug caused when a new automation client instance is launched and attempts to attach to an existing external tab. An example of where this could happen is javascript on a page attempting a window.open with target _blank. In this case the Chrome browser creates a TabContents instance which is attached to an ExternalTabContainer instance. The automation client then attaches to this ExternalTabContainer. This all works if the automation client is in the same client process. If a new process is launched a separate automation channel is created between the client and the chrome browser which causes this to not work as expected.
      
      Fix is have a floating ExternalTabContainer instance which is eventually connected to by the client. When we receive a notification from the client that it is about to connect to the ExternalTabContainer instance we setup the automation channel and other info in the underlying automation profile.
      
      The new TabContents is created with the same profile instance as the current TabContents. This does not
      work correctly if the underlying profile is an automation profile as its lifetime is tied to the
      ExternalTabContainer. To fix this I added a setter for the new policy to the NavigationController. Not doing
      this causes the browser to crash if the original ExternalTabContainer instance dies.
      
      There is a bigger issue here which is that all this profile sharing would cause session cookies to not work correctly if multiple automation clients are connected to the same Chrome browser instance over the same profile. I will file a separate bug to track this issue.
      
      Bug=1694574
       
      Review URL: http://codereview.chromium.org/200003
      
      git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25594 0039d316-1c4b-4281-b951-d872f2087c98
      632fbb17
    • darin@chromium.org's avatar
      Stick all of the WebKit API enum compile asserts in one file. · a0663ed7
      darin@chromium.org authored
      I did this for two reasons:
      
      1) For enumeration types that are not defined within a class,
      and therefore do not have a corresponding .cpp file, we have
      an obvious place to put the compile asserts.
      
      2) It keeps these assertions out of the more interesting code,
      which should help with readability a bit.
      
      R=jorlow
      BUG=none
      TEST=none
      
      Review URL: http://codereview.chromium.org/198034
      
      git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25593 0039d316-1c4b-4281-b951-d872f2087c98
      a0663ed7
    • dglazkov@chromium.org's avatar
      WebKit Update 48078:48098 · b58f9a4a
      dglazkov@chromium.org authored
      TBR=jianli
      TEST=none
      BUG=21162
      
      Review URL: http://codereview.chromium.org/201039
      
      git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25586 0039d316-1c4b-4281-b951-d872f2087c98
      b58f9a4a
    • suzhe@chromium.org's avatar
      Fix issue 20934: Omnibox keyboard behavior wrong for "See recent pages in history" · 4690e3ef
      suzhe@chromium.org authored
      This CL fixes issue 20934 by eliminating the side effect caused by Enter key press event.
      
      BUG=20934: Omnibox keyboard behavior wrong for "See recent pages in history"
      TEST=Input something in omnibox, make sure it triggers "See N recent pages in history containing XXX", then select this item and press Enter to see if chrome://history/#q=XXX is opened.
      
      Review URL: http://codereview.chromium.org/196020
      
      git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25585 0039d316-1c4b-4281-b951-d872f2087c98
      4690e3ef
    • eroman@chromium.org's avatar
      Aesthetic changes to the proxy configuration log format. · 3dfd29f2
      eroman@chromium.org authored
      Also in this change, I stop brodacasting the proxy settings changes to LOG(INFO) --- This is because navigating to "view-net-internal:proxyservice.config" offers a better solution, so no point polluting the log file.
      
      Note that the format change is intended to make the string more succint and human readable. For example, here is a before and after comparison:
      
      ------------
      New version:
      ------------
      
      Automatic settings:
        Auto-detect: No
        Custom PAC script: [None]
      Manual settings:
        Proxy server: [None]
        Bypass list: [None]
        Bypass local names: No
      
      ------------
      Old version:
      ------------
      
      {
        auto_detect: 0
        pac_url: 
        proxy_rules:
        {
          type: TYPE_NO_RULES
          single_proxy: 
          proxy_for_http: 
          proxy_for_https: 
          proxy_for_ftp: 
          socks_proxy: 
        }
        proxy_bypass_local_names: 0
        proxy_bypass_list:
        id: 1
      }
       
      BUG=http://crbug.com/14478
      TEST=ProxyConfigTest.ToString
      
      Review URL: http://codereview.chromium.org/198039
      
      git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25584 0039d316-1c4b-4281-b951-d872f2087c98
      3dfd29f2