1. 16 Aug, 2016 1 commit
    • torne's avatar
      Remove now-unnecessary .obj() in Java method calls. · 948f3666
      torne authored
      Java methods can now be passed JavaRef parameters directly; remove calls
      to .obj() that were being used to convert JavaRef to bare jobject, in
      preparation for requiring JavaRef to be used.
      
      This CL only fixes cases that can be fixed by removing the precise
      string ".obj()" from a function call and does not introduce any other
      changes (though it was run through git cl format to rewrap lines
      afterward). This is to enable rubberstamp reviews.
      
      There are a much smaller number of nontrivial changes required to
      completely eliminate use of bare jobject as Java method parameters,
      which will come in followup CLs for proper review.
      
      BUG=506850
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
      
      Review-Url: https://codereview.chromium.org/2237943002
      Cr-Commit-Position: refs/heads/master@{#412237}
      948f3666
  2. 04 Aug, 2016 1 commit
    • torne's avatar
      Add missing using statements for JNI types. · 86560114
      torne authored
      Currently jni_generator_helper.h includes a using statement for
      JavaParamRef and ScopedJavaLocalRef. To allow this to be removed (since
      it shouldn't really be there in a header file), add a "using" statement
      to all the files currently depending on this.
      
      BUG=568574
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
      
      Review-Url: https://codereview.chromium.org/2209993003
      Cr-Commit-Position: refs/heads/master@{#409796}
      86560114
  3. 03 Aug, 2016 1 commit
  4. 08 Sep, 2015 1 commit
  5. 07 Mar, 2015 1 commit
    • asanka's avatar
      Be explicit about target type in platform_util::OpenItem() · 655d1118
      asanka authored
      OpenItem() now takes an OpenItemType parameter that should specify
      expected type of the object to be opened. It verifies the type of the
      object before invoking platform specific logic for opening the item.
      
      Code that assumed that the target of OpenItem() was always a folder
      should now no longer unintentionally open or execute the file at the
      target location when this assumption was found to not be correct.
      
      In addition to the checks performed by OpenItem, the platform specific
      logic used to open folders fail if the target type is not a directory.
      
      BUG=387037
      
      Review URL: https://codereview.chromium.org/352393002
      
      Cr-Commit-Position: refs/heads/master@{#319555}
      655d1118
  6. 24 Feb, 2015 1 commit
  7. 13 Dec, 2013 1 commit
  8. 12 Dec, 2013 1 commit
    • hashimoto@chromium.org's avatar
      Stop using GetDefaultProfile() in Chrome OS implementation of platform_util::OpenExternal() · 7f0a3efa
      hashimoto@chromium.org authored
      Add Profile* as an argument of OpenExternal().
      Disallow calling OpenExternal() from threads other than UI thread.
      
      Changes for the implementations:
       Chrome OS implementation: Use the argument Profile and stop posting tasks to UI thread.
       Win implementation: Post tasks to FILE thread. (for the reason noted in external_protocol_handler.cc)
       Other implementations: Just add Profile* argument and add thread check.
      
      Changes for user code:
       1. first_run_dialog.cc: Just pass Profile*.
       2. browser_commands.cc: Pass Profile* acquired from Browser.
       3. chrome_shell_window_delegate.cc: Pass Profile* acquired from WebContents.
       4. external_protocol_handler.cc: Pass Profile* acquired with a pair of render_process_host_id and tab_contents_id.
      
      BUG=322682
      TEST=git cl try
      
      Review URL: https://codereview.chromium.org/107033003
      
      git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240346 0039d316-1c4b-4281-b951-d872f2087c98
      7f0a3efa
  9. 31 Oct, 2013 1 commit
  10. 23 Apr, 2013 1 commit
    • aurimas@chromium.org's avatar
      [Android] Refactor NativeView to be able to use it for AutofillDialog. · 74d96983
      aurimas@chromium.org authored
      Create a new class WindowAndroid that serves the purpose of representing a native (platform specific) view where Chromium code expects to have a cross platform handle to the system view type. As Views are Java objects on Android, ViewAndroid.java and view_android.* will provide the expected abstractions on the C++ side and allow it to be flexibly glued to an actual Android Java View at runtime. It should only be used where access to Android Views is needed from the C++ code as there are easier/better ways to access Views from Java.
      
      This new abstraction will allow to reuse AutofillPopup for regular use in a webpage (using ContentView) as well as for AutofillDialog.
      
      BUG=229199
      
      Review URL: https://chromiumcodereview.appspot.com/14018004
      
      git-svn-id: svn://svn.chromium.org/chrome/trunk/src@195750 0039d316-1c4b-4281-b951-d872f2087c98
      74d96983
  11. 02 Feb, 2013 1 commit
  12. 18 Sep, 2012 1 commit
  13. 28 Feb, 2012 1 commit
  14. 27 Feb, 2012 1 commit
  15. 24 Dec, 2011 1 commit
  16. 23 Dec, 2011 1 commit
  17. 13 Dec, 2011 1 commit
    • ben@chromium.org's avatar
      Move the concept of Activation to the Shell. · 9fc206d7
      ben@chromium.org authored
      The Active Window is now stored in a property on the RootWindow. Classes wishing to observe changes to this can implement WindowObserver and attach to the RootWindow to be notified of changes in this property.
      
      We provide an ActivationClient interface in Aura for customers to use to set/get the active window, and deactivate a window. This is because setting the active window involves more than just changing the property, there is some additional book-keeping that must be done. The ActivationClient is stored in a property on the RootWindow.
      
      We also provide an ActivationDelegate interface in Aura that window owners can use to be notified of changes in activation state, and to specify whether or not a window can be activated. The ActivationDelegate should be stored on the relevant window in a property.
      
      I moved a lot of Activation-related functionality out of Aura, including all of the unit tests, now on ActivationController, and the associated WindowDelegate implementations which have now become a single TestActivationDelegate implementation.
      
      BUG=none
      TEST=unit tests
      Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=114095
      Review URL: http://codereview.chromium.org/8894018
      
      git-svn-id: svn://svn.chromium.org/chrome/trunk/src@114121 0039d316-1c4b-4281-b951-d872f2087c98
      9fc206d7
  18. 12 Dec, 2011 2 commits
    • ben@chromium.org's avatar
      Revert 114095 - Move the concept of Activation to the Shell. · a9ea2b53
      ben@chromium.org authored
      The Active Window is now stored in a property on the RootWindow. Classes wishing to observe changes to this can implement WindowObserver and attach to the RootWindow to be notified of changes in this property.
      
      We provide an ActivationClient interface in Aura for customers to use to set/get the active window, and deactivate a window. This is because setting the active window involves more than just changing the property, there is some additional book-keeping that must be done. The ActivationClient is stored in a property on the RootWindow.
      
      We also provide an ActivationDelegate interface in Aura that window owners can use to be notified of changes in activation state, and to specify whether or not a window can be activated. The ActivationDelegate should be stored on the relevant window in a property.
      
      I moved a lot of Activation-related functionality out of Aura, including all of the unit tests, now on ActivationController, and the associated WindowDelegate implementations which have now become a single TestActivationDelegate implementation.
      
      BUG=none
      TEST=unit tests
      Review URL: http://codereview.chromium.org/8894018
      
      TBR=ben@chromium.org
      Review URL: http://codereview.chromium.org/8926004
      
      git-svn-id: svn://svn.chromium.org/chrome/trunk/src@114101 0039d316-1c4b-4281-b951-d872f2087c98
      a9ea2b53
    • ben@chromium.org's avatar
      Move the concept of Activation to the Shell. · 9b10d2a0
      ben@chromium.org authored
      The Active Window is now stored in a property on the RootWindow. Classes wishing to observe changes to this can implement WindowObserver and attach to the RootWindow to be notified of changes in this property.
      
      We provide an ActivationClient interface in Aura for customers to use to set/get the active window, and deactivate a window. This is because setting the active window involves more than just changing the property, there is some additional book-keeping that must be done. The ActivationClient is stored in a property on the RootWindow.
      
      We also provide an ActivationDelegate interface in Aura that window owners can use to be notified of changes in activation state, and to specify whether or not a window can be activated. The ActivationDelegate should be stored on the relevant window in a property.
      
      I moved a lot of Activation-related functionality out of Aura, including all of the unit tests, now on ActivationController, and the associated WindowDelegate implementations which have now become a single TestActivationDelegate implementation.
      
      BUG=none
      TEST=unit tests
      Review URL: http://codereview.chromium.org/8894018
      
      git-svn-id: svn://svn.chromium.org/chrome/trunk/src@114095 0039d316-1c4b-4281-b951-d872f2087c98
      9b10d2a0
  19. 06 Dec, 2011 1 commit
  20. 30 Nov, 2011 1 commit
  21. 05 Oct, 2011 1 commit
  22. 03 Oct, 2011 1 commit
  23. 14 Sep, 2011 1 commit
  24. 07 Sep, 2011 1 commit