summaryrefslogtreecommitdiffstats
path: root/ui
Commit message (Collapse)AuthorAgeFilesLines
* Merge 245681 "Fix a page responsive dialog showing up in Chrome ..."ananta@chromium.org2014-01-211-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | > Fix a page responsive dialog showing up in Chrome Desktop Windows Aura if we hovered or clicked on the portion of the window > where the OS thinks that there is a native scrollbar. > > We fake the scrollbar styles on top level windows in Chrome Windows Desktop Aura to ensure that trackpoint and trackpad > scrolling works. We hide the Windows scrollbars to ensure that we don't see two scrollbars on the window, one drawn by Webkit > and one by Windows. > > If we hover/click on the area of the window where the scrollbars would be drawn, the default WM_NCHITTEST returned by the OS > is HTVSCROLL or HTHSCROLL. This then results in non client mouse messages being delivered to the renderer which does not ack them > leading to the dialog showing up. > > As we dont't have Windows native scrollbars in Windows Desktop Aura, we can safely return HTCLIENT for these hittests. I gave a local build to QA to test. Worked fine > with the following tests > 1. Inspector popped in and out of Chrome > 2. Page resizing, tab dragging, etc. > 3. Task manager, bookmark tree view > > This change should not cause any major fires. If it does, will consider reverting the scrollbar hack and look into another approach. > > BUG=335248 > R=cpu@chromium.org > TBR=sky > > Review URL: https://codereview.chromium.org/131743025 TBR=ananta@chromium.org Review URL: https://codereview.chromium.org/138083003 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@246171 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 245651 "Add support for horizontal mouse wheel messages in..."ananta@chromium.org2014-01-211-2/+6
| | | | | | | | | | | | | | | | | | > Add support for horizontal mouse wheel messages in Windows Desktop Aura. > > This is simply a matter of recognizing the WM_MOUSEHWHEEL message as a valid mouse wheel message. > Tested this on web pages with horizontal scrollbars and it works well. > > BUG=332797 > R=sky@chromium.org, sky > > Review URL: https://codereview.chromium.org/140653006 TBR=ananta@chromium.org Review URL: https://codereview.chromium.org/137273008 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@246170 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 245289 "Relanding this as this caused layout tests failure..."ananta@chromium.org2014-01-212-29/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | > Relanding this as this caused layout tests failures on Win7 due to the call to ShowScrollBars being incorrectly deleted > in the HWNDMessageHandler::OnSize for a regular WM_SIZE. Added that call back. The rest of the CL is exactly the same as > the previous one. TBR'ing sky. > > Don't set the scroll styles (WS_VSCROLL and WS_HSCROLL) for WS_POPUP windows. > > This causes issues with select boxes on Windows 7 where hovering at the end of the window returns the scroll WM_NCHITTEST > codes. Works fine on Windows 8. In any case we don't want the scrolling styles set on windows other than the main Chrome window > which is the only window which should be receive mousewheel messages. > > I moved the scroll style setting code from the HWNDMessageHandler::OnCreate function to HWNDMessageHandler::Init function as that > would prevent the initial WM_SIZE message from hiding the scrollbar. The other change is to hide the scrollbars and readd the > scroll styles if we are sizing the window, when the sizing completes. Basically when we receive the WM_EXITSIZEMOVE message. > For normal sizing operations we continue to do this in WM_SIZE as before. > > From testing on my thinkpad with Win7, desktop with Win7 and Win8 this works well > > BUG=334454, 334541 > TBR=sky > > Review URL: https://codereview.chromium.org/133273020 TBR=ananta@chromium.org Review URL: https://codereview.chromium.org/144403003 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@246169 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 245156 "Fix omnibox height when less than 64 pixels tall."jbauman@chromium.org2014-01-213-22/+28
| | | | | | | | | | | | | | | | > Fix omnibox height when less than 64 pixels tall. > > Ensure there's always a HandleClientSizeChanged call that happens when the bounds change (even if that doesn't cause the actual bounds of the HWND to change), as otherwise the view size will be stale. > > BUG=330123 > > Review URL: https://codereview.chromium.org/138073004 TBR=jbauman@chromium.org Review URL: https://codereview.chromium.org/143003009 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@246165 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 245641 "Merge 244330 "Have browser process shutdown metro..."karen@chromium.org2014-01-182-14/+0
| | | | | | | | | | | | | | | | | | | | | | > Merge 244330 "Have browser process shutdown metro viewer on Metr..." > > > Have browser process shutdown metro viewer on Metro -> Metro restart. > > > > Metro -> Metro restarts can happen as a result of changing about:flags, or a chrome update. In order for the metro viewer to exit, it is necessary for the browser to notify the metro viewer that it needs to close itself. This was happening for Metro -> Desktop restarts, but not for Metro -> Metro restarts. > > > > BUG=332063 > > > > Review URL: https://codereview.chromium.org/130223002 > > TBR=zturner@chromium.org > > Review URL: https://codereview.chromium.org/141273012 TBR=zturner@chromium.org Review URL: https://codereview.chromium.org/131513007 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@245672 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 244330 "Have browser process shutdown metro viewer on Metr..."zturner@chromium.org2014-01-172-0/+14
| | | | | | | | | | | | | | | | > Have browser process shutdown metro viewer on Metro -> Metro restart. > > Metro -> Metro restarts can happen as a result of changing about:flags, or a chrome update. In order for the metro viewer to exit, it is necessary for the browser to notify the metro viewer that it needs to close itself. This was happening for Metro -> Desktop restarts, but not for Metro -> Metro restarts. > > BUG=332063 > > Review URL: https://codereview.chromium.org/130223002 TBR=zturner@chromium.org Review URL: https://codereview.chromium.org/141273012 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@245641 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 244295 "Ensure that trackpad and trackpoint scrolling work..."ananta@chromium.org2014-01-168-9/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | > Ensure that trackpad and trackpoint scrolling works on Windows desktop Aura with legacy trackpad drivers. > > Legacy trackpad drivers like the older synaptics drivers have bugs where in they don't generate the WM_MOUSEWHEEL > messages for applications unless there is an entry for the application with the class name of the window in their > config file. If an entry does not exist here, these drivers expect the window to have the WS_VSCROLL/WS_HSCROLL style > to generate the legacy WM_VSCROLL/WM_HSCROLL messages. > > This patch adds these styles to top level windows for Windows Aura. To ensure that Windows does not draw these > scrollbars, we hide them when the window size changes and readd them in a posted task which works correctly in our > testing. > > Changes in this patch are as below:- > 1. Add handlers to the HWNDMessageHandler class for the WM_VSCROLL/WM_HSCROLL messages. > 2. Forward the scroll events to the HWNDMessageHandlerDelegate which then forwards it off to its delegate. > 3. Miscellaneous fixes in the events code to allow the WM_VSCROLL/WM_HSCROLL messages to go through. > > BUG=320849 > R=cpu@chromium.org, sky@chromium.org, cpu, sky > > Review URL: https://codereview.chromium.org/133053004 TBR=ananta@chromium.org Review URL: https://codereview.chromium.org/138143012 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@245057 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 243442 "Relanding this change with the DesktopAuraTopLevel..."ananta@chromium.org2014-01-162-1/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | > Relanding this change with the DesktopAuraTopLevelOwnedPopupResizeTest enabled only for Windows. > > Revert 243438 "Revert 243413 "Resize the widget when top level p..." > > > Revert 243413 "Resize the widget when top level popup windows cr..." > > > > > Resize the widget when top level popup windows created by the content layer are resized. > > > > > > The content layer creates top level popup windows, for select items on a page for e.g. When these > > > windows are resized we need to resize the parent widget hosting them. > > > > > > BUG=330596 > > > TEST=Covered by views test DesktopAuraTopLevelOwnedPopupResizeTest > > > R=sky@chromium.org > > > > > > Review URL: https://codereview.chromium.org/125203005 > > > > TBR=ananta@chromium.org > > > > Review URL: https://codereview.chromium.org/127073003 > > TBR=ccameron@chromium.org > > Review URL: https://codereview.chromium.org/127163002 TBR=ananta@chromium.org Review URL: https://codereview.chromium.org/139833005 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@245055 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 244538 "Don't populate URL data in WebDropData when draggi..."dcheng@chromium.org2014-01-169-15/+43
| | | | | | | | | | | | | | | | | > Don't populate URL data in WebDropData when dragging files. > > This is considered a potential security issue as well, since it leaks > filesystem paths. > > BUG=332579 > > Review URL: https://codereview.chromium.org/135633002 TBR=dcheng@chromium.org Review URL: https://codereview.chromium.org/137783015 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@245053 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 244064 "Revert partially "cros: Use AlertDialog for remora..."mtomasz@chromium.org2014-01-141-5/+2
| | | | | | | | | | | | | | | | | | > Revert partially "cros: Use AlertDialog for remora device requisition." > > This reverts the webui change from the commit 9cc0da7de2e00c403bb2672762009148e1846078 (https://codereview.chromium.org/61523002/). > The reverted webui change breaks alert dialogs in the Files app by making them not closable by pressing the Escape key. > > TEST=Tested manually in Files app. > BUG=330835, 331739 > > Review URL: https://codereview.chromium.org/129973002 TBR=mtomasz@chromium.org Review URL: https://codereview.chromium.org/137533007 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@244626 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 240827 "DesktopNativeCursorManager currently only has "tdanderson@google.com2014-01-089-175/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See issue 332477 for a description of the revert. > DesktopNativeCursorManager currently only has > knowledge of a single RootWindow, which means > that it is possible for a change in cursor state > within one RootWindow to cause another RootWindow > to have a stale cursor state. This CL makes changes > in cursor state global among all root windows > by doing the following: > > - Make CursorManager and DesktopNativeCursorManager > static members of DesktopNativeWidgetAura. > - Maintain a set of root windows in > DesktopNativeCursorManager. > - When a native widget is initialized, add its > owned root window to this set. When a native > widget is destroyed, remove its owned root window > from this set. > - Whenever a call to the public CursorClient API > causes a change in cursor state, inform all root > windows in this set. > > This change makes cursor management for desktop > Aura behave similar to cursor management in Ash, > where all root windows are already notified of > cursor state changes. > > BUG=324006 > TEST=DesktopNativeWidgetAuraTest.GlobalCursorState > > Review URL: https://codereview.chromium.org/111043002 BUG=332477 TBR=tdanderson@chromium.org Review URL: https://codereview.chromium.org/129613002 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@243665 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 240976 "Invoke cursor-hiding logic on touch for Windows"tdanderson@google.com2014-01-082-10/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See issue 332477 for a description of this revert. > Invoke cursor-hiding logic on touch for Windows > > Continue to invoke cursor-hiding logic on touch > for Windows even though the OS hides the cursor > for us. The reason is that this code path is > needed in order to call > RenderWidgetHostViewAura:: > NotifyRendererOfCursorVisibilityState() > in order for the renderer to know to suppress > generation of synthetic mousemove events > while touch scrolling. This avoids unwanted > hover effects from being invoked when the > cursor is not visible. > > To avoid regressions in behavior (such as > the one mentioned in > https://codereview.chromium.org/56053004), > make the cursor state global among all > root windows. This is done in > https://codereview.chromium.org/111043002/. > > BUG=322250 > TEST=To be added later (crbug.com/328549) > R=sky@chromium.org > > Review URL: https://codereview.chromium.org/82463002 BUG=332477 TBR=tdanderson@google.com Review URL: https://codereview.chromium.org/129353003 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@243661 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 243261 "Revert "Retain tray bubble's rounded corners when ..."michaelpg@chromium.org2014-01-083-33/+47
| | | | | | | | | | | | | | | | | > Revert "Retain tray bubble's rounded corners when the bubble animates out" > > This reverts commit 7b1cac3592db1009adf4e11c2d9f87a81626630f. > BUG=330744, 330745, 331852 > TBR=piman@chromium.org, msw@chromium.org > > Review URL: https://codereview.chromium.org/125433002 TBR=michaelpg@chromium.org Review URL: https://codereview.chromium.org/128913002 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@243603 0039d316-1c4b-4281-b951-d872f2087c98
* Updating XTBs based on .GRDs from branch 1750laforge@chromium.org2014-01-0695-2/+545
| | | | git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@243198 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 242517 "Bug fix: Translate New UX: Stop consuming an Enter..."hajimehoshi@chromium.org2014-01-062-0/+21
| | | | | | | | | | | | | | | > Bug fix: Translate New UX: Stop consuming an Enter/Space key event when the combobox's style is not STYLE_NOTIFY_ON_CLICK. > > BUG=329995 > TEST=views_unittests --gtest_filter=ComboboxTest.* > > Review URL: https://codereview.chromium.org/119853002 TBR=hajimehoshi@chromium.org Review URL: https://codereview.chromium.org/114693004 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@243051 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 241955 "Make extensions icons easier to target with gestures"tdanderson@google.com2013-12-206-69/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | > Make extensions icons easier to target with gestures > > The bounds of a BrowserActionView and the bounds > of its child view |button_| have the following > properties: > > - Both share a common center point. > - The bounds of |button_| are square, but the > bounds of BAV are not. > - The bounds of |button_| are contained within > the bounds of BAV. > - Both are small enough to be easily covered > by a finger. > > This is a flaw in rect-based targeting > making it difficult to correctly target > |button_| with a tap gesture. To obtain the > desired behavior, use the distance > between the center of the touch and the center > of the view (instead of the center line of > the view) to break ties among rect-based > targeting candidates. > > The use of the distance to center line was > to avoid biases against wide or tall views. > But this is not necessary because any view > which can have at least 60% of its area > covered by a touch cannot be sufficiently wide > or tall enough to benefit from such a metric. > > BUG=328182 > > Review URL: https://codereview.chromium.org/94003003 TBR=tdanderson@chromium.org Review URL: https://codereview.chromium.org/108283008 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@242156 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 241746 "Truncating X event's coordinate instead of rounding"oshima@chromium.org2013-12-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | > Truncating X event's coordinate instead of rounding > > In CL https://codereview.chromium.org/69653002 > I was thinking using rounding instead of truncating when converting > X event's coordinate to ui::TouchEvent's location seems more correct. > But it introduces the bug that an edge event can be rounded to location > that is out of bounds, e.g. rightmost X event's x position on Pixel is > 2559, and it gets divided by device scale factor of 2 so becomes > 1279.5 and rounded to be 1280, which is out of bounds. > So lets revert to the truncating behavior. > > BUG=328151 > TEST=follow the test at #1 & #5 at crbug.com/328151 and make sure > the issue is fixed. > > Review URL: https://codereview.chromium.org/118423003 TBR=miletus@chromium.org Review URL: https://codereview.chromium.org/112423005 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@241903 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 241355 "Possible fix for use of Window after deleted"sky@chromium.org2013-12-182-7/+107
| | | | | | | | | | | | | | | | | | | | | | | | > Possible fix for use of Window after deleted > > An ActivationChangeObserver is trying to use the window supplied to > OnWindowActivated. It seems as though the window is not valid; most > likely deleted. I'm guessing an earlier ActivationChangeObserver > deleted it. > > This change makes it so that if an ActivationChangeObserver deletes a > window we supply NULL to future ActivationChangeObservers. > > BUG=328468 > TEST=covered by test > R=ben@chromium.org > > Review URL: https://codereview.chromium.org/115463004 TBR=sky@chromium.org Review URL: https://codereview.chromium.org/99553003 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@241672 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 241586 "aura: Early out when there is no held event to dis..."sadrul@chromium.org2013-12-181-0/+3
| | | | | | | | | | | | | | | > aura: Early out when there is no held event to dispatch. > > BUG=328603 > R=sky@chromium.org > > Review URL: https://codereview.chromium.org/116553006 TBR=sadrul@chromium.org Review URL: https://codereview.chromium.org/117343006 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@241618 0039d316-1c4b-4281-b951-d872f2087c98
* Support mouse cursor in DesktopCaptureDeviceAura.hshi@chromium.org2013-12-172-0/+31
| | | | | | | | | | | | | Perform an in-place alpha blending of an ARGB cursor bitmap on a YUV420 video frame. BUG=326000 R=oshima@chromium.org, sergeyu@chromium.org TBR=ben@chromium.org TEST=mouse cursor rendered correctly (position, shape and scale) during destkop sharing on Chrome OS. Review URL: https://codereview.chromium.org/108193015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@241106 0039d316-1c4b-4281-b951-d872f2087c98
* Optimize png files under ash/resources, ui/resourcesoshima@chromium.org2013-12-1728-0/+0
| | | | | | | | | | | | | | $ /tmp/optimize-png-files.sh -s -o2 -r 232777 ash/resources/ ui/resources/ Processed 35 files (out of 159 files) in 00:10:29s Result : 38333 => 24386 bytes (13947 bytes : 36 %) BUG=313730 R=jamescook@chromium.org Review URL: https://codereview.chromium.org/114003004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@241098 0039d316-1c4b-4281-b951-d872f2087c98
* Revert of https://codereview.chromium.org/107513011/szym@chromium.org2013-12-165-312/+82
| | | | | | | | | | | | | Reason for revert: Test fails on main waterfall. TBR=jshin@chromium.org,msw@chromium.org,pkasting@chromium.org,skanuj@chromium.org NOTREECHECKS=true NOTRY=true BUG=327833 Review URL: https://codereview.chromium.org/103053014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@241050 0039d316-1c4b-4281-b951-d872f2087c98
* A trivial style fixyukawa@chromium.org2013-12-161-2/+2
| | | | | | | | | BUG=none TEST=none Review URL: https://codereview.chromium.org/116433002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@241034 0039d316-1c4b-4281-b951-d872f2087c98
* Implement eliding/truncating at end in RenderTextskanuj@chromium.org2013-12-165-82/+312
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | patch from issue 112063003 The eliding is determined using binary search similar to the ElideText in ui/gfx/text_elider.cc. The mixed LTR-RTL handling for ellipsis is done using LTR/RTL markers. There is no other way of rendering the ellipsis with the directionality of preceding strong-directional characters. Previous scheme worked because it rendered LTR and RTL sub-strings as different RenderText instances. Added helper method to be able to determine directionality of the trailing text. Made StringSlicer used by text_elider.cc public to be shared by RenderText. Additional Fix: - Call UpdateLayoutText from SetDisplayRect. - Disable erratic tests on versions of windows older than Vista. BUG=327833 TEST=ui_unittests,base_unittests R=msw@chromium.org TBR=jshin@chromium.org,pkasting@chromium.org Review URL: https://codereview.chromium.org/107513011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@241000 0039d316-1c4b-4281-b951-d872f2087c98
* rAc: open info bubbles only within the dialog using existing logic.dbeam@chromium.org2013-12-165-44/+38
| | | | | | | | | | | | Kills some duplicated logic and fixes vertical positioning. R=msw@chromium.org BUG=322816 NOTRY=true Review URL: https://codereview.chromium.org/115483004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240984 0039d316-1c4b-4281-b951-d872f2087c98
* Invoke cursor-hiding logic on touch for Windowstdanderson@google.com2013-12-162-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Continue to invoke cursor-hiding logic on touch for Windows even though the OS hides the cursor for us. The reason is that this code path is needed in order to call RenderWidgetHostViewAura:: NotifyRendererOfCursorVisibilityState() in order for the renderer to know to suppress generation of synthetic mousemove events while touch scrolling. This avoids unwanted hover effects from being invoked when the cursor is not visible. To avoid regressions in behavior (such as the one mentioned in https://codereview.chromium.org/56053004), make the cursor state global among all root windows. This is done in https://codereview.chromium.org/111043002/. BUG=322250 TEST=To be added later (crbug.com/328549) R=sky@chromium.org Review URL: https://codereview.chromium.org/82463002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240976 0039d316-1c4b-4281-b951-d872f2087c98
* Refactors the flick logic on the virtual keyboard.rsadam@chromium.org2013-12-163-25/+40
| | | | | | | | BUG= Review URL: https://codereview.chromium.org/115353002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240960 0039d316-1c4b-4281-b951-d872f2087c98
* Call OnCaretBoundsChanged in InputMethodBridge::OnFocuskomatsu@chromium.org2013-12-161-1/+3
| | | | | | | | | | | | | | When a new window is opened, the caret focus is moved in the Omnibox of the new window. However, this focus motion was not propagated to IME, because OnCaretBoundsChanged was not called in InputMethodBridge::OnFocus. It caused a bug of the mode indicator (328232). This patch fixes it. BUG=328232 Review URL: https://codereview.chromium.org/114953004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240956 0039d316-1c4b-4281-b951-d872f2087c98
* aura: Post non-nestable tasks for dispatching held/repostable events.sadrul@chromium.org2013-12-162-3/+81
| | | | | | | | | | | | | | | | | | | | | A context menu starts a nested message-loop. If a context menu is closed in response to a right-click outside the bounds of the menu, then the mouse-press event is reposted (so that the event reaches the view under the cursor), the menu is closed, and the nested message-loop is terminated. While the message-loop unwinds on its way to be closed, it triggers the posted-task of reposting the event. If this reposted right-click causes another context menu to show up (with its own nested message-loop), then we actually end up with a nested message-loop inside another nested loop. This can cause nested message-loops of depth n for n right-clicks (each of which causes a context menu). So instead of this madness, post the task of dispatching the held/ repostable event in a non-nestable task, so that it gets triggered only after the nested loop unwinds completely and is terminated. BUG=328603 R=sky@chromium.org Review URL: https://codereview.chromium.org/108653005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240928 0039d316-1c4b-4281-b951-d872f2087c98
* Rename View::set_focusable and View::set_accessibility_focusablemohsen@chromium.org2013-12-1639-89/+101
| | | | | | | | | | | | | These functions are renamed to SetFocusable and SetAccessibilityFocusable, respectively, as a first step to add some functionality to them later. Later the view should give up focus if it has become unfocusable. BUG=323956 Review URL: https://codereview.chromium.org/103493005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240888 0039d316-1c4b-4281-b951-d872f2087c98
* DesktopNativeCursorManager currently only has tdanderson@chromium.org2013-12-149-30/+175
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | knowledge of a single RootWindow, which means that it is possible for a change in cursor state within one RootWindow to cause another RootWindow to have a stale cursor state. This CL makes changes in cursor state global among all root windows by doing the following: - Make CursorManager and DesktopNativeCursorManager static members of DesktopNativeWidgetAura. - Maintain a set of root windows in DesktopNativeCursorManager. - When a native widget is initialized, add its owned root window to this set. When a native widget is destroyed, remove its owned root window from this set. - Whenever a call to the public CursorClient API causes a change in cursor state, inform all root windows in this set. This change makes cursor management for desktop Aura behave similar to cursor management in Ash, where all root windows are already notified of cursor state changes. BUG=324006 TEST=DesktopNativeWidgetAuraTest.GlobalCursorState Review URL: https://codereview.chromium.org/111043002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240827 0039d316-1c4b-4281-b951-d872f2087c98
* Remove uses of WebGraphicsContext3D from ui/compositorjamesr@chromium.org2013-12-148-48/+34
| | | | | | | | | | | | | | This removes all uses of blink::WebGraphicsContext3D as the context type from ui/compositor/ and dependent code, excluding some test harness setup. The compositor implementation uses gpu::gles2::GLES2Interface*, defined in gpu/command_buffer/client/, as the context type to avoid dependencies on the blink repository. BUG=181120 Review URL: https://codereview.chromium.org/107513008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240826 0039d316-1c4b-4281-b951-d872f2087c98
* [Android] Allow the intent to be cancelled.aruslan@chromium.org2013-12-142-4/+29
| | | | | | | | | | | showCancelableIntent() could be used to get a request code for cancelIntent(int). BUG=328205 Review URL: https://codereview.chromium.org/100173007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240823 0039d316-1c4b-4281-b951-d872f2087c98
* Show the download cancellation confirmation on relaunch to desktop.zturner@chromium.org2013-12-133-31/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The issue is that previously, in response to the menu click handler, we were attempting to show the Confirmation dialog (which is asynchronous), and then sending a message to the metro viewer to activate the desktop. This notification would terminate the metro viewer process, so the dialog would never be displayed. The fix is to only send the message to the metro viewer after we determine that it's safe to close (either because the user clicked yes on the cancel dialog, or because there were no pending downloads to begin with). It was necessary for me to remove a DCHECK from the StartPageService::ProfileDestroyObserver. The service's profile member was non NULL and the the one being passed in as the notification details was null. I suspect I will need to fix this, but I spent a while looking over the code and it was not obvious to me how this shutdown flow works, or even if this was a valid DCHECK(), so I would like to get some input from apps people on this point. BUG=315924 R=ananta@chromium.org, jschuh@chromium.org, sky@chromium.org, tapted@chromium.org Review URL: https://codereview.chromium.org/108773002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240730 0039d316-1c4b-4281-b951-d872f2087c98
* [Input View] Restores the keyboard size to default when switching to default ↵shuchen@chromium.org2013-12-131-0/+6
| | | | | | | | | | | keyboard url. BUG=316524 TEST=Locally verified in sandbox. Review URL: https://codereview.chromium.org/98203011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240708 0039d316-1c4b-4281-b951-d872f2087c98
* Revert of https://codereview.chromium.org/112063003/szym@chromium.org2013-12-135-289/+78
| | | | | | | | | | | | Reason for revert: RenderTextTest.ElidedText fails on XP Tests (3) TBR=msw@chromium.org,pkasting@chromium.org,jshin@chromium.org,skanuj@chromium.org NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/103493003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240694 0039d316-1c4b-4281-b951-d872f2087c98
* aura: Start using EventPrcessor interface for event dispatch.sadrul@chromium.org2013-12-138-52/+125
| | | | | | | | | | | | | | | Start converting the RootWindowHostDelegate implementations for event-dispatch use the EventProcessor interface under-the-hood to allow easy transition to the new dispatch process. This patch makes this change for Key and Scroll events. BUG=318879 R=ben@chromium.org Review URL: https://codereview.chromium.org/113283005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240683 0039d316-1c4b-4281-b951-d872f2087c98
* Fix the Views UI example.eranm@google.com2013-12-131-0/+2
| | | | | | | | | | | Otherwise the binary crashes because: [1212/100331:FATAL:input_method_auralinux.cc(54)] Check failed: LinuxInputMethodContextFactory::instance(). BUG=328052 Review URL: https://codereview.chromium.org/113783003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240648 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes inverted keys regression and adds a unit test.rsadam@chromium.org2013-12-132-10/+11
| | | | | | | | BUG=327551 Review URL: https://codereview.chromium.org/111643003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240634 0039d316-1c4b-4281-b951-d872f2087c98
* Add focus button images for a combobox with a button stylehajimehoshi@chromium.org2013-12-13146-11/+58
| | | | | | | | | BUG=305494 TEST=manual Review URL: https://codereview.chromium.org/111343003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240632 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 240602 "Use the caret bounds as a fallback when GetCompos..."jochen@chromium.org2013-12-131-16/+11
| | | | | | | | | | | | | | | | | | | | | | | Broke RemoteInputMethodWinTest.OnCaretBoundsChanged base\ime\remote_input_method_win_unittest.cc(423): error: Value of: mock_remote_delegate.composition_character_bounds() > Use the caret bounds as a fallback when GetCompositionCharacterBounds is not available > > This CL fixes a positional issue of IMEs' candidate window on PPAPI Flash running under Ash mode. > > The root cause is that PPAPI does not support TextInputClient::GetCompositionCharacterBounds at all. We once worked around this in Issue 148903 but the Win/Ash backend lacked of this treatment. > > BUG=328237 > TEST=manually done on Windows 8.1 > > Review URL: https://codereview.chromium.org/109323009 TBR=yukawa@chromium.org Review URL: https://codereview.chromium.org/93933009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240627 0039d316-1c4b-4281-b951-d872f2087c98
* Use the caret bounds as a fallback when GetCompositionCharacterBounds is not ↵yukawa@chromium.org2013-12-131-11/+16
| | | | | | | | | | | | | | | available This CL fixes a positional issue of IMEs' candidate window on PPAPI Flash running under Ash mode. The root cause is that PPAPI does not support TextInputClient::GetCompositionCharacterBounds at all. We once worked around this in Issue 148903 but the Win/Ash backend lacked of this treatment. BUG=328237 TEST=manually done on Windows 8.1 Review URL: https://codereview.chromium.org/109323009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240602 0039d316-1c4b-4281-b951-d872f2087c98
* Implement eliding/truncating at end in RenderTextskanuj@chromium.org2013-12-135-78/+289
| | | | | | | | | | | | | | | | | | | | | | | | | The eliding is determined using binary search similar to the ElideText in ui/gfx/text_elider.cc. The mixed LTR-RTL handling for ellipsis is done using LTR/RTL markers. There is no other way of rendering the ellipsis with the directionality of preceding strong-directional characters. Previous scheme worked because it rendered LTR and RTL sub-strings as different RenderText instances. Added helper method to be able to determine directionality of the trailing text. Made StringSlicer used by text_elider.cc public to be shared by RenderText. BUG=327833 TEST=ui_unittests,base_unittests R=msw@chromium.org TBR=jshin@chromium.org,pkasting@chromium.org Review URL: https://codereview.chromium.org/112063003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240572 0039d316-1c4b-4281-b951-d872f2087c98
* gtk: Make directory selection work with upload typelazyboy@chromium.org2013-12-131-3/+5
| | | | | | | | | | | | | | | | | (<input webkitdirectory>). Right now it hits NOTREACHED(). uploads have type = SELECT_UPLOAD_FOLDER. They should be treated same as SELECT_OPEN_FILE and SELECT_FOLDER to save the last opened directory path. BUG=None Test=Manually with a packaged app that has input element: <input type="file" webkitdirectory id="directory"/> Review URL: https://codereview.chromium.org/111843004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240564 0039d316-1c4b-4281-b951-d872f2087c98
* Adding GroupView. Moving NotificationButton and ProportionalImageViewdimich@chromium.org2013-12-1324-332/+1281
| | | | | | | | | | out into their own files (no code change for them, just move) BUG=320827 Review URL: https://codereview.chromium.org/86083002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240559 0039d316-1c4b-4281-b951-d872f2087c98
* Ash: Tell the browser process of the visibility of IME's popup UIyukawa@chromium.org2013-12-132-0/+11
| | | | | | | | | | | | | | | | | This is one of supplemental CLs to port full Desktop IME features into Ash mode. Rationale: Some components in Chrome are interested in whether an IME is showing its own popup window such as the candidate window. OmniBox is one example (see Issue 326774). W3C IME API on which kochi@ is currently working also relies on this information. Implementation memo: This CL uses SetWinEventHook API to monitor the some accessibility events that are generated by IMEs. The parameters passed to SetWinEventHook are carefully chosen so the delegate is called back on the UI thread even when an IME generates the accessibility events on a background thread (actually MS-IME on Windows 8.1 seems to be doing this). BUG=238585, 326774 TEST=manually done on Windows 8.1 with MS-IME Japanese Review URL: https://codereview.chromium.org/101333006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240555 0039d316-1c4b-4281-b951-d872f2087c98
* Cleanup of CursorClient and NativeCursorDelegate interfacestdanderson@chromium.org2013-12-138-57/+63
| | | | | | | | | | | | Remove some duplicated/unnecessary accessors from NativeCursorDelegate, and move some to CursorClient. BUG=328212 TEST=None (cleanup patch only, no change in functionality) Review URL: https://codereview.chromium.org/98203003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240543 0039d316-1c4b-4281-b951-d872f2087c98
* Settings: Fix infinite loop around FocusManager.onDocumentFocus_().tkent@chromium.org2013-12-131-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bug detail: 1. Open startup overlay: chrome://settings/startup 2. Type a space in the empty URL field 3. Press Cancel button This triggers the infinite loop, and the overlay doesn't disappear. When the startup overlay is canceled, 1. StartupOverlay.updateStartupPages_ updates the list data model. 2. It makes the first ListItem editable. 3. It gives focus to the URL field. 4. FocusManager.onDocumentFocus_() catches the 'focus' event for it. 5. However it is not a part of the current visible page because the startup overlay is closing. 6. So, it removes focus from the URL field, and gives focus to the search field in the main page. 7. After leaving the onDocumentFocus_(), the 'focus' event continues to propagate deeper, and <list> element catches it. 8. The <list> activates the selected ListItem, and it gives focus on the URL fields again. Solution: Don't propagate the 'focus' event when we don't accept the focus. BUG=327615 Review URL: https://codereview.chromium.org/106183008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240503 0039d316-1c4b-4281-b951-d872f2087c98
* Add app list support code and tests for syncstevenjb@chromium.org2013-12-139-77/+263
| | | | | | | | | | Primarily this makes AppListItemModel::set_position protected and adds SetItemPosition to AppListItemList along with logic to ensure that the item is re-ordered correctly. Tests are added for the new function and to ensure correct ordering in general (which was previously broken). BUG=305024 Review URL: https://codereview.chromium.org/99423006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240497 0039d316-1c4b-4281-b951-d872f2087c98
* Ensure that composited bubble windows with size less than 64 x 64 don't show ↵ananta@chromium.org2013-12-121-1/+4
| | | | | | | | | | | | | | | | | | up as clipped. We have code which expands the window sizes to be at least 64 x 64 to work around problems with some GPU drivers in displaying windows smaller than this. When bubbles are created they are centered using the parent window size and the actual size which causes them to show up in the wrong place. We need to use the expanded size while centering them. This fixes the position and also the clipping. Unclear as to why they are clipped. Fixes bug https://code.google.com/p/chromium/issues/detail?id=327887 BUG=327887 R=jbauman@chromium.org, sky@chromium.org Review URL: https://codereview.chromium.org/108303007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240467 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-03-30 10:19:39 +0000