summaryrefslogtreecommitdiffstats
path: root/views/focus
Commit message (Collapse)AuthorAgeFilesLines
* Minor fixes to toolbar keyboard accessibility: focusing the location bardmazzoni@chromium.org2010-06-302-8/+43
| | | | | | | | | | | | | | | should select all, accessibility focus should be preserved when the whole window loses and regains focus, and clicking on the location bar should exit accessibility focus mode. BUG=47380 BUG=36070 BUG=47784 TEST=none Review URL: http://codereview.chromium.org/2833040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@51262 0039d316-1c4b-4281-b951-d872f2087c98
* *Add WidgetGtk::ClearNativeFocus so that subclass can implement cutomized ↵oshima@chromium.org2010-06-191-9/+1
| | | | | | | | | | | | | | behavior when clearning native focus. This is necessary in ScreenLocker as the focus has to be set to the widget that is grabbing all input focus. * PasswordField that will set focus it itself when mouse is clicked. This is necessary again when the input is grabbed by other widget because the gtk textfield will never receive mouse event. * fix minor bug : locating the grab widget in wrong place. Review URL: http://codereview.chromium.org/2811015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@50303 0039d316-1c4b-4281-b951-d872f2087c98
* Keep a cache of all views that have sent notifications. This ensures that ↵dtseng@chromium.org2010-06-181-2/+1
| | | | | | | | | | AccessibleObjectFromEvent works properly. BUG=9601 TEST=none Review URL: http://codereview.chromium.org/2823009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@50302 0039d316-1c4b-4281-b951-d872f2087c98
* Improve toolbar keyboard accessibility.dmazzoni@chromium.org2010-06-186-98/+652
| | | | | | | | | | | | Design doc: https://docs.google.com/a/google.com/Doc?docid=0ATICCjR-gNReY2djdjkyNnNfNzl4ZnpiODQ2Mg&hl=en BUG=40745 BUG=36728 BUG=36222 TEST=New test added to focus_manager_unittest.cc Review URL: http://codereview.chromium.org/2737010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@50234 0039d316-1c4b-4281-b951-d872f2087c98
* Allow widgets to have keyboard shortcuts.avayvod@chromium.org2010-06-161-5/+7
| | | | | | | | | BUG=cros:3956 TEST=Check that keyboard shortcuts work on login screens. Review URL: http://codereview.chromium.org/2857004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@49929 0039d316-1c4b-4281-b951-d872f2087c98
* Process accelerators if grabbed widget is a window.xiyuan@chromium.org2010-06-021-4/+17
| | | | | | | | | | | Update the gtk event filtering logic to process key events for grabbed window (i.e. modal dialog). BUG=chromium-os:3701 TEST=Verify fix for chromium-os:3701. Review URL: http://codereview.chromium.org/2455004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@48742 0039d316-1c4b-4281-b951-d872f2087c98
* views: implement a TODO to move WidgetGtk::GetWindowForNative to WindowGtk.tfarina@chromium.org2010-06-021-3/+2
| | | | | | | | | BUG=NONE TEST=compiles. Review URL: http://codereview.chromium.org/1640003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@48717 0039d316-1c4b-4281-b951-d872f2087c98
* Fixing AutoReset to be a template.gspencer@chromium.org2010-06-011-1/+1
| | | | | | | | | | | I've run into a couple of times this week when I needed one of these, for two different types besides bool. Time to fix the TODO. TEST=trybots FTW, and built locally. BUG=none Review URL: http://codereview.chromium.org/2394001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@48644 0039d316-1c4b-4281-b951-d872f2087c98
* Fixed alt key as shortcut to focus menus on linux/views. It should onlydmazzoni@chromium.org2010-05-243-21/+239
| | | | | | | | | | | | trigger when you press and release Alt and no other keys. Previously it could trigger when Alt was released as part of some other key combination. BUG=40754 TEST=Added new test, accelerator_handler_gtk_unittest.cc Review URL: http://codereview.chromium.org/2128011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@48095 0039d316-1c4b-4281-b951-d872f2087c98
* Committing on behalf of dtseng.dmazzoni@chromium.org2010-05-071-0/+7
| | | | | | | | | | | | | | | | We currently only set focus to the widget's hWnd, but we really want to also notify assistive technologies that a child view received focus so that it can know to obtain an IAccessible for that custom child view using the widget hWnd. The widget hWnd has our implementation of IAccessible through AccessibilityWrapper/ViewAccessibility. Original code review: http://codereview.chromium.org/1985002 BUG=43363 TEST=none git-svn-id: svn://svn.chromium.org/chrome/trunk/src@46687 0039d316-1c4b-4281-b951-d872f2087c98
* Skip accelerator handling if there is a grabbed widget.xiyuan@chromium.org2010-05-031-1/+4
| | | | | | | | | | | | Grabbed widget in gtk should get all the mouse and keyboard events and we should respect that. BUG=<http://crosbug.com/2355> TEST=Verify 2nd issue of 2355 that combobox dropdown should not disappear after mouse release. Also verify that 1st ESC should clear off combo's dropdown and 2nd ESC should dismiss the dialog. Please also pay attention to other regressions related to accelerator keys on gtk (linux, linux_chromeos builds). Review URL: http://codereview.chromium.org/1727020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@46229 0039d316-1c4b-4281-b951-d872f2087c98
* Defer WidgetGtk's focus manager destructionxiyuan@chromium.org2010-04-202-1/+103
| | | | | | | | | | | | | | | | | | This is for the case when a WidgetGtk is hosted in another WidgtGtk and holds a reference to its focus manager. When hosting widget is destroied, it gets the "destroy" signal before the contained widget and thus schedules its destruction before the contained widget. And currently, we are not clearing the focus manager reference in another root view and when contained widget destructs, we crash. By changing focus manager's release into another message, the focus manager remains valid during contained widget destruction. BUG=none TEST=In ChromeOS, bring up options dialog and then click on buttons such as language settings, networ config etc. Then dismiss the options dialog and Chrome should not crash. Review URL: http://codereview.chromium.org/1661003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45071 0039d316-1c4b-4281-b951-d872f2087c98
* * WidgetGtk::OnKeyPressed never called on window because the signal handleroshima@chromium.org2010-04-021-8/+50
| | | | | | | | | | | | was connected to the content, but the focus was set to GtkWindow by FocusManager. * Enable IgnoreKeyupForAccelerators for linux. BUG=40140 TEST=IgnoreKeyupForAccelerators shoud pass now on linux. Review URL: http://codereview.chromium.org/1575001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@43506 0039d316-1c4b-4281-b951-d872f2087c98
* Keyboard accessibility for the page and app menus.dmazzoni@chromium.org2010-03-314-1/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | Works on Windows, and on Linux with toolkit_views. The goal is to make Chrome behave more like a standard Windows application, for users who rely on the keyboard and expect standard keyboard accelerators to work. Pressing F10, or pressing and releasing Alt, will set focus to the Page menu, as if it was the first item in a menu bar. Pressing enter, space, up arrow, or down arrow will open the focused menu. Once a menu is opened, pressing left and right arrows will switch between the two menus. Pressing escape will return focus to the title of the previously open menu. A new UI test attempts to select something from the menus using only the keyboard. It works on Linux (with toolkit_views) and on Windows. BUG=none TEST=New keyboard accessibility interactive ui test. Review URL: http://codereview.chromium.org/660323 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@43216 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting this CL to fix the interactive ui test failures.ananta@chromium.org2010-03-264-35/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert 42498 - Keyboard accessibility for the page and app menus. Works on Windows, and on Linux with toolkit_views. The goal is to make Chrome behave more like a standard Windows application, for users who rely on the keyboard and expect standard keyboard accelerators to work. Pressing F10, or pressing and releasing Alt, will set focus to the Page menu, as if it was the first item in a menu bar. Pressing enter, space, up arrow, or down arrow will open the focused menu. Once a menu is opened, pressing left and right arrows will switch between the two menus. Pressing escape will return focus to the title of the previously open menu. A new UI test attempts to select something from the menus using only the keyboard. It works on Linux (with toolkit_views) and on Windows. BUG=none TEST=New keyboard accessibility interactive ui test. Review URL: http://codereview.chromium.org/660323 TBR=dmazzoni@chromium.org Review URL: http://codereview.chromium.org/1428001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42779 0039d316-1c4b-4281-b951-d872f2087c98
* Reenabling some unit-tests on Linux, they seem to work fine now,jcivelli@chromium.org2010-03-251-6/+0
| | | | | | | | | | | even with the screen locked. BUG=23394 TEST=Run the tests. Review URL: http://codereview.chromium.org/1286005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42634 0039d316-1c4b-4281-b951-d872f2087c98
* Keyboard accessibility for the page and app menus.dmazzoni@chromium.org2010-03-244-1/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | Works on Windows, and on Linux with toolkit_views. The goal is to make Chrome behave more like a standard Windows application, for users who rely on the keyboard and expect standard keyboard accelerators to work. Pressing F10, or pressing and releasing Alt, will set focus to the Page menu, as if it was the first item in a menu bar. Pressing enter, space, up arrow, or down arrow will open the focused menu. Once a menu is opened, pressing left and right arrows will switch between the two menus. Pressing escape will return focus to the title of the previously open menu. A new UI test attempts to select something from the menus using only the keyboard. It works on Linux (with toolkit_views) and on Windows. BUG=none TEST=New keyboard accessibility interactive ui test. Review URL: http://codereview.chromium.org/660323 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42498 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 42465 - Keyboard accessibility for the page and app menus.dmazzoni@chromium.org2010-03-244-35/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reverting because newly added Test*MenuKeyboardAccess tests fail on some of the Windows buildbots, and possibly a XP Perf regression. Works on Windows, and on Linux with toolkit_views. The goal is to make Chrome behave more like a standard Windows application, for users who rely on the keyboard and expect standard keyboard accelerators to work. Pressing F10, or pressing and releasing Alt, will set focus to the Page menu, as if it was the first item in a menu bar. Pressing enter, space, up arrow, or down arrow will open the focused menu. Once a menu is opened, pressing left and right arrows will switch between the two menus. Pressing escape will return focus to the title of the previously open menu. A new UI test attempts to select something from the menus using only the keyboard. It works on Linux (with toolkit_views) and on Windows. BUG=none TEST=New keyboard accessibility ui test. Review URL: http://codereview.chromium.org/660323 TBR=dmazzoni@chromium.org Review URL: http://codereview.chromium.org/1257003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42468 0039d316-1c4b-4281-b951-d872f2087c98
* Keyboard accessibility for the page and app menus.dmazzoni@chromium.org2010-03-244-1/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | Works on Windows, and on Linux with toolkit_views. The goal is to make Chrome behave more like a standard Windows application, for users who rely on the keyboard and expect standard keyboard accelerators to work. Pressing F10, or pressing and releasing Alt, will set focus to the Page menu, as if it was the first item in a menu bar. Pressing enter, space, up arrow, or down arrow will open the focused menu. Once a menu is opened, pressing left and right arrows will switch between the two menus. Pressing escape will return focus to the title of the previously open menu. A new UI test attempts to select something from the menus using only the keyboard. It works on Linux (with toolkit_views) and on Windows. BUG=none TEST=New keyboard accessibility ui test. Review URL: http://codereview.chromium.org/660323 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42465 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "Keyboard accessibility for the page and app menus.", rev 42234 and ↵maruel@chromium.org2010-03-224-35/+1
| | | | | | | | | | 42236. TBR=dmazzoni Review URL: http://codereview.chromium.org/1158004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42239 0039d316-1c4b-4281-b951-d872f2087c98
* Keyboard accessibility for the page and app menus.dmazzoni@chromium.org2010-03-224-1/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | Works on Windows, and on Linux with toolkit_views. The goal is to make Chrome behave more like a standard Windows application, for users who rely on the keyboard and expect standard keyboard accelerators to work. Pressing F10, or pressing and releasing Alt, will set focus to the Page menu, as if it was the first item in a menu bar. Pressing enter, space, up arrow, or down arrow will open the focused menu. Once a menu is opened, pressing left and right arrows will switch between the two menus. Pressing escape will return focus to the title of the previously open menu. A new UI test attempts to select something from the menus using only the keyboard. It works on Linux (with toolkit_views) and on Windows. BUG=none TEST=New keyboard accessibility ui test. Review URL: http://codereview.chromium.org/660323 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42234 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "Keyboard accessibility for the page and app menus."maruel@chromium.org2010-03-224-35/+1
| | | | | | | | | | This reverts commit 42217. TBR=dmzazzoni Review URL: http://codereview.chromium.org/1154003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42218 0039d316-1c4b-4281-b951-d872f2087c98
* Keyboard accessibility for the page and app menus.dmazzoni@chromium.org2010-03-224-1/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | Works on Windows, and on Linux with toolkit_views. The goal is to make Chrome behave more like a standard Windows application, for users who rely on the keyboard and expect standard keyboard accelerators to work. Pressing F10, or pressing and releasing Alt, will set focus to the Page menu, as if it was the first item in a menu bar. Pressing enter, space, up arrow, or down arrow will open the focused menu. Once a menu is opened, pressing left and right arrows will switch between the two menus. Pressing escape will return focus to the title of the previously open menu. A new UI test attempts to select something from the menus using only the keyboard. It works on Linux (with toolkit_views) and on Windows. BUG=none TEST=New keyboard accessibility ui test. Review URL: http://codereview.chromium.org/660323 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42217 0039d316-1c4b-4281-b951-d872f2087c98
* Move some more files to toplevel gfx dir.ben@chromium.org2010-03-171-1/+1
| | | | | | | | | TBR=darin BUG=none TEST=none git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41812 0039d316-1c4b-4281-b951-d872f2087c98
* Move base/gfx contents to gfx/ben@chromium.org2010-03-141-1/+1
| | | | | | | | | TBR=darin BUG=none TEST=none git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41559 0039d316-1c4b-4281-b951-d872f2087c98
* Fix compile error "error: #elif with no expression"nsylvain@chromium.org2010-02-271-1/+1
| | | | | | Review URL: http://codereview.chromium.org/660190 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40195 0039d316-1c4b-4281-b951-d872f2087c98
* Landing Marshall Greenblatt change.jcampan@chromium.org2010-02-242-4/+60
| | | | | | | | | | | | | See review at: http://codereview.chromium.org/609010/show BUG=None TEST=None Review URL: http://codereview.chromium.org/657019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@39827 0039d316-1c4b-4281-b951-d872f2087c98
* CL implementing focus-dismissal of the chrome.experimental.popup set of ↵twiz@chromium.org2010-02-102-3/+117
| | | | | | | | | | | | | | | | | extension APIs. Specifically, these changes cause a displayed pop-up to be dismissed when the focus shifts away from both the pop-up view, and the extension-view that launched the pop-up.I had to do a lot of investigating and trial-and-error to converge to the solution present here. I was hoping to be able to piggy-back on the existing FocusManager's various listener routines, but because the pop-up is hosted in a BubbleWidget, which is a separate top-level window with its own focus manager, I could not rely on a given focus manager to take care of the focus change notifications. To get around the above issue, I added a new type of focus listener that can listen on native-window focus change events. I added invocations to this listener throughout the Widget classes in the system so that registered listeners will be notified on focus change. I found some of the focus change events problematic, as the system will arbitrarily reassign the focus to the main browser window when shifting activation between chrome windows. (SeefocusManagerWin::ClearNativeFocus). To prevent this focus bounce from confusing focus listeners, I added a means to suppress notification of focus change during these operations. I added GTK and Mac stubs for the new widget functions that will assert when called. GTK and Cocoa development is not my expertise, so I thought // TODO(port) would be wiser.I'm uncertain of the best means to unit-test these changes. Direction in this regard would be appreciated. BUG=None TEST=None Review URL: http://codereview.chromium.org/552167 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38685 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes two related focus bugs on views/gtk:sky@chromium.org2010-01-071-0/+3
| | | | | | | | | | | | | | . Focus was inadvertently getting cleared when a window was shown because the focus-in event is received asynchronously. . In some situations we get multiple focus-out events in a row, this caused us to clear out who we thought would have focus. BUG=31140, 31130 TEST=see bugs Review URL: http://codereview.chromium.org/521045 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35714 0039d316-1c4b-4281-b951-d872f2087c98
* Lands http://codereview.chromium.org/449003/show for Thiago:sky@chromium.org2009-12-011-1/+1
| | | | | | | | | | | | | | views: replace the deprecated macro (DISALLOW_EVIL_CONSTRUCTORS). Use DISALLOW_COPY_AND_ASSIGN instead, also fix some style issues pointed by lint. BUG=none TEST=none Review URL: http://codereview.chromium.org/449075 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33500 0039d316-1c4b-4281-b951-d872f2087c98
* Use AutoReset (formerly ScopedBool) where possible.pkasting@chromium.org2009-11-201-2/+2
| | | | | | | | | | This frequently saves a tiny bit of code, but even when it doesn't I think it's more future-proof (less error-prone). BUG=none TEST=none Review URL: http://codereview.chromium.org/399096 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32708 0039d316-1c4b-4281-b951-d872f2087c98
* Fix for BookmarkManager Test Crash test.oshima@chromium.org2009-11-181-1/+5
| | | | | | | | | | | | | | | * Test was failing because the key events were sent even after the window has been destroyed. * Make sure browser window is closed before the end of test. Test fails in BookmarkBarView without this. I think this requires a fix on browser side. Filed a bug 28046. BUG=None Test=run browser_tests --gtest_filter=*Bookmark* Review URL: http://codereview.chromium.org/397034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32286 0039d316-1c4b-4281-b951-d872f2087c98
* Use predefined color names where possible for clarity. Also use ↵pkasting@chromium.org2009-10-131-2/+2
| | | | | | | | | | "SkColorSetARGB(0, 0, 0, 0)" in place of "NULL" since it's not obvious what the latter means as a color. BUG=none TEST=none Review URL: http://codereview.chromium.org/273042 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28874 0039d316-1c4b-4281-b951-d872f2087c98
* Move native_widget_types and gtk_native_view_id_manager from base/gfx tobrettw@chromium.org2009-10-111-1/+1
| | | | | | | | | | | | 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
* Add about:memory link to task manager.thakis@chromium.org2009-10-081-1/+1
| | | | | | | | | | | | | Since about:memory DCHECK()s atm, the link is not completely hooked up. In the xib, I've added a square button with height 14 and the new HyperlinkCell, contained in a GTMWidthBasedResizer or how it's called. I made sure the baseline of link on the left and button on the right is at the same height. BUG=17989,13156 TEST=Open MainMenu.xib, click "Enable" for view->dev->taskman. Build&run chrome. Task manager should contain link. Review URL: http://codereview.chromium.org/255018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28426 0039d316-1c4b-4281-b951-d872f2087c98
* Enabling the default button behavior on Linux toolkit_views.jcampan@chromium.org2009-10-082-13/+15
| | | | | | | | | | | | I had to make the KeyEvent constructor include the event flags. Also cleaned-up some unit-tests BUG=None TEST=Run the unit-tests. Review URL: http://codereview.chromium.org/266012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28397 0039d316-1c4b-4281-b951-d872f2087c98
* Turns on the focus traversal unit-tests and fixed some focus traversal problem:jcampan@chromium.org2009-10-071-74/+74
| | | | | | | | | | | | | | | | - in TabbedPaneView, the focus traversable were not properly hooked-up - the NativeTextField was focusing the wrapper view instead of the actual Textfield view. Also in the FocusTraversal unit-test I had to select one of the radio-button that the test uses, as the behavior of focusing a disabled button is different on Windows (it forces any non disabled radio-button to become selected) than on Gtk. BUG=None TEST=Run the unit tests. Review URL: http://codereview.chromium.org/242163 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28263 0039d316-1c4b-4281-b951-d872f2087c98
* This CL make the AcceleratorDispatcher eat the WM_KEYUP associated tojcampan@chromium.org2009-10-063-5/+158
| | | | | | | | | | | | WM_KEYDOWN that resulted in an accelerator, as they would cause orphaned KeyUp events to be sent to views. This is Windows only for now, still needs to be ported to Linux. BUG=23383 TEST=Run unit-tests. Ensure accelerators work as expected in Chrome. Review URL: http://codereview.chromium.org/246074 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28096 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting the NativeViewHostWin focus refactoring.jcampan@chromium.org2009-10-051-103/+1
| | | | | | | | | | | It seems the added subclassing is causing crashers in the field. BUG=23861 TEST=None TBR=beng Review URL: http://codereview.chromium.org/259052 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28061 0039d316-1c4b-4281-b951-d872f2087c98
* Relanding focus traversal on Linux toolkit views.jcampan@chromium.org2009-10-012-1/+13
| | | | | | | | | | | | | | | | | | | | | It was previously breaking the interactive UI tests. That was because I changed the button base class to be focusable by default which led to many button beings added to the tab traversal order. I now explicitly make these buttons non focusable. Also because of the way we clear the native focus on Gtk (by setting focus to NULL on the top level window), views now default to clearing the focus when focused (so that views non backed by a native window don't leave the native focus on the previously native window). On Windows we used to focus the WidgetWin's HWND, and now we focus the top-level HWND. The WidgetWin class had to be changed to forward the key events to the root view that contains the focused view because of that. (otherwise it would send it to the top-level root-view, and if the focused view was in a child root-view it would not recieve the keyboard messages). Note that the mouse wheel does not need that, as the mouse-wheel Windows messages are sent to the HWND under the cursor. See: http://codereview.chromium.org/246030/show TEST=Run the tests BUG=NONE Review URL: http://codereview.chromium.org/255008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27723 0039d316-1c4b-4281-b951-d872f2087c98
* Fix for a focus related unit-test on Linux toolkit views.jcampan@chromium.org2009-09-301-12/+13
| | | | | | | | | | | | | | | | The problem was caused by the way we were setting the focus, using grab_focus which does not work whenthe screen is locked. We now explicitly send a signal. Also make sure to give a good parent when building a child GtkWidget, as using the WidgetGtk native window would cause a Gtk error. BUG=23394 TEST=Run the unit-tests. R=oshima Review URL: http://codereview.chromium.org/242071 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27629 0039d316-1c4b-4281-b951-d872f2087c98
* Temporary disabling a unit test that fails on Linux toolkit views while I ↵jcampan@chromium.org2009-09-301-0/+6
| | | | | | | | | | | investigate. BUG=23394 TBR=huanr Review URL: http://codereview.chromium.org/251039 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27570 0039d316-1c4b-4281-b951-d872f2087c98
* Relanding the NativeViewHost refactoring (it was breaking the ChromeOS build). jcampan@chromium.org2009-09-291-1/+103
| | | | | | | | | | | | | | | Refactoring some of the NativeViewHost and NativeControl focus management so their consumers don't have to explicitly set the focused view. See original review: http://codereview.chromium.org/235011/show BUG=None TEST=Run all tests. Make sure focus is stored/restored properly in Chrome. TBR=ben Review URL: http://codereview.chromium.org/246032 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27563 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 27504, it breaks the interactive ui tests on Windows.jcampan@chromium.org2009-09-291-10/+1
| | | | | | | TBR=oshima Review URL: http://codereview.chromium.org/243034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27512 0039d316-1c4b-4281-b951-d872f2087c98
* See original review atjcampan@chromium.org2009-09-291-1/+10
| | | | | | | | | | | | | | http://codereview.chromium.org/251001/show This CL hooks the focus traversal for the TabbedPaneView on Linux with toolkit views. It also has few focus related fixed (focus with buttons, clearing focus effectively in the focus manager). BUG=None TEST=Run the view_examples app. Press tab to move the focus. Try the different tabs. Review URL: http://codereview.chromium.org/246030 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27504 0039d316-1c4b-4281-b951-d872f2087c98
* Relanding keyboard code refactoring:jcampan@chromium.org2009-09-292-4/+6
| | | | | | | | | | | | | | | | http://codereview.chromium.org/248010/show Changing the KeyboardEvent to use a KeyboardCode instead of a w_char. Led to several places where I had to switch from VK_ to VKEY_. Also cleaned-up the table view OnKeyDown method. Since TableView is a NativeControl it can use the NativeControl::OnKeyDown directly. BUG=None TEST=Make sure short-cuts works as expected, especially in the omnibox. Review URL: http://codereview.chromium.org/251020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27444 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 27412 it breaks the toolkit views Linux build.jcampan@chromium.org2009-09-282-6/+4
| | | | | | | TBR=sky Review URL: http://codereview.chromium.org/254005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27416 0039d316-1c4b-4281-b951-d872f2087c98
* Changing the KeyboardEvent to use a KeyboardCode instead of a w_char. Led to ↵jcampan@chromium.org2009-09-282-4/+6
| | | | | | | | | | | | several places where I had to switch from VK_ to VKEY_. Also cleaned-up the table view OnKeyDown method. Since TableView is a NativeControl it can use the NativeControl::OnKeyDown directly. BUG=None TEST=Make sure short-cuts works as expected, especially in the omnibox. Review URL: http://codereview.chromium.org/248010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27412 0039d316-1c4b-4281-b951-d872f2087c98
* [Relanding erg's change with fix for toolkit_views shortcuts and jcampan@chromium.org2009-09-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | interactive ui tests. Note that this was originally reviewed in http://codereview.chromium.org/217022/show I originally Elliot suggestion of replacing the usage of int for keycode with the bae::Keycode type, but that led to the CL getting out of hands (as this is used in many different places). So this is only the patch set 1 of that CL, I'll replace the type in another CL] Use windows keycodes under linux (and all non-windows platforms). This fixes any place where we use a VKEY_* (RenderWidgetHost, for example) under Linux, but breaks accelerators in TOOLKIT_VIEWS which relied on this wrong behaviour. Previously, keyboard_codes_linux defined all the VKEY_* constants as their GDK_* counterparts, which is wrong since the VKEY_* are supposed to resolve to windows key codes. BUG=22551 TEST=Make sure accelerators still work as expected on Chrome Linux and Chrome Linux with toolkit views. Test when the the accelerators with the focus in the location bar and also with the focus on the page. Review URL: http://codereview.chromium.org/235025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27284 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 27113, it breaks the ChomeOS build.jcampan@chromium.org2009-09-241-103/+1
| | | | | | | TBR=ben Review URL: http://codereview.chromium.org/231022 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27115 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-19 18:04:29 +0000