summaryrefslogtreecommitdiffstats
path: root/chrome/renderer/render_widget.h
Commit message (Collapse)AuthorAgeFilesLines
* Move native_widget_types and gtk_native_view_id_manager from base/gfx tobrettw@chromium.org2009-10-111-1/+2
| | | | | | | | | | | | app/gfx in preparation for removing the base_gfx project. This also moves base/window_impl.cc to app/win/window_impl because this file shouldn't be in base. TEST=none BUG=none Review URL: http://codereview.chromium.org/273017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28691 0039d316-1c4b-4281-b951-d872f2087c98
* Eliminate WebView::GetDelegate and replace RenderViewSet with a map fromdarin@chromium.org2009-10-091-1/+1
| | | | | | | | | | | | WebView to RenderView. R=mpcomplete BUG=10033 TEST=none Review URL: http://codereview.chromium.org/265044 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28515 0039d316-1c4b-4281-b951-d872f2087c98
* Supports Gtk keyboard themes.suzhe@chromium.org2009-09-101-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | This CL fixes issue 11480: Support GTK keyboard themes (emacs keybindings). A new class GtkKeyBindingsHandler has been added, which matches a key event against key bindings defined in current Gtk keyboard theme. A new render message ViewMsg_SetEditCommandsForNextKeyEvent has been added for sending edit commands associated to a key event to renderer. This message shall be sent just before sending the key event. RenderView will handle this event and cache the edit commands until the key event is processed. When processing the key event, EditClientImpl::handleKeyboardEvent() will eventually be called to handle the key event, if it's not handled by DOM and the focus is inside an input box. Then a newly added method WebViewDelegate::ExecuteEditCommandsForCurrentKeyEvent(), which is implemented in RenderView, will be called by EditClientImpl::handleKeyboardEvent() to execute edit commands previously sent from browser by ViewMsg_SetEditCommandsForNextKeyEvent message. If WebViewDelegate::ExecuteEditCommandsForCurrentKeyEvent() returns false, which means the key event doesn't have edit command associated, EditClientImpl will handle the key event with built-in logic, which may trigger a built-in key binding. With this approach, system defined key bindings always have higher priority than built-in key bindings defined in editor_client_impl.cc. Known issue: If a key event matches not only a system defined key binding but also an accesskey of a DOM element, then both corresponding edit commands and accesskey action will be executed. Because accesskey is handled in WebViewImpl::CharEvent(), while edit commands are bound to RawKeyDown or KeyUp events. BUG=11480 "Support GTK keyboard themes (emacs keybindings)" TEST=Switch to Emacs keyboard theme by changing the value of gconf key "/desktop/gnome/interface/gtk_key_theme" to "Emacs", then starts chrome and opens a webpage with a text input box. Input something into the text box, then press any of the Emacs key bindings defined in /usr/share/themes/Emacs/gtk-2.0-key/gtkrc, to see if it works as expected. For example, ctrl-p should move the cursor up one line, and ctrl-k should delete to the end of paragraph. Review URL: http://codereview.chromium.org/165293 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25852 0039d316-1c4b-4281-b951-d872f2087c98
* Eliminate remaining WebCore dependencies from webplugin_impl.ccdarin@chromium.org2009-09-021-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduces WebPluginPageDelegate to hold the methods that only existed on WebViewDelegate to allow WebPluginImpl to talk to the RenderView. This enables us to eliminate those methods from WebViewDelegate, which eliminates the last dependency on gfx/ native_widget_types.h in our WebKit interface! WebViewDelegate grows a CreatePlugin method that returns a WebKit::WebPlugin. It loses its CreatePluginDelegate method, which now lives on WebPluginPageDelegate. This change makes RenderView use WeakPtr when it hands itself to each WebPluginDelegateProxy and WebPluginImpl instance. This makes the memory management simpler. This change also moves various WebPlugin* interfaces defined in webkit/glue into the webkit_glue namespace. This was to help reduce confusion with similarly named types in the WebKit namespace. WebKit::WebPluginParams is added to contain the set of parameters used to construct a plugin. WebPluginContainer gets a couple more methods to allow us to avoid WebCore dependencies in WebPluginImpl. R=jam BUG=10036 TEST=none Review URL: http://codereview.chromium.org/181014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25184 0039d316-1c4b-4281-b951-d872f2087c98
* Reduce the size of the paint queue.agl@chromium.org2009-09-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (Sheriffs: warning, dangerous patch) On Chronos, with the slower CPU, it appears that page scrolling sigificantly lags the mouse cursor sometimes. Some amount of lag will always happen, but it appears that we are queuing old mouse positions. This patch makes it so that we don't ACK a mouse move event if there is a resulting paint pending. Current we get something like this: Renderer: Browser: <------- HandleInputEvent -------- (handles the event and defers the painting) -------- ACK -------------------> (has a mouse move saved up) ... HandleInputEvent --------- (painting starts) ----------- PaintRect -------------> <----... At this point, we buffered a mouse position while painting. If we don't ACK the event until we have finished painting, we can get a more up-to-date event. This will need careful observation of the perf bots to check that nothing bad happens. http://codereview.chromium.org/173285 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25059 0039d316-1c4b-4281-b951-d872f2087c98
* Relanding with v8 fix.mbelshe@google.com2009-08-261-0/+5
| | | | | | | | | | | | | | | Modify the RenderThread to track the number of widgets and "hidden widgets" which are running through that thread. By knowing the if the widgets are all hidden, the thread can accurately inform V8 when it is idle so that V8 can better cleanup unused memory when idle. BUG=none TEST=none Review URL: http://codereview.chromium.org/173466 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24448 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 24314 - Modify the RenderThread to track the number of widgetsmbelshe@google.com2009-08-251-5/+0
| | | | | | | | | | | | | | | | | | | | | | | and "hidden widgets" which are running through that thread. By knowing the if the widgets are all hidden, the thread can accurately inform V8 when it is idle so that V8 can better cleanup unused memory when idle. This time if V8 has been killed for some reason, don't call into it. BUG=none TEST=none Review URL: http://codereview.chromium.org/173379 TBR=mbelshe@google.com Review URL: http://codereview.chromium.org/174458 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24339 0039d316-1c4b-4281-b951-d872f2087c98
* Modify the RenderThread to track the number of widgetsmbelshe@google.com2009-08-251-0/+5
| | | | | | | | | | | | | | | | | | | and "hidden widgets" which are running through that thread. By knowing the if the widgets are all hidden, the thread can accurately inform V8 when it is idle so that V8 can better cleanup unused memory when idle. This time - if V8 has been killed for some reason, don't call into it. BUG=none TEST=none Review URL: http://codereview.chromium.org/173379 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24314 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 24227 - Modify the RenderThread to track the number of widgetsnick@chromium.org2009-08-251-5/+0
| | | | | | | | | | | | | | | | | | | and "hidden widgets" which are running through that thread. By knowing the if the widgets are all hidden, the thread can accurately inform V8 when it is idle so that V8 can better cleanup unused memory when idle. BUG=none TEST=none Review URL: http://codereview.chromium.org/174303 TBR=mbelshe@google.com Review URL: http://codereview.chromium.org/174417 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24270 0039d316-1c4b-4281-b951-d872f2087c98
* Modify the RenderThread to track the number of widgetsmbelshe@google.com2009-08-251-0/+5
| | | | | | | | | | | | | | | and "hidden widgets" which are running through that thread. By knowing the if the widgets are all hidden, the thread can accurately inform V8 when it is idle so that V8 can better cleanup unused memory when idle. BUG=none TEST=none Review URL: http://codereview.chromium.org/174303 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24227 0039d316-1c4b-4281-b951-d872f2087c98
* Address bug 12392 by only updating the PRIMARY selection if we are currentlyestade@chromium.org2009-08-131-0/+3
| | | | | | | | | | | | | | handling an InputEvent BUG=12392 TEST=navigate to facebook.com, PRIMARY selection should not contain "Email" afterward patch by Steve VanDeBogart <vandebo [at] google> original review: http://codereview.chromium.org/165471 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23387 0039d316-1c4b-4281-b951-d872f2087c98
* When the plugin crashes, cleanup references to its window in the renderer.piman@chromium.org2009-08-061-1/+6
| | | | | | | | | This avoids spurious messages when the plugin crashes, and potential issues (plugin crashes, the HWND/XID gets destroyed, a new one gets created by a new instance and gets the same HWND/XID, the browser operates on the new one instead of the old one). Review URL: http://codereview.chromium.org/160614 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22688 0039d316-1c4b-4281-b951-d872f2087c98
* Split the IPC code into ipc/agl@chromium.org2009-07-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This splits the ipc code from the common project. The 'common' project pulls in all of webkit, the v8 bindings, skia, googleurl, and a number of other projects which makes it very difficult to deal with especially for external projects wanting just to use some of Chromium's infrastructure. This puts the ipc code into its top-level ipc/ directory with a dependency only on base. The common project depends on the new ipc/ipc.gyp:ipc target so that all projects currently pulling common in to get the IPC code still have it available. This mostly follows agl's pre-gyp attempt to do this which was r13062. Known issues: - Currently a number of projects depend on chrome/chrome.gyp:common in order to use the IPC infrastructure. Rather than fixing all of these dependencies I have made common depend on ipc/ipc.gyp:ipc and added "ipc" to the include_rules section of DEPS so that checkdeps.py doesn't complain. Over time projects that need IPC should depend on the IPC project themselves and dependencies on common removed, although I don't think many projects that need IPC will be able to get away without common currently. - ipc/ipc_message_macros.h still has #include "chrome/common/..." inside of a ipc/ should not refer to files in chrome/... now. I'm not sure how to resolve this since it's really an IDE bug - the named pipe name (windows+linux) and the logging event name (all) + env variable (posix) refer explicitly to 'Chrome' which somewhat hurts the illusion of ipc/ being an independent library. I think this should be examined in a subsequent, much smaller patch. - I've eliminated the IPC.SendMsgCount counter since it was implemented in a way to create a dependency from ipc/ to chrome/common/chrome_counters. This is the same approach that r13062 took. http://codereview.chromium.org/155905 (Patch from James Robinson) git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21342 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 20855.darin@chromium.org2009-07-161-29/+28
| | | | | | Review URL: http://codereview.chromium.org/149744 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20859 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 20854.darin@chromium.org2009-07-161-28/+29
| | | | | | Review URL: http://codereview.chromium.org/155621 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20855 0039d316-1c4b-4281-b951-d872f2087c98
* Use WebWidget from the WebKit API. This change also makesdarin@chromium.org2009-07-161-29/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | use of WebKitClient (replacing WebWidgetDelegate from glue). The ripple effects of this change are rather large, but most of the impact is mechanical. The more interesting changes include: 1- Removing the WebWidget parameter from WebWidgetClient methods. This didn't matter at all to RenderWidget or RenderView, but it did cause some changes to be made to TestWebViewDelegate. Now, it is not possible to share a delegate implementation for both the WebView and a popup menu, so I have a second instance of the delegate owned by TestShell for use with popup menus. 2- Plumbing WebNavigationPolicy in place of WindowOpenDisposition was getting to be a pretty large change, so I stopped short of deleting WindowOpenDisposition. That way the Chrome side can remain mostly unmodified. I then added a mapping function to convert from WebNavigationPolicy to WindowOpenDisposition. 3- The IME methods on WebWidget were renamed (reviewed separately by hbono), and there is now an enum to specify the composition command (WebCompositionCommand). 4- I added IPC serialization for WebCompositionCommand and WebTextDirection, which cleaned up some code that was just using ints in IPC messages. R=jam BUG=16234 TEST=none Review URL: http://codereview.chromium.org/149620 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20854 0039d316-1c4b-4281-b951-d872f2087c98
* Replace ShowAsPopupWithItems to CreatePopupWidgetWithInfo. Also,darin@chromium.org2009-07-141-5/+12
| | | | | | | | | | | | | | | | | | make use of WebPopupMenuInfo from the WebKit API. WebMenuItem remains in webkit/glue for convenience with IPC marshalling and related usage in Chrome. This work is precursor to switching over to using WebWidget from the WebKit API. BUG=16234 TEST=html select drop downs should still work on the mac. try switching languages on news.google.com. R=paul Review URL: http://codereview.chromium.org/155378 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20624 0039d316-1c4b-4281-b951-d872f2087c98
* Remove reference counting from WebWidgetDelegate.darin@chromium.org2009-07-091-8/+0
| | | | | | | | | | | | | | | | | This was added as a speculative crash fix by eseidel back in June of 2008. See http://b/1211911 for details. It didn't appear to resolve the crash then (as another patch was required to fix the bug), and it doesn't seem to be necessary since the RenderView, which is the delegate and owns the WebView, is the one in charge of allocating the WebView and destroying the WebView. So, it is not possible for the WebView to outlive the RenderView. BUG=16234 TEST=none R=brettw Review URL: http://codereview.chromium.org/155292 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20294 0039d316-1c4b-4281-b951-d872f2087c98
* Remove WebWidgetDelegate::GetContainingView since it is not needed.darin@chromium.org2009-07-091-1/+0
| | | | | | | | | | TEST=none BUG=16234 R=jam Review URL: http://codereview.chromium.org/155243 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20213 0039d316-1c4b-4281-b951-d872f2087c98
* Start using WebCursorInfo from the WebKit API. WebCursorInfo is adarin@google.com2009-07-081-1/+2
| | | | | | | | | | | | | | | | lightweight struct containing a description of a cursor that the embedder should render. WebCursor still exists. Instead of WebCursor initializing from a PlatformCursor, it now initializes from a WebCursorInfo. TEST=none BUG=10039 R=jam Review URL: http://codereview.chromium.org/155172 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20194 0039d316-1c4b-4281-b951-d872f2087c98
* Fix for reverted cl http://codereview.chromium.org/147123davemoore@chromium.org2009-06-271-0/+4
| | | | | | | | | | | | | A recent change broke the load times. It also revealed some deficiencies. This adds a new time marker for when a load is committed, which is a more interesting value than the start of the load (which we still keep). Also, the first layout time wasn't an interesting time to keep, instead we keep the time of the first paint. The histograms were modified to use the new values when appropriate. Review URL: http://codereview.chromium.org/149099 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19465 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 19361.davemoore@chromium.org2009-06-261-4/+0
| | | | | | | tbr=darin Review URL: http://codereview.chromium.org/149081 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19368 0039d316-1c4b-4281-b951-d872f2087c98
* A recent change broke the load times. It also revealed some deficiencies.davemoore@chromium.org2009-06-261-0/+4
| | | | | | | | | | | | This adds a new time marker for when a load is committed, which is a more interesting value than the start of the load (which we still keep). Also, the first layout time wasn't an interesting time to keep, instead we keep the time of the first paint. The histograms were modified to use the new values when appropriate. Review URL: http://codereview.chromium.org/147123 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19361 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 18765 to try to repair perf regressionjar@chromium.org2009-06-191-1/+1
| | | | | | | TBR=mpcomplete Review URL: http://codereview.chromium.org/131093 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18784 0039d316-1c4b-4281-b951-d872f2087c98
* Send port-closed notification when a frame with ports unloads.mpcomplete@google.com2009-06-181-1/+1
| | | | | | | | | | | | | Also add onLoad and onUnload chrome Event to our bindings, so we can add listeners to these events without needing a DOM. These don't hook into the window "unload" event, so we no longer prevent Chrome's sudden termination of tabs on shutdown. BUG=12686 TEST=no Review URL: http://codereview.chromium.org/125280 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18765 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting Rev 18383 since it brings down the performance of single core page ↵mad@chromium.org2009-06-151-4/+1
| | | | | | cyclers too much... git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18385 0039d316-1c4b-4281-b951-d872f2087c98
* This is to thest the page cycler performance without the resize corner, to ↵mad@chromium.org2009-06-151-1/+4
| | | | | | | | | | | | | see if these paint optimizations are worth it. I will revert these changes as needed... You may revert them yourself if they cause you trouble before I get to revert them. I have tested these changes on two different linux configuration, but there are more code paths that I couldn't verify myself, though agl gave me the OK anyway. These changes have already been reviewed here: http://codereview.chromium.org/108040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18383 0039d316-1c4b-4281-b951-d872f2087c98
* Revert mad's backing store changes, it completely hosed Linux painting.deanm@chromium.org2009-06-111-4/+1
| | | | | | | | | This was r18090, reverted in r18092, recommitted without review in 18130. Review URL: http://codereview.chromium.org/122034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18158 0039d316-1c4b-4281-b951-d872f2087c98
* Relanding reverted patch 18090.mad@google.com2009-06-111-1/+4
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18130 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 18090jrg@chromium.org2009-06-101-4/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18092 0039d316-1c4b-4281-b951-d872f2087c98
* To help resolve the performance issue introduced when enabling the resize ↵mad@google.com2009-06-101-1/+4
| | | | | | | | corner, we now keep all non-intersecting rects separately and send an array of invalidation bitmaps via IPC as opposed to a single unionized rect :-) Review URL: http://codereview.chromium.org/108040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18090 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes a flash plugin hang caused by opening google finance ticker symbols in ↵ananta@chromium.org2009-06-091-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | a background tab. From what I can tell this bug always existed in Chrome. The flash plugin gets instantiated and gets initial geometry updates during initialization. We download the plugin url after the geometry update. After these geometry updates the webkit layout timer runs and the plugin gets additional geometry updates. However these don't get sent over to the flash plugin instance in the plugin process as the geometry updates for windowed plugins are only flushed during paint, which does not happen in this case. The flash plugin ends up receiving data before geometry update and ends up behaving in a wierd fashion, i.e. not peeking for messages, etc. The fact that this is a windowed plugin results in the browser ui thread also getting hung until the plugin gets out of this state. The fix for the geometry update issue is to remove the deferred geometry update stuff. This only exists for windowed plugins anyway. The geometry update IPC is a plain routed message and it should not be a big overhead to send these IPCs to the plugin process. I found that while this change fixes the basic issue, we still see some hangs in the flash plugin because of it receiving data before the valid geometry update kicks in. John is working on a fix where we never have to call setFrameRect ourselves and always honor the setFrameRect calls made by Webkit. This issue can be marked as fixed once both fixes get checked in. This fixes http://code.google.com/p/chromium/issues/detail?id=12993 Bug=12993 TEST=Open google finance and Ctrl Click on the tickers in the page like Basic Materials, etc. Review URL: http://codereview.chromium.org/119200 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17918 0039d316-1c4b-4281-b951-d872f2087c98
* This CL updates chrome to the latest version of skia, retrieved via DEPS, andsenorblanco@chromium.org2009-05-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | placed in third_party. All relevant skia changes (for all 3 platforms) have been upstreamed. Most of this CL is mind-numbingly repetitive. Things of interest are: skia.gyp (now points at third_party versions), DEPS, and SkUserConfig.h. stdint.h: Skia now requires C99 integer types, which MSVC doesn't support natively. I have put typedefs in config/win/stdint.h. Note that the new version of skia appears to render rects whose coordinates are "backwards" (ie., x2 < x1 or y2 < y1), which were formerly culled. There were a couple obvious instances of this in the code which I fixed, but there may be more. There were ~35 layout test failures due to minor pixel differences which I rebaselined on Windows and Linux, and 8 genuine failures related to masks and stroked text, which I have put in text_expectations.txt and assigned to myself. (There was another change which broke ~1700 tests on each platform, but I put that change behind an #ifdef for now). R=brettw Review URL: http://codereview.chromium.org/65012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15949 0039d316-1c4b-4281-b951-d872f2087c98
* Move WebKit API to src/webkit/api.darin@chromium.org2009-05-101-1/+1
| | | | | | | | R=dglazkov Review URL: http://codereview.chromium.org/113186 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15739 0039d316-1c4b-4281-b951-d872f2087c98
* Defer window.close(), resizeTo() and moveTo() actionsmbelshe@google.com2009-05-091-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | by posting a task back to the message loop before notifying the RenderWidgetHost to perform these operations. Otherwise the JS code races with the browser to use the modified window. BUG=http://crbug.com/6377 BUG=http://crbug.com/6192 Cache a pending_window_rect on the render_view (moved from prior CL where I had it on the chrome_client_impl). This is a short lived cache, and not a complete solution. It fixes this case, where a JS script makes multiple operations and expects the GetWindowSize() to be correct immedately after having called SetWindowSize(). BUG=http://crbug.com/835 Review URL: http://codereview.chromium.org/115030 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15698 0039d316-1c4b-4281-b951-d872f2087c98
* Revert bug fix because interactive_ui_tests are failing.mbelshe@google.com2009-05-041-6/+0
| | | | | | Review URL: http://codereview.chromium.org/99358 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15227 0039d316-1c4b-4281-b951-d872f2087c98
* Defer window.close(), window.resizeTo(), and window.moveTo()mbelshe@google.com2009-05-041-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | actions by posting a task back to the message loop before notifying the RenderWidgetHost to perform these operations. Otherwise, the JS code races with the browser to use the modified window. BUG=http://crbug.com/6377 BUG=http://crbug.com/6192 Also, because window resizing is asynchronous between the renderer and browser, added a renderer-side cache of "pending window rect" to ChromeClientImpl. Before the change, calling setWindowRect() would schedule a call to the RenderViewHost to do the work, but a subsequent call to windowRect() would return the current size, as through the call to setWindowRect() had never happened. We cache a pending size and then schedule a task on the message loop to clear the cached size. This allows javascript which writes and reads the WindowRect sizes to work, and once we come out of JS and return to the message loop, we'll go back to asking the RenderViewHost for the true values. This pending_window_size is my only concern about this patch. It does pass all layout tests, and the ChromeClientImpl code is executed in the test_shell.exe code path. BUG=http://crbug.com/835 TEST=LayoutTests have tests which cover all of these actions. The problem is that we run layout tests using the test_shell, not Chrome. Review URL: http://codereview.chromium.org/101019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15214 0039d316-1c4b-4281-b951-d872f2087c98
* Add transparency support to RenderWidgetHostView.aa@chromium.org2009-04-231-0/+9
| | | | | | | | | | | | This is used to make the background behind toolstrips 'shine through' them. It isn't possible to make them really transparent due to cleartype (cleartype must know the pixels behind the text to work), so instead we paint the background we want behind the transparent webview. Review URL: http://codereview.chromium.org/88076 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14378 0039d316-1c4b-4281-b951-d872f2087c98
* DevTools: Run nested message loop instead of whitelisting the messages.pfeldman@chromium.org2009-04-221-0/+3
| | | | | | Review URL: http://codereview.chromium.org/90007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14183 0039d316-1c4b-4281-b951-d872f2087c98
* Chrome side of the WebKit popup changes.paulg@google.com2009-04-101-6/+6
| | | | | | | | | | | Implements HTML select popups on Mac OS X as native Cocoa controls. BUG=5095 (http://crbug.com/5095) Review URL: http://codereview.chromium.org/67018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13495 0039d316-1c4b-4281-b951-d872f2087c98
* Switch to using WebPoint, WebRect, and WebSize in more of the gluedarin@chromium.org2009-04-091-7/+10
| | | | | | | | | | | | | | | | | layer interface. This will help when we move those interfaces into the WebKit API. This is a second attempt at r13381, which was already reviewed here: http://codereview.chromium.org/63126 The only change between that CL and this one is in render_view.h, where I needed to change a parameter type from gfx::Rect to WebRect. TBR=dglazkov Review URL: http://codereview.chromium.org/64005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13424 0039d316-1c4b-4281-b951-d872f2087c98
* When the Find bar has focus it eats keypresses such as PageUp, PageDown and ↵finnur@chromium.org2009-04-081-5/+5
| | | | | | | | | | | | | | | Up and Down arrow keys. It doesn't need to - instead the page should scroll even if focus is on the Find bar. This patch forwards those selected keypresses to the page for its perusal. Known issues: Just like Firefox, the page doesn't scroll if it has frames. SONG=I like to fixit fixit. I like to fixit fixit. BUG=7079 TEST=Open FindInPage on a webpage that has a vertical scrollbar. Press Down, Up, PageDown and PageUp and the page should scroll accordingly. Make sure no ding is heard while doing so. Also make sure this works if focus is on a textfield/textarea when you press Ctrl+F. Review URL: http://codereview.chromium.org/62129 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13389 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting dfisher changes 133386 and 13381cpu@google.com2009-04-081-10/+7
| | | | | | | | | | TBR=darin Review URL: http://codereview.chromium.org/58018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13387 0039d316-1c4b-4281-b951-d872f2087c98
* Switch to using WebPoint, WebRect, and WebSize in more of the gluedarin@chromium.org2009-04-081-7/+10
| | | | | | | | | | | layer interface. This will help when we move those interfaces into the WebKit API. R=dglazkov Review URL: http://codereview.chromium.org/63126 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13381 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "Move IPC code to ipc/"agl@chromium.org2009-04-031-1/+1
| | | | | | | This reverts commit r13062 which, unsurprisingly, broke the build. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13063 0039d316-1c4b-4281-b951-d872f2087c98
* Move IPC code to ipc/agl@chromium.org2009-04-031-1/+1
| | | | | | | (No review URL: Rietvelt couldn't cope) git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13062 0039d316-1c4b-4281-b951-d872f2087c98
* Replace webkit/glue/screen_info.h with WebKit/chromium/public/WebScreenInfo.hdarin@chromium.org2009-04-011-6/+7
| | | | | | | | | | | | | This also eliminates webkit_glue::GetScreenInfo and webkit_glue::GetScreenInfoHelper. As part of this CL, I also extracted all of the ParamTraits for WebKit API types into chrome/common/webkit_param_traits.h. R=dglazkov Review URL: http://codereview.chromium.org/58008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12993 0039d316-1c4b-4281-b951-d872f2087c98
* A tricky fix for Issue 1845 (Take 2).hbono@chromium.org2009-03-251-0/+1
| | | | | | | | | | This is almost the same change as <http://codereview.chromium.org/39252/show>, which caused a build break on a Linux buildbot while compiling my new template function in "chrome/common/render_messages.h". Even though I was not able to reproduce the build errors on my Linux box, I removed this function and use the int type in my IPC message 'ViewMsg_SetTextDirection'. BUG=1845 Review URL: http://codereview.chromium.org/42495 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12434 0039d316-1c4b-4281-b951-d872f2087c98
* First stage of implementing HTML select popup menus forpaulg@google.com2009-03-241-0/+5
| | | | | | | | | | | | | | | | the Mac test_shell. Once the changes to WebKit/WebCore/platform/chromium/PopupMenuChromium* have been upstreamed (then landed in our tree), we can enable them in test_shell. The WebKit part is contained in this bug: https://bugs.webkit.org/show_bug.cgi?id=24692 BUG=5095 (http://crbug.com/5095) Review URL: http://codereview.chromium.org/48149 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12382 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 11953.hbono@chromium.org2009-03-181-2/+0
| | | | | | Review URL: http://codereview.chromium.org/48121 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11954 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-19 08:38:29 +0000