summaryrefslogtreecommitdiffstats
path: root/chrome/renderer/render_widget.cc
Commit message (Collapse)AuthorAgeFilesLines
* Implement HTML selects as native Cocoa controls for Chrome.paul@chromium.org2009-04-241-3/+8
| | | | | | | | BUG=8389 (http://crbug.com/8389) Review URL: http://codereview.chromium.org/57032 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14471 0039d316-1c4b-4281-b951-d872f2087c98
* Add transparency support to RenderWidgetHostView.aa@chromium.org2009-04-231-0/+26
| | | | | | | | | | | | 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/+4
| | | | | | 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-5/+5
| | | | | | | | | | | 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-16/+24
| | | | | | | | | | | | | | | | | 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-1/+1
| | | | | | | | | | | | | | | 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-24/+16
| | | | | | | | | | 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-16/+24
| | | | | | | | | | | 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
* Replace webkit/glue/screen_info.h with WebKit/chromium/public/WebScreenInfo.hdarin@chromium.org2009-04-011-0/+9
| | | | | | | | | | | | | 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
* Use Webkit::WebInputEvent and remove webkit/glue/webinputevent.darin@chromium.org2009-03-271-1/+2
| | | | | | | | | | This change adds a temporary dependency on src/KeyIdentifier.{h,cpp} which I am going to remove after this CL. I didn't want to grow this CL any larger. R=dglazkov Review URL: http://codereview.chromium.org/53099 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12728 0039d316-1c4b-4281-b951-d872f2087c98
* A tricky fix for Issue 1845 (Take 2).hbono@chromium.org2009-03-251-0/+16
| | | | | | | | | | 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/+9
| | | | | | | | | | | | | | | | 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-8/+0
| | | | | | Review URL: http://codereview.chromium.org/48121 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11954 0039d316-1c4b-4281-b951-d872f2087c98
* A tricky fix for Issue 1845.hbono@chromium.org2009-03-181-0/+8
| | | | | | | | | | | | | | | | | This change is a very tricky fix for Issue 1845 in chromium: cant alignt text to the right using right shift and right ctrl.This change consists of two parts listed below. 1. Emulating the implementation of Safari that changes the text-direction of an input element. Safari uses context menus to change the text direction. This change adds an IPC message 'ViewMsg_SetTextDirection', which notifies the new text direction. Also, it adds two functions: RenderWidgetHost::UpdateTextDirection() and RenderWidgetHost::NotifyTextDirection(). They encapsulate the new IPC message so that we can use them both when we presses a set of keys and when we add context-menu items which change the text direction. 2. Calling the above interface when pressing right-shift and right-control keys, or when left-shift and left-control keys. This modifies the RenderWidgetHostViewWin::OnKeyEvent() function and call the above text-direction interfaces when a user finishes pressing the keys. As you can imagine, if we send an IPC message every time when we receive a WM_KEYDOWN event, we continue sending IPC messages while a user is pressing the keys. BUG=1845 Review URL: http://codereview.chromium.org/39252 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11953 0039d316-1c4b-4281-b951-d872f2087c98
* NO CODE CHANGE.maruel@google.com2009-03-101-2/+4
| | | | | | | Fix files with lines > 80 cols. Part 2. Review URL: http://codereview.chromium.org/40226 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11326 0039d316-1c4b-4281-b951-d872f2087c98
* We don't support beeing scrolled in two dimensions at a time.mad@chromium.org2009-02-271-10/+5
| | | | | | | | | | | This can happen when zooming on an image as identified in related bug. So we split it in two phases. BUG=5873 Review URL: http://codereview.chromium.org/27064 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10568 0039d316-1c4b-4281-b951-d872f2087c98
* Don't send WebInputEvents from the renderer to the browser.erg@google.com2009-02-271-4/+2
| | | | | | | | | | The browser process now keeps a queue of the last keyboard events that it sent to the renderer in a queue and pops them on ACK. If a key is unhandled, we use the copy in the browser process; we don't even send the key back in the ACK anymore. Review URL: http://codereview.chromium.org/27244 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10563 0039d316-1c4b-4281-b951-d872f2087c98
* Delete the ViewSourceTabContents.brettw@chromium.org2009-02-251-1/+1
| | | | | | | | | | | | | This removes all the tab contents type stuff for view source mode. The RenderViewHostManager now automatically switches RenderViews when we turn view source mode on or off to get the desired effect. I also moved some instances of hardcoded schemes into chrome_constants.h, and renamed RendererCreated/Ready/Gone to RenderViewCreated/Ready/Gone to reflect what they actually mean. Review URL: http://codereview.chromium.org/28089 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10346 0039d316-1c4b-4281-b951-d872f2087c98
* Keeping track of whether WebKit is in the callstack using RenderThread ↵jam@chromium.org2009-02-241-75/+8
| | | | | | | | | | | | doesn't work when there are Send calls to plugins (i.e. Gears). So instead, just use PostNonNestableTask to delete RenderWidget. I (Note I still don't know how my change affected this, it seems to have been broken before as well.) BUG=7951 Review URL: http://codereview.chromium.org/28090 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10298 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor code from RenderThread and PluginThread and move it to ChildThread. ↵jam@chromium.org2009-02-211-8/+8
| | | | | | | | | | | ChildProcess now owns the ChildThread, which removes duplicate code and simplifies things. Clean up ChildProcess, there really was no need for all the templates and statics in it and its subclasses. Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=10080 Review URL: http://codereview.chromium.org/21502 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10144 0039d316-1c4b-4281-b951-d872f2087c98
* Remove unused 'node' parameter from ImeUpdateStatus.darin@chromium.org2009-02-201-2/+1
| | | | | | | | R=hbono Review URL: http://codereview.chromium.org/21531 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10096 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 10080.jam@chromium.org2009-02-201-8/+8
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10082 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor code from RenderThread and PluginThread and move it to ChildThread. ↵jam@chromium.org2009-02-201-8/+8
| | | | | | | | | ChildProcess now owns the ChildThread, which removes duplicate code and simplifies things. Clean up ChildProcess, there really was no need for all the templates and statics in it and its subclasses. Review URL: http://codereview.chromium.org/21502 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10080 0039d316-1c4b-4281-b951-d872f2087c98
* Bitmap transportagl@chromium.org2009-02-201-55/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch reworks bitmap transport on all platforms. Linux and Mac are switched from serialising bitmaps over the IPC channel to using shared memory. All platforms gain a shared memory mapping cache on the host side. The concept of a TransportDIB (device independent bitmap) is added to encapsulate most of the platform specifics. On Linux, we use SysV shared memory. This is because X shared pixmaps, which predate POSIX SHM, can only use SysV. By using SysV between renderer and browser, we open up the possibility to map the shared memory directly from the renderer to the X server. On Mac, we use POSIX shared memory. However, since this needs filesystem access and the Mac renderer is sandboxed from the filesystem, we add two new messages from renderer -> browser: The first, AllocTransportDIB, synchronously creates a transport DIB in the browser and passes a handle back to the renderer. The second, FreeTransportDIB, asynchronously, notifies the browser that it may close its handle to the shared memory region. On Mac, the shared memory regions are identified by their inode numbers on the wire. This means that the browser must keep handles open to all the allocated shared memory regions (since an inode number is insufficient to map the region). The alternative design is that the renderer passes the file descriptor with each paint operation. Since passing file descriptors is special case in the code, I felt that it would be best to minimise their use. Creating and freeing transport DIBs are relatively rare operations relative to paints and scrolls. On Windows, most of the code remains the same, except that Windows now uses the mapping cache added in this patch. This allows the browser to maintain a shared memory mapping for a transport DIB over several paints. Previously it mapped and unmapped for every operation, causing lots of TLB and VM churn. Review URL: http://codereview.chromium.org/21485 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10071 0039d316-1c4b-4281-b951-d872f2087c98
* Hook up the resize rect for Mac and enable its use in the renderer (mac-only). pinkerton@chromium.org2009-02-191-0/+5
| | | | | | Review URL: http://codereview.chromium.org/21512 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10019 0039d316-1c4b-4281-b951-d872f2087c98
* The WebFrame interface currently supports reference counting, but no one uses.darin@chromium.org2009-02-131-3/+3
| | | | | | | | | | | | | | | | Internally, WebFrameImpl needs reference counting, so we still define it there. Same goes for WebView and WebWidget. While making this change, I noticed that WebInspectorClient was casting WebView pointers to WebViewImpl pointers too much. By just starting with WebViewImpl pointers, things could be cleaned up considerably. R=brettw Review URL: http://codereview.chromium.org/21342 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9745 0039d316-1c4b-4281-b951-d872f2087c98
* This is an attempt at finding the reason for the page_cycler slowness caused bymad@chromium.org2009-02-121-9/+9
| | | | | | | | | | | | | | | the new resize corner. Local experiment led me to believe that it is WebKit that is slower when we specify a resize corner area. To validate this hypothesis, I always return an empty rect to WebKit, but I still compute and push the rect to the render widget and I also draw the bitmap even if this will cause it to be drawn on top of the scroll bars when there is only one. TBR=brettw git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9654 0039d316-1c4b-4281-b951-d872f2087c98
* Implement browser scrolling on posix.estade@chromium.org2009-02-111-0/+2
| | | | | | | | This code still has not been tested on nested scroll frames (e.g. webkit/data/test_shell/iframes/test1.html) because they don't render correctly yet. But it does work for scrolling horizontally and vertically on the main frame. Review URL: http://codereview.chromium.org/20244 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9550 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 9493.kuchhal@chromium.org2009-02-101-6/+9
| | | | | | Review URL: http://codereview.chromium.org/21231 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9517 0039d316-1c4b-4281-b951-d872f2087c98
* Relanding of http://codereview.chromium.org/16488.mad@chromium.org2009-02-101-9/+6
| | | | | | | | Adding proper project dependency in chrome.sln. Review URL: http://codereview.chromium.org/21188 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9493 0039d316-1c4b-4281-b951-d872f2087c98
* Get the renderer closer to rendering something on linux.estade@chromium.org2009-02-101-0/+6
| | | | | | | | | | * implement some stubbed functions * comment out some unimplemented IPC calls * hack a webcontents widget into BrowserWindow so that something displays Review URL: http://codereview.chromium.org/20204 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9445 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 9408.brettw@chromium.org2009-02-091-6/+3
| | | | | | Review URL: http://codereview.chromium.org/20190 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9414 0039d316-1c4b-4281-b951-d872f2087c98
* Add a new resizer corner.mad@chromium.org2009-02-091-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To display a resize bitmap and handle the mouse interactions as requested in http://code.google.com/p/chromium/issues/detail?id=458. BUG=458 There are unfortunately two cases to handle and they must be handled separately. The first one is when there are no bottom shelf like the download bar, and the case where there is one. For the case without, we must draw on top of what we receive from WebKit, so we intercept the bitmap in RenderWidgetHostViewWin::OnPaint() so that we can draw the resize corner bitmap on top of it (taking into account whether we are in a right to left language or not). For the case where we have a bottom shelf, we use a dedicated view that we properly layout on top of the bottom shelf view (which takes care of handling the RTL language case for us). Same split for the mouse interactions. Without the bottom shelf, we must deal with it in RenderWidgetHostViewWin::OnMouseEvent() by sending the root window a WM_NCLBUTTONDOWN message with either HTBOTTOMRIGHT or HTBOTTOMLEFT (based on the RTL setting) and let the OS take care of the resizing. IF we have a bottom shelf, we must deal with the mouse interaction in BrowserView::NonClientHitTest() to either return HTBOTTOMRIGHT or HTBOTTOMLEFT (again, based on the RTL setting) and, again, let the OS take care of the resizing. More details here: http://code.google.com/p/chromium/wiki/BrowserViewResizer git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9408 0039d316-1c4b-4281-b951-d872f2087c98
* Commiting the changes from my previous cl that are specific to not including ↵jam@chromium.org2009-02-041-0/+21
| | | | | | | | | | render_messages.h/plugin_message.h unless necessary. TBR=mpcomplete Review URL: http://codereview.chromium.org/20059 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9189 0039d316-1c4b-4281-b951-d872f2087c98
* Revert my change to get the tree green. Not sure why the tests became ↵jam@chromium.org2009-02-041-21/+0
| | | | | | | | | | flaky. I'll try to check them in again but in smaller chunks tomorrow. TBR=mpcomplete Review URL: http://codereview.chromium.org/21039 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9132 0039d316-1c4b-4281-b951-d872f2087c98
* Make it easier/less work/less error-prone to create new IPC channel types ↵jam@chromium.org2009-02-041-0/+21
| | | | | | | | (i.e. renderer/plugin).Instead of having each message file include the internal one several times with different ifdefs, move that logic to ipc_message_macros.h. Also make the message class starting IDs come from an enum to ensure we don't use a value twice. I simplified the logging code a bit so we don't need X_messages.cc files.Clean up places that we were doing manual packing/unpacking. Most of this was in the automation code. I added a few new template functions to make it convenient to read the parameters from a message, and updated the code to use them.I also removed unnecessary includes of render/plugin_messages.h from headers to speed up compiling.I moved the traits of IPC structs beside the struct definition to make it more apparent what's going on, so we avoid people modifying the struct and forgetting to update the traits.Amit: please look at chrome/test/automation/tab_proxy.ccMarc-Antoine: chrome/browser/printing/*Matt: the rest Review URL: http://codereview.chromium.org/20015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9123 0039d316-1c4b-4281-b951-d872f2087c98
* From agl. Cleaned up version of issue 19046.thestig@chromium.org2009-02-031-14/+52
| | | | | | | | | | | | | POSIX: bitmap data on the wire On Windows, when drawing a given rect in the renderer, we allocate memory for the bitmap, render and send a shared memory handle across IPC. In the browser, we bitblit the shared memory to the backing store and draw it to the screen. In the long term, on Linux, we want the backingstore to be shared with both X and the renderer. The renderer then draws directly to that store, sends an IPC to the browser and the browser sends a message to X to bitblit to the display. Since only cache a few backing stores we'll need messages from the browser to tell the renderer to attach and detatch from shared memory regions as they get created and evicted. In the short term, however, to get something that works, we make a BitmapWireData typedef. This will be a shared memory region on Windows, as before, and on POSIX we'll be sending the bitmap data over the wire. Obviously this'll be pretty slow but it'll work sooner. Review URL: http://codereview.chromium.org/19491 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9065 0039d316-1c4b-4281-b951-d872f2087c98
* Remove most header file dependencies on the notification type list. It isbrettw@chromium.org2009-02-011-2/+0
| | | | | | | | | | | really painful to add more types, since lots of headers include the notification service to derive from the notification observer. This splits that out, so much less of the project should end up including notification_types.h ---Paths modified but not in any changelist: Review URL: http://codereview.chromium.org/19744 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9020 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a bunch of lint complaints in preparation to land issue 19046. Mostly ↵thestig@chromium.org2009-01-301-2/+3
| | | | | | | | formatting changes, i.e. CRLF, space at end of line. Review URL: http://codereview.chromium.org/19486 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8933 0039d316-1c4b-4281-b951-d872f2087c98
* POSIX: gfx::NativeViewId and CrossProcessEventagl@chromium.org2009-01-271-4/+3
| | | | | | | | | | | | | | | | | | | Create a couple new typedefs for porting work. Firstly, gfx::NativeViewId is a handle to a platform specific widget in the renderer process. For Windows, this is just a HWND as before. However, in other platforms the ids used in the renderer process will be something else. CrossProcessEvent is the type of a HANDLE to a Windows event object which is used across processes. Since we aren't going to support these sorts of events on non-Windows platforms, this will have to go away at some point. For now, however, this lets us build code without too many ifdefs all over the place. Review URL: http://codereview.chromium.org/18768 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8756 0039d316-1c4b-4281-b951-d872f2087c98
* The popup for autofill is now never activated, even when clicked.jcampan@chromium.org2009-01-091-6/+5
| | | | | | | | | | | | | This allows us to hide it when the page loses focus. (doing that previously would have caused the popup to be hidden before the click in the popup was sent to the renderer). Most of the file changes are just renaming focus_on_show to activatable. TEST=Open a form and make an autofill popup. Focus another window, the popup should disappear. Ensure the autofill still work properly, and the combo-box as well. BUG=3844,5830 Review URL: http://codereview.chromium.org/17455 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7823 0039d316-1c4b-4281-b951-d872f2087c98
* Adjusting the name of a function to make it more descriptive.avi@google.com2008-12-301-1/+1
| | | | | | Review URL: http://codereview.chromium.org/16489 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7504 0039d316-1c4b-4281-b951-d872f2087c98
* Move the "platform" wrappers in skia/ext to the skia namespace.brettw@google.com2008-12-171-1/+1
| | | | | | Review URL: http://codereview.chromium.org/14110 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7182 0039d316-1c4b-4281-b951-d872f2087c98
* Remove base versions of the graphics headers, which previously just ↵brettw@google.com2008-11-221-1/+1
| | | | | | | | forwarded to the skia ones. Review URL: http://codereview.chromium.org/11588 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5894 0039d316-1c4b-4281-b951-d872f2087c98
* Plumb WebCore's windowResizerRect() through glue and renderer. Enables Mac ↵pinkerton@google.com2008-11-211-0/+5
| | | | | | | | scrollbars to not overlap the in-window resizer widget. Review URL: http://codereview.chromium.org/11353 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5831 0039d316-1c4b-4281-b951-d872f2087c98
* A workaround fix for Issue 343 "Chinese Sogou input method lose first ↵hbono@chromium.org2008-11-171-1/+7
| | | | | | | | | | | | | | initial letter". This issue is caused by our IME code that does not filter out focus events raised by an IME function of WebKit, WebCore::Editor::setComposition(). Its details are listed below: 1. WebKit sometimes creates a WebCore::EditingText instance and moves the input focus to the instance while updating a composition string in the Editor::setComposition() function; 2. Our IME code automatically finishes the ongoing composition everytime when WebKit moves the input focus to the WebCore::EditingText instance. As a wordaround for this issue, this change ignores focus events while a renderer process updates a composition string with the Editor::setComposition() function. Review URL: http://codereview.chromium.org/10827 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5556 0039d316-1c4b-4281-b951-d872f2087c98
* Add Terminate() to the Process object, have RenderProcessHost use this to ↵brettw@google.com2008-11-141-1/+2
| | | | | | | | | | avoid some more Windows specific code. Move Process and SharedMemory into the base namespace (most changes). Review URL: http://codereview.chromium.org/10895 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5446 0039d316-1c4b-4281-b951-d872f2087c98
* Landing this again as I cannot reproduce the perf regression locally.jcampan@chromium.org2008-11-071-5/+9
| | | | | | | | | | | Will investigate on the bot. TBR=nsylvain Review URL: http://codereview.chromium.org/9700 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5018 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting the autofill popu CL as it creates perf regression.jcampan@chromium.org2008-11-061-9/+5
| | | | | | | | TBR=nsylvain Review URL: http://codereview.chromium.org/9460 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4908 0039d316-1c4b-4281-b951-d872f2087c98
* Changes parameters used by IME code to fix several issues caused by Japanese ↵hbono@chromium.org2008-11-061-19/+23
| | | | | | | | | | | | | | IMEs. Recent Japanese IMEs (ATOK2008 and MSIME 2007) display a suggestion window (a window which contains suggestions) above a composition string. To fix this issue, we do not only send the lower-left corner of a composition string but also send its upper-left corner and its upper-right corner. So, this change changes IPC parameters used by IME from a tuple of integers to gfx::Rect. Also, this change fixes cursor positions for Japanese IMEs. BUG=2770 "IME: Candidate window of Japanese IME follows the end of composition" BUG=2771 "ATOK 2008 IME pop-ups are displayed below the main Chrome window." BUG=2775 "IME: Caret is always displayed at the last of IME composition." Review URL: http://codereview.chromium.org/7385 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4872 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-13 06:11:11 +0000