summaryrefslogtreecommitdiffstats
path: root/chrome/browser/external_tab_container.h
Commit message (Collapse)AuthorAgeFilesLines
* ChromeFrame now uses host provided popup blocker.stoyan@chromium.org2010-03-081-2/+2
| | | | | | | | | | | It does not work in all scenarions since from Chrome side an empty string is passed as target url. Note in IE6 "Tools/Popup Blocker" menu is not visible if ChromeFrame is the activedocument. Have to support some IOleCommandTarget command.. BUG=34823 Review URL: http://codereview.chromium.org/668168 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40897 0039d316-1c4b-4281-b951-d872f2087c98
* Initial HTTP requests issued by ChromeFrame popups could bypass the host ↵ananta@chromium.org2010-02-221-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | network stack. The host network stack in ChromeFrame intercepts HTTP requests based on registered render views. When a popup window is created we register it in the AddNewContents notification on the TabContentsDelegate. This is a little late as network requests could be issued before the view actually becomes visible. To fix this we now have a new method in the TabContentsDelegate interface called TabContentsCreated which notifies the delegate about the creation of a new TabContents. The ExternalTabContainer implements this method and registers the render view as pending. I also changed the signature of the RenderViewHostDelegateViewHelper::CreateNewWindow method to return the new TabContents. As part of this fix we also unregister the render view when the ExternalTabContainer is deleted. The container registers for the NotificationType::RENDER_VIEW_HOST_DELETED notification. However we end up deleting the TabContents in WM_DESTROY, which results in the container never receiving this notification. Fixes bug http://code.google.com/p/chromium/issues/detail?id=36323 Bug=36323 Test=Will be covered by the automation proxy test which Stoyan is adding Review URL: http://codereview.chromium.org/652009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@39611 0039d316-1c4b-4281-b951-d872f2087c98
* Clone of issue 600130. (http://codereview.chromium.org/600130)twiz@chromium.org2010-02-161-1/+9
| | | | | | | | | BUG=None TEST=None Review URL: http://codereview.chromium.org/593111 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@39077 0039d316-1c4b-4281-b951-d872f2087c98
* Fix an ExternalTabContainer leak caused in the code path which attaches an ↵ananta@chromium.org2010-02-111-1/+1
| | | | | | | | | | | ExternalTabContainer to an IE tab, which connects to it. The leak occurs because of a refcount leak. This causes the AutomationProvider to not get released thus resulting in a running chrome.exe instance even after we shutdown IE. Review URL: http://codereview.chromium.org/600063 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38735 0039d316-1c4b-4281-b951-d872f2087c98
* This CL adds support for displaying Chrome InfoBars in pages rendered via ↵ananta@chromium.org2010-02-051-1/+9
| | | | | | | | | | | | | | | | | | ChromeFrame. To achieve this the ExternalTabContainer now creates a view which comprises of the InfoBarContainer and the TabContentsContainer view. It uses the GridLayout manager to layout this view. The InfoBarContainer no longer depends on the BrowserView. It now passes notifications to the InfoBarContainerDelegate interface which is implemented by the BrowserView and the ExternalTabContainer. Fixes bug http://code.google.com/p/chromium/issues/detail?id=24051 Bug=24051 Review URL: http://codereview.chromium.org/573022 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38228 0039d316-1c4b-4281-b951-d872f2087c98
* The ExternalTabContainer enters a modal loop while waiting for the unload ↵ananta@chromium.org2010-02-031-0/+5
| | | | | | | | | | | | | | | | | | events on the tab to complete. If multiple ChromeFrame tabs were closed together then we end up in a nested loop hierarchy. In this case the innermost message loop ends up dispatching the TabContents::Close method which then calls its delegate which is the ExternalTabContainer for the other ExternalTabs as well. As a result the outer loops never exit, which causes IE tabs to hang. Fix is to use a local global stack of ExternalTabContainers. If we receive a CloseContents call for any other container but the innermost one, we post it back to the loop. Bug=31853 Review URL: http://codereview.chromium.org/560034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38022 0039d316-1c4b-4281-b951-d872f2087c98
* In IE8 new windows opened within ChromeFrame via window.open calls at times ↵ananta@chromium.org2010-01-301-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bypass the host network stack. In this case we don't get control over the navigation as window.open calls expect to carry the opener relationship over to the new window. This basically means that navigation occurs in Chrome and the new tab/window created by the host attaches to the newly created ExternalTabContainer instance. In IE8 the new tab opens in a new IE process, which basically uses a new automation channel to talk to Chrome. The host network stack implementation routes network requests issued by registered render views to the host browser over the automation channel. There is a timing window between the new window getting created and issuing network requests and the channel being established with the new iexplore instance. As a result network requests issued by the new window don't use the host network stack. Fix is to register the render view and process as a pending view when we get notified about the new TabContents in the original ExternalTabContainers implementation of TabContentsDelegate::AddNewContents. Any network requests issued for this view would result in the corresponding URLRequestAutomationJob instances getting created as pending as well. When the host browser connects to the new ExternalTabContainer instance, we pass over the new automation channel and tab handle to the URLRequestAutomationJob instances and resume them. This fixes bug http://code.google.com/p/chromium/issues/detail?id=33516 Bug=33516 Test=Login to gmail in IE8 in ChromeFrame. Open up a new conversation and click on New Window which opens up a tear off window. This should not bring up the login prompt again. Will think about a good approach to write a unit test for this behavior and send out a separate CL for that. Review URL: http://codereview.chromium.org/554134 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37585 0039d316-1c4b-4281-b951-d872f2087c98
* Unload and BeforeUnload handlers would not get invoked within pages inside ↵ananta@chromium.org2010-01-271-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | ChromeFrame. This was because the ExternalTabContainer would close the underlying tab contents in its OnDestroy handler without invoking unload handlers on the page if any. In Chrome the TabStripModel invokes the RunUnloadListenerBeforeClosing on the delegate which is implemented by the browser. We need to mimic this in the external tab container. To achieve this we now have a static helper function RunUnloadListenerBeforeClosingHelper in the browser class which is called by the ExternalTabContainer and the Browser::RunUnloadListenerBeforeClosing function. The ExternalTabContainer also needs to wait for the unload handlers on the page to return before it returns control back to the host browser. To achieve this we enter a nested modal loop which is exited when the underlying tab is closed. Fixes bug http://code.google.com/p/chromium/issues/detail?id=31853 Bug=31853 Test=Covered by ChromeFrame unit test. Review URL: http://codereview.chromium.org/543183 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37197 0039d316-1c4b-4281-b951-d872f2087c98
* Unhandled keyboard messages coming back from the host browser running ↵ananta@chromium.org2010-01-121-1/+14
| | | | | | | | | | | | | | | | | | | | | ChromeFrame need to process accelerators. Currently accelerators are processed by the focus manager. We already have code in browser_view to process unhandled keyboard messages coming back from the renderer. Moved this code to a new class UnhandledKeyboardEventHandler which maintains state about whether the next character event has to be ignored, etc. This class is now used by BrowserView and the ExternalTabContainer to process unhandled keyboard messages. To support accelerators in ChromeFrame, the ExternalTabContainer needs to implement an Accelerator target. I also added a minimal accelerator table for Chromeframe in the chrome_dll.rc and chrome_dll_resource.h files. This fixes bug http://code.google.com/p/chromium/issues/detail?id=31672 Bug=31672 Review URL: http://codereview.chromium.org/536023 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36037 0039d316-1c4b-4281-b951-d872f2087c98
* Multiple chrome frame activex controls should instantiate and navigate ↵ananta@chromium.org2009-12-181-1/+2
| | | | | | | | | | | | | | | | | | | | | | | correctly in IE. This was not the case due to a race condition between put_src getting called for subsequent activex instances and the external tab to hold the chrome frame instance getting created. Fix is to pass in the URL if we have it when the automation client is initialized to launch the chrome automation server. If not we navigate when the external tab is created. To achieve this we stuff in all relevant parameters into a structure which is populated when the automation client is initialized. I also changed the CreateExternalTab message to carry the referrer for the initial navigation. Fixes http://code.google.com/p/chromium/issues/detail?id=28236 Test=added unit tests for the same. The firefox one is not working at this point. Disabled this test for now while I debug it. Bug=28236 Review URL: http://codereview.chromium.org/500123 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34985 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor the keyboard events handling code related to ↵suzhe@chromium.org2009-12-101-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | RenderViewHostDelegate::View and TabContentsDelegate interfaces. Significant changes made by this CL: 1. The keyboard event handling code has been moved from TabContentsView implementation classes into BrowserWindow implementation classes. Please refer to this discussion thread: http://groups.google.com/group/chromium-dev/browse_thread/thread/e6e0b5cc105659b7/9953c4308bb0000c This change makes the keyboard event flow comply with the relationship between TabContents/TabContentsView and TabContentsDelegate/BrowserWindow. Besides it, the code is also simplified a lot, for example, the keyboard event handling code in chrome/browser/views/tab_contents/tab_contents_view_{gtk,win}.cc are now merged into one copy and moved into chrome/browser/views/frame/browser_view.cc. 2. A pre-handle phrase has been added into the keyboard event handling flow. A keyboard event will be first sent to the browser for pre-handling before being sent to the renderer. Then if the event was not handled by the renderer, it'll be sent to the browser again for post-handling. 3. The keyboard accelerator handling code of Windows and Linux ports have been optimized to get rid off extra command lookup. 4. The keyboard event message flow between the browser and the renderer is changed back to full async mode, all complex logics introduced by revision 29857 are removed. BUG=24479, 26054, 26131, 28839 TEST=See bug reports. Review URL: http://codereview.chromium.org/400012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34234 0039d316-1c4b-4281-b951-d872f2087c98
* A collection of fixes allowing the chrome.experimental.popup.* set of APIs ↵twiz@google.com2009-12-101-0/+6
| | | | | | | | to function in circumstances where there is no Browser instance present. This is a symptom of a tab-contents view hosted in an ExternalTabContainer.The major change here is the removal of the explicit dependency on a Browser instance across all of the delegates involved when showing a pop-up API. I modified the following delegates:- ExtensionPopupHost::Delegate- TabContentsDelegate- ExtensionFunctionDispatcher::DelegateBecause the pop-up requires a Profile, and a gfx::NativeWindow, I added methods to the above interfaces to provide them.BUG=noneTEST=ExtensionApiTest.FLAKY_Popup Review URL: http://codereview.chromium.org/434046 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34219 0039d316-1c4b-4281-b951-d872f2087c98
* Speculative fix for ChromeFrame crash in bug ↵ananta@chromium.org2009-12-021-1/+2
| | | | | | | | | | | | | | | | | | | | http://code.google.com/p/chromium/issues/detail?id=29025 The crash occurs while dereferencing the automation channel to send out the SetCookie IPC message on the automation channel to the host browser. Based on what I could see from the crash dump and the code it seems like there could be a scenario where the AutomationResourceContext object could be destroyed while the AutomationCookieStore object is still around and thus ends up with a stale pointer which crashes when dereferenced. Fix is to ensure that all related code paths hold on to a refcounted AutomationResourceContext instance. I will look into whether it is possible to come up with a unit test for this. Bug=29025 Review URL: http://codereview.chromium.org/450020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33524 0039d316-1c4b-4281-b951-d872f2087c98
* amit, please review everything, jam please review the changes to the ↵ananta@chromium.org2009-11-171-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | tab_contents and the renderer_host sources. Remove the AutomationProfileImpl class which wraps the Chrome profile for an external tab container, which hosts ChromeFrame. This object was used to carry a custom URL request context which was used to intercept HTTP requests and cookie requests issued by external tabs. However as the life time of the automation profile class depended on the lifetime of the external tab container object this caused a number of crashes in objects which held on to the automation profile pointer retrieved from the associated tab contents. This does not happen in a regualar Chrome browser instance as the profile is deleted at the very end. We can associate the automation URL request context with the underlying tab_contents which would eventually percolate down to the resource message filter. Doing this would avoid the need for the AutomationProfile class. This CL achieves that. Bug=27695,27662 Review URL: http://codereview.chromium.org/385117 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32127 0039d316-1c4b-4281-b951-d872f2087c98
* Modifying extension automation so that it is done through a particularjoi@chromium.org2009-11-081-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | tab for all extension views. Previously, API routing to the automation client would only work for extension views that were contained in the particular ExternalTab instance being automated. This meant you couldn't test API calls from e.g. background pages. Also using async functions instead of the previous RVH-based hack. Updating one of the UI tests to make the API calls from a background page, to provide an end-to-end test of the new routing. This makes AutomationProvider::SetEnableAutomationExtension Windows-only, but it effectively always was since it was already dependent on ExternalTabContainer (indirectly, to provide a non-empty implementation of TabContentsDelegate::ForwardMessageToExternalHost). BUG=none TEST=ui_tests.exe, chrome_frame_tests.exe, chrome_frame_unittests.exe Review URL: http://codereview.chromium.org/366025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31403 0039d316-1c4b-4281-b951-d872f2087c98
* Basic wiring to enable downloads for CF's host browser network stack. A ↵tommi@chromium.org2009-11-071-0/+3
| | | | | | | | notable change here is that url automation job id's no longer exist and instead a request id is used. There's a 1 to 1 relation between a job and a request so this is more convenient. Review URL: http://codereview.chromium.org/355036 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31363 0039d316-1c4b-4281-b951-d872f2087c98
* Ninth patch in making destructors of refcounted objects private.jam@chromium.org2009-11-071-1/+4
| | | | | | | | BUG=26749 Review URL: http://codereview.chromium.org/372013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31357 0039d316-1c4b-4281-b951-d872f2087c98
* Ensure that the correct URL and title is displayed in the host browser if ↵ananta@chromium.org2009-10-141-0/+4
| | | | | | | | | | | | | | | | | | | | | | the browser tab is attached to an existing external tab. This can happen if a script running in chrome invokes window.open which opens a popup window. To ensure that the title and URL display correctly we send over the navigation state changed IPC from Chrome when we receive an IPC from ChromeFrame indicating that it connected to the external tab. I also made a change to the function which sends over the navigation state to chrome to ensure that we set the title to the URL if it is empty. This mimics Chrome and the other browser's behavior. This should fix http://code.google.com/p/chromium/issues/detail?id=24024 Bug=24024 Review URL: http://codereview.chromium.org/274035 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28991 0039d316-1c4b-4281-b951-d872f2087c98
* This CL is for the needs of ChromeFrame.stoyan@google.com2009-10-131-0/+1
| | | | | | | | | | | | TabContentsDelegate implementation may override navigations caused by JsvaScript history object. Yet not perfect since webkit view of navigation stack differs from the view of external-non-Chrome-host-browser. We have to provide the full stack from host-browser (+visited links alongside) in the same way as Chrome-browser provides it to renderer. BUG=24004 Review URL: http://codereview.chromium.org/261046 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28818 0039d316-1c4b-4281-b951-d872f2087c98
* Any time we are shutting down a tab, try to use fast shutdown.estade@chromium.org2009-10-021-1/+0
| | | | | | | | | BUG=http://crbug.com/5638 TEST=existing tab strip model tests, Fast shutdown ui tests, new tab strip model fast shutdown test Review URL: http://codereview.chromium.org/235050 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27865 0039d316-1c4b-4281-b951-d872f2087c98
* Support the View Page Info option in the ExternalTabContainer, which would ↵ananta@chromium.org2009-09-121-0/+5
| | | | | | | | | | | | | | allow this to work in external automation clients. This fixes bug http://b/issue?id=2093098 Bug=2093098 Review URL: http://codereview.chromium.org/192080 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26085 0039d316-1c4b-4281-b951-d872f2087c98
* ExternalTabcontainer browser to initial URLamit@chromium.org2009-09-111-1/+3
| | | | | | | | | | | | | Browse the newly created external tab to the specified initial URL if present, to about:blank otherwise. Also send information about SSL status when sending navigation updates to the automation client. BUG=none TEST=CreateExternalTabWithUrl UI test Review URL: http://codereview.chromium.org/193054 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26037 0039d316-1c4b-4281-b951-d872f2087c98
* Chrome side of the fix for http://b/issue?id=1694574, which is a bug caused ↵ananta@chromium.org2009-09-061-7/+28
| | | | | | | | | | | | | | | | | | | 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
* InitNavigationInfo only if there's a valid entryamit@chromium.org2009-08-211-1/+1
| | | | | | | | | | | | | | Automation can send information about an entry only if it exists. Handle the case that during early loading there's no navigation entry and we can avoid sending navigation information. BUG=none TEST=none Review URL: http://codereview.chromium.org/174225 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23995 0039d316-1c4b-4281-b951-d872f2087c98
* Support navigating to absolute index through automation.amit@chromium.org2009-08-191-0/+8
| | | | | | | | | | | | Also, send more information in AutomationMsg_DidNavigate BUG=none TEST=none Review URL: http://codereview.chromium.org/165333 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23776 0039d316-1c4b-4281-b951-d872f2087c98
* Added support in the ExternalTabContainer for handling the ↵ananta@chromium.org2009-08-141-1/+9
| | | | | | | | | | | | NEW_FOREGROUND_TAB and NEW_BACKGROUND_TAB dispositions in its implementation of TabContents::AddNewContents. These dispositions are handled by creating a new ExternalTabContainer instance, attaching it to the automation provider and sending off the AutomationMsg_AttachExternalTab IPC to the automation client requesting it to attach to the newly created tab. This fixes bug http://b/issue?id=2050347 Bug=2050347 Review URL: http://codereview.chromium.org/164530 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23483 0039d316-1c4b-4281-b951-d872f2087c98
* If URL requests are to be routed through the external host, the ↵ananta@chromium.org2009-08-101-1/+5
| | | | | | | | | | | | | | | | | | | | ExternalTabContainer instantiates an automation profile object which implements the Profile interface. This object was not being passed the external tab handle which is needed for cookies to be set correctly in the external host. HTTP Post requests should not be treated as top level URL requests to be handled by the external host. These were getting converted incorrectly to HTTP Get requests thus resulting in Post requests not working correctly in the external tab container. Fixes bug http://b/issue?id=2042101 Bug=2042101 Review URL: http://codereview.chromium.org/164207 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22927 0039d316-1c4b-4281-b951-d872f2087c98
* Navigation and cookies for Automationamit@chromium.org2009-07-281-1/+6
| | | | | | | | | | | | | Give Automation better visibility and control over navigations. Also, make it possible for automation to implement a dummy cookie store to go with dummy request serving over automation. BUG=none TEST=none Review URL: http://codereview.chromium.org/159189 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21836 0039d316-1c4b-4281-b951-d872f2087c98
* The ExternalTabContainer object which implements the TabContentsDelegate ↵ananta@chromium.org2009-07-221-0/+12
| | | | | | | | | | | | | | interface now implements the ShowHtmlDialog function which is needed to support HTML dialog popups like those displayed by Gears.' Fixes http://b/issue?id=1963582 Bug=1963582 Review URL: http://codereview.chromium.org/159162 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21289 0039d316-1c4b-4281-b951-d872f2087c98
* Remove the defunct SetAccelerator message and replace it with anamit@chromium.org2009-07-141-7/+2
| | | | | | | | | | | automation message to set initial settings. BUG=none TEST=none Review URL: http://codereview.chromium.org/155376 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20676 0039d316-1c4b-4281-b951-d872f2087c98
* Allow TabContentsDelegates to process unhandled keyboard messages coming ↵ananta@chromium.org2009-07-141-6/+8
| | | | | | | | | | | | | | | | | | | back from the renderer. This is required for ExternalTabContainer to be able to pass unhandled keyboard accelerator messages back to the external host. This worked before as the focus manager would hand off these messages to keystroke listeners like the ExternalTabContainer. However with the ExternalTabContainer no longer using the focus manager this does not work anymore. Removed the keystroke listener code from the focus manager as the ExternalTabContainer was the only consumer and it does not use it anymore. This fixes bug http://b/issue?id=1975749 Bug=1975749 Review URL: http://codereview.chromium.org/149520 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20600 0039d316-1c4b-4281-b951-d872f2087c98
* A prototype of resource loading through automationamit@chromium.org2009-07-091-1/+9
| | | | | | | | | | | | | | | | In a test scenario where we need to load resources over automation, we intercept the URL reqeusts and serve them using automation IPCs. This resource loading can be enabled per tab created by automation. BUG=none TEST=none Review URL: http://codereview.chromium.org/145024 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20267 0039d316-1c4b-4281-b951-d872f2087c98
* In this episode, we implement the DOMUI interface for extension views that ↵aa@chromium.org2009-07-011-3/+0
| | | | | | | | | | are rendered in the main tab contents area. This gets us loaded and unloaded at the right place and removes many special cases for extensions from the RenderViewHost and RenderViewHostDelegate hierarchy. BUG=13936 Review URL: http://codereview.chromium.org/126137 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19717 0039d316-1c4b-4281-b951-d872f2087c98
* Allow external hosts to handle the context menu and thus be able to ↵ananta@chromium.org2009-06-121-0/+17
| | | | | | | | | | | | | | | | | | | | customize it. Changes include 1. A HandleContextMenu function which can be implemented by a TabContentsDelegate. Currently only ExternalTabContainer implements this. 2. Removed InitMenu calls from the RenderViewContextMenu subclass constructors, We need the subclasses to be able to override individual AddMenuItem calls. The newly added RenderViewContextMenuExternalWin class derives from RenderViewContextMenuWin whose constructor calls InitMenu. This happens at a time when the vtable is not yet setup. To fix this we added an Init function to the RenderViewContextMenu base class which then calls a virtual function DoInit, which derived classes can override to perform specific initializations. 3. Added automation messages to send over context menu events to external hosts and back amit, please review everything. estade please review changes to tab_contents_view_gtk.cc and render_view_context_menu_gtk.cc. pinkerton please review changes to tab_contents_view_mac.mm and render_view_context_menu_mac.mm Review URL: http://codereview.chromium.org/119429 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18250 0039d316-1c4b-4281-b951-d872f2087c98
* Rename the TabContents::SetInitialFocus(reverse) method to ↵jcampan@chromium.org2009-06-081-2/+2
| | | | | | | | | | | TabContents::FocusThroughTabTraversal(reverse), as SetInitialiFocus can be easily confused with TabContentView::SetInitialFocus(). BUG=None TEST=None Review URL: http://codereview.chromium.org/118392 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17900 0039d316-1c4b-4281-b951-d872f2087c98
* ExternalTabContainer should subclass WidgetWin rather than Widget and ATL ↵ben@chromium.org2009-05-271-93/+39
| | | | | | | | | | | | CWindowImpl. This makes it much easier to extend the API of Widget. Cleans up ExternalTabContainer to better match chrome style. BUG=none TEST=run ui tests, verify ExternalTabContainer tests pass. Review URL: http://codereview.chromium.org/113892 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16996 0039d316-1c4b-4281-b951-d872f2087c98
* Removes WidgetWin dependency from StatusBubbleViews so that it can compile ↵ben@chromium.org2009-05-261-0/+8
| | | | | | | | | | | | | | | | on Linux. Requires: - making SetOpacity a cross platform method on Widget, replacing SetLayeredAlpha. - moving Window::SetBounds to Widget - replacing usage of MoveWindow in StatusBubbleViews with call to new SetBounds method. BUG=none TEST=make sure transparency still works for floating widgets like - status bubble, full screen exit bubble, dragged tabs Review URL: http://codereview.chromium.org/113846 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16948 0039d316-1c4b-4281-b951-d872f2087c98
* Refactors TabContentsContainerView into TabContentsContainer and associated ↵ben@chromium.org2009-05-221-2/+2
| | | | | | | | | | | platform-specific inner classes. BUG=none TEST=make sure web page focus cycling in and out of the content area still works. Review URL: http://codereview.chromium.org/113784 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16810 0039d316-1c4b-4281-b951-d872f2087c98
* This is the first pass at themes.glen@chromium.org2009-05-091-0/+1
| | | | | | | | | | | | This CL is paired with http://codereview.chromium.org/67284 This CL (for commit purposes) includes http://codereview.chromium.org/67284 BUG=4463,11232,11233,11234,11235 Review URL: http://codereview.chromium.org/99030 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15704 0039d316-1c4b-4281-b951-d872f2087c98
* Pass external tab handle when Chrome sends outgoing notifications through ↵stoyan@chromium.org2009-05-081-0/+6
| | | | | | | | automation interface. Review URL: http://codereview.chromium.org/115134 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15663 0039d316-1c4b-4281-b951-d872f2087c98
* Move src/chrome/views to src/views. RS=darin http://crbug.com/11387ben@chromium.org2009-05-081-3/+3
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15604 0039d316-1c4b-4281-b951-d872f2087c98
* Destroy browser/content related C++ object on WM_DESTROY message, rather ↵stoyan@chromium.org2009-05-061-1/+2
| | | | | | | | than OnFinalMessage Review URL: http://codereview.chromium.org/115034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15434 0039d316-1c4b-4281-b951-d872f2087c98
* Replace all occurrances of WebContents with TabContents.brettw@chromium.org2009-05-041-3/+3
| | | | | | Review URL: http://codereview.chromium.org/99177 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15194 0039d316-1c4b-4281-b951-d872f2087c98
* Allowing the client to handle escape and keyup events.tommi@google.com2009-05-021-2/+2
| | | | | | Review URL: http://codereview.chromium.org/99293 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15142 0039d316-1c4b-4281-b951-d872f2087c98
* Two changes:sky@chromium.org2009-04-291-1/+0
| | | | | | | | | | | | . Removes MoveToFront on Widget. . CHanges AsWindow to GetWindow. BUG=none TEST=none Review URL: http://codereview.chromium.org/99133 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14868 0039d316-1c4b-4281-b951-d872f2087c98
* Implement tabs.createWindow extension api call. Required: (a) new ↵rafaelw@chromium.org2009-04-281-0/+5
| | | | | | | | | | | RVHDelegate & TabContentsDelegate method(s) CreateExtensionFunctionDispatcher() so that the dispatcher could be created with (an optional) browser attached to it, while avoiding having render_host depend on browser.h BUG=11092: R=aa,mpComplete,darin,pkasting Review URL: http://codereview.chromium.org/79070 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14710 0039d316-1c4b-4281-b951-d872f2087c98
* Provide a way for a TabContentsDelegate to take focus when we receive a ↵ananta@chromium.org2009-04-231-2/+2
| | | | | | | | | | notification from the renderer that it is done cycling through the controls on the page. Review URL: http://codereview.chromium.org/93001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14363 0039d316-1c4b-4281-b951-d872f2087c98
* Remove TabContnetsType from everywhere.brettw@chromium.org2009-04-151-1/+0
| | | | | | | | I also removed the notion of the "active" tab contents since there is only one per tab now, and all the messages to replace them. Review URL: http://codereview.chromium.org/67173 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13808 0039d316-1c4b-4281-b951-d872f2087c98
* Make the omnibox popup look nicer. Add dropshadow images (not final). ↵ben@chromium.org2009-04-151-3/+3
| | | | | | | | | | | | Experiment with some effects. Adds a positioner interface that allows the popup to size itself to the width of the edit view + the width of the star and go buttons. (Basically the toolbar needs to help the popup position itself). No results yet! Review URL: http://codereview.chromium.org/68011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13784 0039d316-1c4b-4281-b951-d872f2087c98
* Make the RenderViewHostFactory a global. This prevents us from having to passbrettw@chromium.org2009-04-071-4/+5
| | | | | | | | | a factory pointer around all the time. Removing TestTabContents will require making the Browser object keep track of the Factory pointer as well, so I think the global is the best approach and cleans some things up. Review URL: http://codereview.chromium.org/62044 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13255 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-19 15:29:19 +0000