summaryrefslogtreecommitdiffstats
path: root/chrome/renderer/render_view.h
Commit message (Collapse)AuthorAgeFilesLines
* Implements keyboard events for RenderViewTest.This change implements a ↵hbono@chromium.org2009-05-111-0/+3
| | | | | | | | function RenderViewTest::SendKeyEvent() that sends a keyboard event to a RenderView object.To emulate not only US keyboards but also non-US keyboards, this change adds a new class "MockKeyboard", which implements a mapping function from a triple <keyboard type, key code, modifiers> to a Unicode character so that engineers can write RenderViewTest cases without taking care of keyboard types.As samples for this new function, I updated my test RenderViewTest.OnHandleKeyboardEvent and added another test RenderViewTest.InsertCharacters.I wish this class help engineers write more RenderViewTest cases. Review URL: http://codereview.chromium.org/92122 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15748 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
* Refactor media player to move away from webkit_gluehclam@chromium.org2009-05-071-1/+4
| | | | | | | | | | | | Highlights: 1. WebCore::MediaPlayerPrivate now only has one static method that constructs WebMediaPlayerClient 2. Implementation of WebCore::MediaPlayerPrivateInterface now is WebMediaPlayerClient 3. WebMediaPlayerClient does the delgation to WebMediaPlayer 4. Implemtnation of real media player will go into chrome/renderer and implements WebMediaPlayer Review URL: http://codereview.chromium.org/105007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15492 0039d316-1c4b-4281-b951-d872f2087c98
* Popup whitelisting checkpoint.pkasting@chromium.org2009-05-061-2/+2
| | | | | | | | | | | | | | | | | This provides some basic UI for the popup whitelist. The actual whitelist is completely unimplemented and just has TODOs at the hook points. The actual blocking behavior of the browser is unchanged. The popup blocker bubble menu now gets an extra section below the popups with checkable "Always show popups from <host>" items (usually one, can be more on pages with popups from iframes from different hosts). Clicking one of these will whitelist a hostname and open its popups, and remove it from the menu. When navigating to a page with whitelisted popups, the popup blocker bubble is opened (showing "Blocked Popups: 0", text subject to change), and the menu contains the checked entr(y/ies) relevant to these page. Clicking one of these un-whitelists the host and removes the entry from the menu (closing the menu if that was the last such entry). Known UI questions: * Wording is all speculative * Should manually closing all popups associated with a whitelisted site remove that entry/close the menu automatically? (I suspect yes) * Should un-whitelisting a site via the menu entry close its popups, just like whitelisting it opens them? (Not sure) * Should menu items for sites stick around after toggling their whitelisting status, thus keeping the bubble onscreen until it's manually closed, the page is navigated, etc.? (While this is slightly more consistent, I suspect the answer is no) BUG=11440 Review URL: http://codereview.chromium.org/113058 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15475 0039d316-1c4b-4281-b951-d872f2087c98
* Plumb the creator URL for popups up to the browser. We don't yet use this ↵pkasting@chromium.org2009-05-051-1/+4
| | | | | | | | | for anything; it will be used for whitelisting popups by hostname. BUG=11440 Review URL: http://codereview.chromium.org/105004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15326 0039d316-1c4b-4281-b951-d872f2087c98
* Revert r15278. More unexpected test failures :(darin@chromium.org2009-05-051-1/+10
| | | | | | | | TBR=mpcomplete Review URL: http://codereview.chromium.org/108005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15279 0039d316-1c4b-4281-b951-d872f2087c98
* Re-do r15244: Fix crash in ~TestWebViewDelegate caused bydarin@chromium.org2009-05-051-10/+1
| | | | | | | | | | | | | | | | | | shell_ being null. Moved the RevokeDragDrop call to the TestShell destructor instead. Eliminate webkit/glue/webhistoryitem* in favor of adding a NavigateBackForwardSoon method WebViewDelegate. This moves all of the hacky details of how we intercept "history.{back, forward,go}" into the webkit layer. My eventual plan is to teach WebCore how to make this not hacky. BUG=11423 R=mpcomplete Review URL: http://codereview.chromium.org/108004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15278 0039d316-1c4b-4281-b951-d872f2087c98
* Various trivial clean-up bits:pkasting@chromium.org2009-05-051-5/+1
| | | | | | | | | | * Fix an 80-column issue * Remove an unused param * Remove an unnecessary setter * Fix a variable capitalization style violation Review URL: http://codereview.chromium.org/100361 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15254 0039d316-1c4b-4281-b951-d872f2087c98
* Fix bug 9812: Remove current RSS code in favor of new more generalizedfinnur@chromium.org2009-05-041-4/+0
| | | | | | | | | | | | PageAction code that serves the same purpose (and more). BUG=9812 TEST=No test needed, this shouldn't result in any noticable difference since the RSS parsing was disabled. Review URL: http://codereview.chromium.org/100356 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15247 0039d316-1c4b-4281-b951-d872f2087c98
* Revert r15244. Failed tests :(darin@chromium.org2009-05-041-1/+10
| | | | | | | | TBR=mpcomplete Review URL: http://codereview.chromium.org/99370 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15246 0039d316-1c4b-4281-b951-d872f2087c98
* Eliminate webkit/glue/webhistoryitem* in favor of adding adarin@chromium.org2009-05-041-10/+1
| | | | | | | | | | | | | | NavigateBackForwardSoon method WebViewDelegate. This moves all of the hacky details of how we intercept "history.{back, forward,go}" into the webkit layer. My eventual plan is to teach WebCore how to make this not hacky. BUG=11423 R=mpcomplete Review URL: http://codereview.chromium.org/100353 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15244 0039d316-1c4b-4281-b951-d872f2087c98
* This CL makes Chrome on par with Firefox in terms of 'GetSuggestedFilename' ↵jungshik@google.com2009-05-011-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | for file download via context-menu. For a download initiated with a click on a link in a web page, a webkit-side change is necessary, which will be done later. Add a field (referrer_charset) to URLRequestContext and DownloadCreateInfo. It's set to the character encoding of a document where the download request originates from when it's known (download initiated via "save as" in the context menu). If it's not known (a download initiated by clicking on a download link or typing a url directly to the omnibox), it's initialized to the default character encoding in the user's preference. I guess this is marginally better than leaving it empty (in that case, step 2b below will be skipped and step 2c will be taken) because a user has a better control over how raw 8bit characters in C-D are interpreted (especially on Windows where a reboot is required to change the OS default codepage). This is later passed to GetSuggestedFilename and used as one of fallback encodings (1. UTF-8, 2. origin_charset, 3. default OS codepage). With this change, we support the following: 1. RFC 2047 2. Raw-8bit-characters : a. UTF-8, b. origin_charset, c. default os codepage. 3. %-escaped UTF-8. In this CL, for #3, I didn't add a fallback similar to one used for #2. If necessary, it can be added easily. New entries are added to 3 existing tests. What's previously not covered (raw 8bit Content-Disposition header) is now covered in all 3 tests. BUG=1148 TEST=net unit test: NetUtilTest.GetFileNameFromCD NetUtilTest.GetSuggestedFilename unittest : DownloadManagerTest.TestDownloadFilename Review URL: http://codereview.chromium.org/83002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15113 0039d316-1c4b-4281-b951-d872f2087c98
* Replace window.external with a v8::extension.mbelshe@google.com2009-05-011-4/+0
| | | | | | | | | BUG=http://crbug.com/10957 TEST=Verify that the AddSearchProvider logic still works. This dates back to an old bug http://b/1069781 Review URL: http://codereview.chromium.org/99168 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15056 0039d316-1c4b-4281-b951-d872f2087c98
* Second attempt at cleaning up handling of --disable-popup-blocking. I ↵pkasting@chromium.org2009-04-291-6/+0
| | | | | | | | | didn't realize that now window.open() will result in a popup with this flag, where before it resulted in a tab. This necessitated changes to a test that expected one window and two tabs to expect two windows each with one tab. I also fixed the test to not crash when some expectations were not met (by using ASSERT_ instead of EXPECT_), and to properly use (expected, actual) instead of (actual, expected). Review URL: http://codereview.chromium.org/99203 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14886 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "Instead of passing down a switch to the renderer, storing a member, ↵evan@chromium.org2009-04-291-0/+6
| | | | | | | | | | etc., just implement --disable-popup-blocking in the browser at the point where we make the final policy decision." This reverts commit r14851. As it DID NOT PASS THE TRY BOTS. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14853 0039d316-1c4b-4281-b951-d872f2087c98
* Instead of passing down a switch to the renderer, storing a member, etc., ↵pkasting@chromium.org2009-04-291-6/+0
| | | | | | | | just implement --disable-popup-blocking in the browser at the point where we make the final policy decision. Review URL: http://codereview.chromium.org/100132 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14851 0039d316-1c4b-4281-b951-d872f2087c98
* Fix sudden termination after the latest WebKit merge.jam@chromium.org2009-04-251-2/+0
| | | | | | | | BUG=10927 Review URL: http://codereview.chromium.org/93104 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14517 0039d316-1c4b-4281-b951-d872f2087c98
* Use WebWorker and WebWorkerClient from the WebKit API.darin@chromium.org2009-04-241-1/+1
| | | | | | | | | BUG=10995 R=jam Review URL: http://codereview.chromium.org/92144 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14461 0039d316-1c4b-4281-b951-d872f2087c98
* Remove unused bits and pieces of #ifdefed code that isn't used.tim@chromium.org2009-04-241-13/+0
| | | | | | Review URL: http://codereview.chromium.org/93042 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14402 0039d316-1c4b-4281-b951-d872f2087c98
* Add transparency support to RenderWidgetHostView.aa@chromium.org2009-04-231-1/+5
| | | | | | | | | | | | 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
* Adds a keyboard-event test into RenderViewTest.hbono@chromium.org2009-04-231-0/+1
| | | | | | | | | | | | | | This change adds a new test "RenderViewTest.OnHandleKeyboardEvent" to verify we can receive proper DOM events when we send platform-specific keyboard events. This test is mainly for verifying our WebKit-glue code can convert platform-specific keyboard events to keyboard events of WebKit without any problems, which is hard to implement with LayoutTests. To emulate non-US layouts, this test loads the following keyboard-layout drivers: * Arabic (qwerty); * United States (qwerty); * French (azerty); * Hebrew, and; * Canadian French (qwerty). Review URL: http://codereview.chromium.org/75034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14287 0039d316-1c4b-4281-b951-d872f2087c98
* DevTools: Make all devtools messages dispatch through debugger interrupt.pfeldman@chromium.org2009-04-171-4/+0
| | | | | | Review URL: http://codereview.chromium.org/73002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13910 0039d316-1c4b-4281-b951-d872f2087c98
* Handles audio messages on IO thread in render processhclam@chromium.org2009-04-161-32/+8
| | | | | | | | | | | | | | | | First step to have smoother audio playback. We previously performed audio messages handling on render thread, which gave us huge amount of latency, especially when renderer is busy compositing or is blocked by synchronous IPC call. A lot of these latencies are eliminated by moving audio messages handling to IO thread, this is the first step to see if sharing the regular IPC channel for audio messages is creating too much stress for the IPC channel. Also doubled the audio packet size to 8192 samples, ~194ms of audio for 16bit/44.1khz/2ch. Review URL: http://codereview.chromium.org/62125 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13863 0039d316-1c4b-4281-b951-d872f2087c98
* Introduce printing test case (Step 1)hbono@chromium.org2009-04-161-0/+2
| | | | | | | | | | | | | | | | | | This CL will just show how to actually execute a full print process from start to finish. It will verify that a page has been printed (successfully). In the next steps, we would need to test whether the elements rendered after printing are correct. (how?) And fixed some lint errors. Thanks for hbono and maruel to lead me in the right direction :) Original patch by Mohamed Mansour (see http://codereview.chromium.org/67036/show), r=me,maruel,sverrir. BUG=? Review URL: http://codereview.chromium.org/67202 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13831 0039d316-1c4b-4281-b951-d872f2087c98
* Refactoring; switch the |filter| parameter into something that is more ↵avi@chromium.org2009-04-121-3/+2
| | | | | | | | | | amenable to cross-platform implementation. BUG=9852 Review URL: http://codereview.chromium.org/63093 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13573 0039d316-1c4b-4281-b951-d872f2087c98
* Make sure we can handle favicons that are provided as data: URLsarv@chromium.org2009-04-111-0/+3
| | | | | | | | BUG=9881 Review URL: http://codereview.chromium.org/67042 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13551 0039d316-1c4b-4281-b951-d872f2087c98
* Switch to using WebPoint, WebRect, and WebSize in more of the gluedarin@chromium.org2009-04-091-1/+1
| | | | | | | | | | | | | | | | | 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
* Copy text selection from renderer to browser every time it changes.estade@chromium.org2009-04-091-4/+0
| | | | | | | BUG=9848 Review URL: http://codereview.chromium.org/63145 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13396 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/+3
| | | | | | | | | | | | | | | 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
* Switch to using WebDragData in WebView and WebViewDelegate.darin@chromium.org2009-04-071-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | I also cleaned up some of the WebView and WebViewDelegate methods to pass WebPoint instead of pairs of ints or gfx::Point. With this change, I am keeping webkit/glue/webdropdata.{h,cc}, which is what Chrome uses to pass around the equivalent data. Now, it is possible to construct a WebDropData from a WebKit::WebDragData and to also get a WebKit::WebDragData from a WebDropData. Hence, the conversion between WebDropData and ChromiumDataObject (see clipboard_conversion.{h,cc}) is now removed in favor of conversion between WebDropData and WebKit::WebDragData. Conversion between WebKit::WebDragData and WebCore::ChromiumDataObject is very cheap (just reference counting). Finally, this change also brings in WebData, which is now used by the return value of WebKitClient::loadResource. As a companion to that change, I also changed webkit_glue::GetDataResource to return StringPiece instead of std::string. That also saves on an unnecessary buffer copy. R=dglazkov Review URL: http://codereview.chromium.org/63084 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13305 0039d316-1c4b-4281-b951-d872f2087c98
* Switching things to FilePath:phajdan.jr@chromium.org2009-04-071-0/+1
| | | | | | | | | | | | | | | | Remove following deprecated wstring-using functions: net/net_util: FilePathToFileURL net/net_util: FileURLToFilePath Switch net/base/upload_data to FilePath. Switch upload-related parts of net/url_request/url_request to FilePath. Made necessary adjustments in rest of code (a lot). Review URL: http://codereview.chromium.org/63011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13242 0039d316-1c4b-4281-b951-d872f2087c98
* Stop serializing WebString over IPC. The new rule is that only POD (plain olddarin@chromium.org2009-04-061-5/+6
| | | | | | | | | | | | | data) types from WebKit API are allowed to be used in the browser process. I added a big note about this to webkit_param_traits.h to explain the details of this decision. R=dglazkov Review URL: http://codereview.chromium.org/62032 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13181 0039d316-1c4b-4281-b951-d872f2087c98
* First pass of refactoring dialogs.avi@chromium.org2009-04-061-1/+1
| | | | | | Review URL: http://codereview.chromium.org/60110 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13168 0039d316-1c4b-4281-b951-d872f2087c98
* DevTools: Split message handling on the agent side into the Renderer and IO ↵pfeldman@chromium.org2009-04-061-1/+5
| | | | | | | | | | | handling classes (currently mixed). All the messages except for the DebuggerCommand should go be dispatched on the Renderer thread by the DevToolsAgent. DebuggerCommand should be handled by the DevToolsAgentFilter separately (for v8 suspend support). Review URL: http://codereview.chromium.org/62037 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13153 0039d316-1c4b-4281-b951-d872f2087c98
* Callbacks through ChromeClient->RenderView->RenderViewHost for ↵rafaelw@chromium.org2009-04-041-0/+3
| | | | | | | | ContentsDidChangeSize so that extensions can change their toolbar size when the contained contents changes size. Review URL: http://codereview.chromium.org/56122 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13130 0039d316-1c4b-4281-b951-d872f2087c98
* - Added support for keeping track of load times.davemoore@chromium.org2009-04-031-0/+2
| | | | | | | | | | | | | | | | | For each document loaded we record the time the page was requested by the user (or as close as we can get to that), the time the load process started, the time the document and it's dependent resources (scripts) have been loaded (before onload()) and the time all the document's resources have been loaded. We use this data for two things: 1) We histogram the deltas between the time marks 2) We expose the times to javascript running on the page which was loaded Review URL: http://codereview.chromium.org/42527 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13116 0039d316-1c4b-4281-b951-d872f2087c98
* Add code to support 2-way communication between extensions and renderers. ↵mpcomplete@google.com2009-04-021-2/+0
| | | | | | | | The code is almost fully symmetrical, except that right now a channel can only be opened to an extension (by ID). It should be trivial to open a channel to a tab, once we have a solid tab API. Review URL: http://codereview.chromium.org/56037 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13057 0039d316-1c4b-4281-b951-d872f2087c98
* Copy selection to x clipboard.estade@chromium.org2009-04-021-0/+10
| | | | | | Review URL: http://codereview.chromium.org/55052 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13044 0039d316-1c4b-4281-b951-d872f2087c98
* Paste from the x clipboard into webkit.estade@chromium.org2009-04-021-0/+3
| | | | | | Review URL: http://codereview.chromium.org/51008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13031 0039d316-1c4b-4281-b951-d872f2087c98
* Use WebConsoleMessage instead of ConsoleMessageLevel.darin@chromium.org2009-03-311-3/+2
| | | | | | | | R=dglazkov Review URL: http://codereview.chromium.org/57073 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12916 0039d316-1c4b-4281-b951-d872f2087c98
* Use WebScriptSource and WebFindInPageRequest from the WebKit API.darin@chromium.org2009-03-311-4/+5
| | | | | | | | | | | | | | | | | | This change introduces some helper functions in glue_util.cc for efficient conversion between WebString and WebCore::String when inside the implementation of webkit/glue. This is a temporary change since eventually all code in glue that uses WebCore will be moved into the WebKit API implementation. Instead of making the Chrome automation use WebFindInPageRequest, I decided to introduce AutomationMsg_Find_Params as a copy of the old FindInPageRequest structure. That preserves the IPC protocol and avoids making the automation library depend on WebKit. R=dglazkov Review URL: http://codereview.chromium.org/57060 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12881 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
* Implement default css for toolstrips.aa@chromium.org2009-03-241-0/+6
| | | | | | Review URL: http://codereview.chromium.org/42435 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12408 0039d316-1c4b-4281-b951-d872f2087c98
* Add basic infrastructure for sending async browser API request and receiving ↵aa@chromium.org2009-03-241-0/+8
| | | | | | | | results. Review URL: http://codereview.chromium.org/42262 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12347 0039d316-1c4b-4281-b951-d872f2087c98
* Initial rev at a message passing API for extensions. So far, only passingmpcomplete@google.com2009-03-231-4/+2
| | | | | | | messages to the extension process is supported. Review URL: http://codereview.chromium.org/48090 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12319 0039d316-1c4b-4281-b951-d872f2087c98
* Pressing the Del key while a item is selected in the autocomplete popup ↵jcampan@chromium.org2009-03-201-0/+2
| | | | | | | | | | deletes that suggestion from the DB. BUG=6176 TEST=Bring up the autofill popup in a form. Select an item and press the Del key. The item should be removed from the popup and should not show on subsequent autofill popups. Review URL: http://codereview.chromium.org/42258 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12221 0039d316-1c4b-4281-b951-d872f2087c98
* Removes all use of COM and dependencies on Windows-specific classes ↵klink@chromium.org2009-03-201-8/+11
| | | | | | | | (including the use of AccessibleBase and AccessibleDocument) in the glue accessibility implementation.Introduces the GlueAccessibilityObject, which serves as a platform-independent wrapper directly around WebKit's AccessibilityObject (also platoform-independent).Updates naming/comments to reflect the independence of IAccessible both in glue and (where appropriate) in the browser-side accessibility. Review URL: http://codereview.chromium.org/46013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12207 0039d316-1c4b-4281-b951-d872f2087c98
* Remove code duplicated from webcore and use the common PrintContext facility.maruel@chromium.org2009-03-191-17/+3
| | | | | | Review URL: http://codereview.chromium.org/20470 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12100 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 11953.hbono@chromium.org2009-03-181-1/+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/+1
| | | | | | | | | | | | | | | | | 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