| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
BUG=chromium-os:17469
TEST=Click battery icon, confirm it meets spec
Review URL: http://codereview.chromium.org/7491083
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@96643 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
BUG=None
TEST=None
R=jeanluc@chromium.org
Review URL: http://codereview.chromium.org/7612011
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@96432 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ensure the display offset and cursor bounds are valid on use.
Build in offset logic to RenderText display and hit-testing.
Implement simpler temporary GetStringWidth and GetCursorBounds.
Fix SetDisplayRect signature, code file ordering, invalidation.
Rename and refactor a bit, update comments.
Fixes adornment display & hit testing on text field overflows.
Increases abstraction/encapsulation for easier client use.
BUG=90426
TEST=--use-pure-views / touch_ui textfield use with overflow.
Review URL: http://codereview.chromium.org/7466048
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@96334 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mousewheel events, like keyboard events and unlike other mouseevents, are sent
to the focused view from the focus-manager, instead of sending to the view at
the location of the LocatedEvent. So This needs to be handled from the
dekstop/window-manager to send the events to the focused window.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/7462017
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@96271 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
an external texture.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/7605024
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@96177 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gets added to the desktop.
This fixes sending keyboard events to the browser in views-desktop.
TBR=sky@chromium.org
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/7604024
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@96126 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
as views_delegate may not be initialized when touchui is set
BUG=none.
TEST=none.
Review URL: http://codereview.chromium.org/7529031
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@95940 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
BUG=none.
TEST=none.
Review URL: http://codereview.chromium.org/7491090
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@95847 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=WidgetObserverTest.ActivationChange
Review URL: http://codereview.chromium.org/7585028
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@95828 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
TEST=build with touchui=1, drag selection handles.
Review URL: http://codereview.chromium.org/7569024
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@95701 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
R=rvargas@chromium.org
Review URL: http://codereview.chromium.org/7550038
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@95651 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Moves temporary color definition to gfx, declares some function as virtual for override,
removes const from some functions so that the override function is able to modify local data.
2. Cache cursor bounds and compute it (along with display_offset_) when necessary.
3. Introduce SelectionModel (not derivable) for visual cursor positioning.
BUG=90426
TEST=--use-pure-views text editing
Review URL: http://codereview.chromium.org/7461102
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@95508 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/7465091
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@95282 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is necessary for updating selection on multiline text such as on a
webpage.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/7508018
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@95279 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a necessary refactoring to a single menu model to define both views menu and WebUI menu.
BUG=chromium-os:17892
TEST=none
Review URL: http://codereview.chromium.org/7541002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@95244 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=None
TEST=gold doesn't complaint about multiple definitions for views::MenuWrapper::CreateWrapper when linking libviews.so
Review URL: http://codereview.chromium.org/7466054
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@95233 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
interface. We want this functionality on views textfields as well as the
webpage. This CL lays out the ground work and implements the text selection
interface for view textfield. In a later CL, I intend to implement the
TextSelection Interface for RenderWidgetHostViewViews.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/7465045
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@95186 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For reasonss that are not entirely clear, Browser::GetSavedMaximizedState() is sometimes setting maximized to true for panels created by an extension on ChromeOS.
Since panels have no concept of a maximized state, fix this by always returning 'false'.
This also includes a patch to widget.cc that is not necessary to fix this behavior, but it fixes the case where ShowInactive gets called when the widget is maximized (which shouldn't normally happen).
BUG=chromium-os:18534
TEST=See issue + test opening panels from an extension
Review URL: http://codereview.chromium.org/7551002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@95141 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove unnecessary gfx namespace specifiers.
This should restore the large font size, and render the cursor and selection in their correct positions.
BUG=90426
TEST=touchui omnibox text interaction.
Review URL: http://codereview.chromium.org/7540036
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@95118 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use Widget|View::GetFocusManager instead.
Use Widget::Get[TopLevel]WidgetForNativeView|Window as necessary.
BUG=88718
TEST=none
Review URL: http://codereview.chromium.org/7532015
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@95111 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=None
TEST=None
R=sky@chromium.org
Review URL: http://codereview.chromium.org/7552005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@95088 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
All 'low-hanging' platform_canvas.h dependencies have been removed, and replaced with skia-specific includes.
BUG=None
TEST=None
Review URL: http://codereview.chromium.org/7517020
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@95083 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the tooltip after the menu has been closed. This is likely because
we're using close and not closenow, which means hide/closenow. Using
closenow may have timing issues here, so I'm going with this fix.
BUG=90860
TEST=none
R=rhashimoto@chromium.org
Review URL: http://codereview.chromium.org/7545011
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94980 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/7488058
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94797 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Activate a widget when it is touched.
* Drop a synthetic mouse event on the toplevel widget instead of the immediate
parent widget.
* Send touch-events to the captured view if there is one.
BUG=none
TEST=manually
Review URL: http://codereview.chromium.org/7540002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94796 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
menu while it's already showing.
BUG=90862
TEST=none
R=rhashimoto@chromium.org
Review URL: http://codereview.chromium.org/7529026
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94752 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
just a proof of concept. Next step is going to be pulling code from
the window manager into this. Desktop will likely be renamed to
WindowManager.
At this point just make sure you think I'm not going off into the
weeds.
BUG=none
TEST=none
R=derat@chromium.org
Review URL: http://codereview.chromium.org/7534002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94733 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
menu is trying to exit the nested message loop.
BUG=90860
TEST=none
R=rhashimoto@chromium.org
Review URL: http://codereview.chromium.org/7474005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94732 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A simple 3D CSS benchmark shows a 20% improvement in framerate on T25 hardware: an increase from about 30 fps to 36 fps.
This is a first pass to getting rid of double painting by introducing a hole in layers Currently a layer which wants its parent not to paint under it will call SetParentLayerHoley
There are a number of questions in terms of implementation:
1) We are doing this with layers. We are currently setting all layers to be holey if the touch_ui flag is enabled. Another option is to merge the holey functionality into regular layers. (Get rid of the holey layer subclass)
2) We are always generating vertices matrix, even in the ui::Layer case, is this ok?
3) We are wasting video memory. We are still uploading a full bitmap. I wasn't able to find a function call which would be able to efficiently slice the bigger bitmap, notably changing the origin of where the painting starts (texture upload)
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@91848 0039d316-1c4b-4281-b951-d872f2087c98
BUG=
TEST=
Review URL: http://codereview.chromium.org/7330025
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94677 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=manually, build works with 'chromeos=1 touchui=1 component=shared_library'
Review URL: http://codereview.chromium.org/7524028
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94498 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
views::TooltipWindowGtk and views::SmoothedThrobber are referenced by
ChromeOS UI code, but not exported in views.
BUG=None
TEST=chromeos=1 builds don't fail linking
Review URL: http://codereview.chromium.org/7523026
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94489 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem this CL addresses is that the parent for a NativeWidgetViews-backed widget must be specified as a Widget and not a View. This produces inconsistent results for views_examples because on Linux each tab is a Widget but on Windows each tab is only a View. The result on Windows is that the NativeWidgetViews test goes on the 0th child of the Widget contents, which is the check box tab.
BUG=chromium:88716
TEST=run views_examples on Windows, NativeWidgetViews should be on proper tab
Review URL: http://codereview.chromium.org/7517015
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94484 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In views-desktop, if you click on a window once, all the subsequent click events
go to that window until it is closed. This is a fix for that. I have updated the
relevant test to catch such errors.
BUG=none
TEST=WidgetTest.GrabUngrab
Review URL: http://codereview.chromium.org/7519006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94479 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
R=sky@chromium.org,rvargas@chromium.org
Review URL: http://codereview.chromium.org/7493017
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94428 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem was that I was unconditionally calling set_delete_native_widget() from the NativeWidgetViews destructor, which is wrong if the NativeWidgetView has already been destroyed with its view hierarchy. The unconditional call is correct in the NativeWidgetView destructor because it must prevent itself from being deleted again even if it does not delete the NativeWidgetViews (WIDGET_OWNS_NATIVE_WIDGET case) and is safe because the NativeWidgetViews lifetime is always longer than its NativeWidgetView.
BUG=chromium:90484
TEST=valgrind out/Debug/views_unittests --gtest_filter="WidgetOwnershipTest.*ViewsNativeWidget*" --single-process
Review URL: http://codereview.chromium.org/7461082
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94336 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
Fix TestTexture and ViewLayerTest compile.
BUG=90548
TEST=none
Review URL: http://codereview.chromium.org/7470030
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94241 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the API can fabricate a key event which is supported by src/ui/base/keycodes/keyboard_codes_posix.h. This means the API only supports ASCII characters (<= 0x7f).
However, since some i18n virtual keyboards need to call the API to generate a key event which is not supported by the header, it'd be better to relax the limitation. For example, French virtual keyboard might call the API with U+00E1 (LATIN SMALL LETTER A WITH ACUTE), Russian one might do it with U+0410 (CYRILLIC CAPITAL LETTER A).
BUG=chromium-os:18048
TEST=run browser_tests
Review URL: http://codereview.chromium.org/7473025
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94236 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
BUG=chromium-os:17013
TEST=Open two windows on device, open wrench menu, use Alt-Tab to switch windows and check that menu closes.
Review URL: http://codereview.chromium.org/7484048
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94212 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
assertion/closing menu. The problem is the code was checking the
current MenuItemView against the sibling's MenuItemView. This meant if
a submenu was selected and you moused over the menu button we would
get confused and attempt to show a menu we're already showing,
resulting in assertions/closing the menu.
BUG=none
TEST=none
R=rhashimoto@chromium.org
Review URL: http://codereview.chromium.org/7495040
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94166 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=None
TEST=None
Review URL: http://codereview.chromium.org/7477008
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94115 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/7493004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94114 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, check view_ for NULL in a few places because these functions can be called
when the NWViews is in the process of closing and view_ may have already been
unset.
This fixes a crash when closing chrome in --views-desktop world.
BUG=none
TEST=start chrome with --views-dekstop and close, chrome shouldn't crash.
Review URL: http://codereview.chromium.org/7480017
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94112 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=72040
TEST=views_unittests, views_examples, views_desktop
R=sky@chromium.org
Review URL: http://codereview.chromium.org/7471048
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94092 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=none. no functional change and all tests should pass.
Review URL: http://codereview.chromium.org/7489035
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@94046 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that the native text button appears more like a windows button.
BUG=90229
TEST=Open a dialog or popup with a button control. Use the tab key to place
the focus on the button. Make sure the focus border, which is black dotted
line, appears inset into the button as shown in the bug desription.
Review URL: http://codereview.chromium.org/7484045
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@93941 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
maximize, minimize, size and restore could be properly enabled/disabled.
Patch from Hui Guo <guohui@chromium.org>
BUG=73158
TEST=Right click the caption of About Chrome dialog
Review URL: http://codereview.chromium.org/7481002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@93928 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This began with a partial revert of r92246
(http://codereview.chromium.org/7348011/), which affected how a
NativeWidgetViews was destroyed.
The issue with the r92246 code was that whenever a View hierarchy
containing the NativeWidgetView was removed from a parent, destruction
was invoked via ViewHierarchyChanged(). This behavior was wrong when
a View hierarchy containing a NativeWidgetViews was just being moved,
e.g. when TabContentsContainer::ChangeTabContents() was called.
A fix was attempted by not responding to ViewHierarchyChanged() except
when detached by the direct parent, but this doesn't work properly
because ViewHierarchyChanged() is not called for all child removals done
by a destructor so the widget would be leaked.
This CL restores NativeWidget{View,Views} each deleting the other in their destructor when NATIVE_WIDGET_OWNS_WIDGET. If WIDGET_OWNS_NATIVE_WIDGET then NativeWidgetView is not allowed to delete NativeWidgetViews, leaving that for the Widget.
BUG=none
TEST=views_unittests
Review URL: http://codereview.chromium.org/7464035
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@93903 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes issue where NativeTabbedPaneGtk gets retained by the top-level FocusManager during the Widget::Close tear-down sequence. This fix clears focus before proceeding with the tear-down. This avoids redundant operations with the FocusManger as views get deleted, specifically in the FocusManager::ViewRemoved() call.
Caught by Valgrind as a use after free violation:
sh tools/valgrind/chrome_tests.sh views --gtest_filter=FocusManagerTest.FocusNativeControls
BUG=89596
TEST=tools/valgrind/chrome_tests.sh views --gtest_filter=FocusManagerTest.FocusNativeControls
Review URL: http://codereview.chromium.org/7468037
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@93894 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bit more correctly.
I was hoping this would fix the dcheck backer is hitting, but it doesn't.
BUG=none
TEST=none
R=oshima@chromium.org,sadrul@chromium.org
Review URL: http://codereview.chromium.org/7439012
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@93879 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
RenderText is NativeTextFieldViews' interface to platform-specific text rendering engines.
This change doesn't hook in any new Pango or Uniscribe functionality, it will just setup the necessary API.
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=93840
Review URL: http://codereview.chromium.org/7265011
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@93855 0039d316-1c4b-4281-b951-d872f2087c98
|