summaryrefslogtreecommitdiffstats
path: root/chrome/views
Commit message (Collapse)AuthorAgeFilesLines
* When you launch Chrome from a desktop shortcut, the window wasn't getting ↵ben@chromium.org2009-03-031-2/+12
| | | | | | activated because I removed code to explicitly activate the window in my change earlier today git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10780 0039d316-1c4b-4281-b951-d872f2087c98
* Fix interactive ui tests. There was a bug in the ↵ben@chromium.org2009-03-032-4/+3
| | | | | | NonClientView::GetPreferredSize method... it was returning the preferred size of the client area not the non-client area! git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10778 0039d316-1c4b-4281-b951-d872f2087c98
* Make it so that dropdown selects don't deactivate the main frame when opened ↵ben@chromium.org2009-03-031-0/+3
| | | | | | http://crbug.com/8247 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10777 0039d316-1c4b-4281-b951-d872f2087c98
* Support DWM switching.ben@chromium.org2009-03-0318-910/+639
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This completes the collapsing of window types and browser frames around a single class: views::Window. CustomFrameWindow is removed with this change. The Browser window is represented by a single views::Window subclass: BrowserFrame, which replaces both AeroGlassFrame and OpaqueFrame. NonClientView is now a container of two sibling classes - the Window's ClientView (in the Browser's case, BrowserView), and a NonClientFrameView subclass, which provides the rendering for the non-client portions of the window. These Views are siblings rather than the ClientView a child of the NonClientFrameView because when the DWM is toggled, the ClientView would have to be re-parented. Many Views make the assumption they are only inserted into a View hierarchy once, and so this is problematic. By having the views be siblings, this is avoided. With this in mind, all of the former NonClientViews now become NonClientFrameView subclasses: DefaultNonClientView -> CustomFrameView (non-existent, NonClientView) -> NativeFrameView AeroGlassNonClientView -> GlassBrowserFrameView OpaqueNonClientView -> OpaqueBrowserFrameView The latter two derive from NonClientFrameView via BrowserNonClientFrameView, which adds some extras. I also had to modify the TabRenderer class to know how to drop its cache of tab background images when the theme changes since it uses different ones for Glass and non-Glass. This change also fixes a few non-client flicker issues relating to window non-client activation by using more ScopedRedrawLocks. (Touches info_bubble.cc, window.cc) Bugs fixed: http://crbug.com/153 http://crbug.com/747 http://crbug.com/2371 http://crbug.com/3264 http://crbug.com/8234 Plumbing for http://crbug.com/8247 Design docs: http://dev.chromium.org/developers/design-documents/views-windowing http://dev.chromium.org/developers/design-documents/browser-window Review URL: http://codereview.chromium.org/27317 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10757 0039d316-1c4b-4281-b951-d872f2087c98
* Fix bookmark and menu drag images by making a halo around them. This makesbrettw@chromium.org2009-03-029-28/+55
| | | | | | | | | | | | | the ClearType composited on the correct color to fix the semitransparent pixels into 1-bit transparency pixels. Remove some unnecessary header file dependencies on ChromeCanvas I noticed when compiling this patch. BUG=8258 Review URL: http://codereview.chromium.org/27321 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10732 0039d316-1c4b-4281-b951-d872f2087c98
* Flatten CustomFrameWindow functionality onto Window.ben@chromium.org2009-02-278-41/+509
| | | | | | | This is not new code, just copying code into Window. None of the added codepaths are executed yet because UseNativeFrame is always true, so all custom frame windows continue to use CustomFrameWindow instead. Review URL: http://codereview.chromium.org/27291 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10646 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes bug in tree view deleting items if there was no root. The oldsky@google.com2009-02-271-4/+3
| | | | | | | | | | | | code would attempt to access an HTREEITEM after it was removed, leading to weird problems. BUG=none TEST=none Review URL: http://codereview.chromium.org/28275 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10634 0039d316-1c4b-4281-b951-d872f2087c98
* Wires up sorting of bookmarks to the 'organize menu' in the bookmarksky@google.com2009-02-272-2/+8
| | | | | | | | | | | | | manager (Glen says no context menus for now). All BookmarkModelObservers have been updated appropriately. BUG=1750 TEST=bring up the bookmark manager and try the 'Reorder by title' menu item, make sure it works and I didn't screw up anything around it. Review URL: http://codereview.chromium.org/27262 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10633 0039d316-1c4b-4281-b951-d872f2087c98
* All views::Window objects must have a NonClientView, regardless of whether ↵ben@chromium.org2009-02-276-85/+137
| | | | | | | | or not they fully render their own frame. This simplifies things a bit on the way to unification of Window and CustomFrameWindow. Review URL: http://codereview.chromium.org/27286 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10632 0039d316-1c4b-4281-b951-d872f2087c98
* Fix 8200: Pressing Esc should cancel dialogs, not commit.finnur@chromium.org2009-02-271-3/+3
| | | | | | | | | | | | | | | | | | | | | When we create the OK & Cancel dialog buttons in DialogClientView, we were registering OK as a handler for Escape, even though the dialog had a Cancel button. This is because we register for Esc if the member variable |cancel_ button_| is NULL. Problem is, that member isn't created until later on in that function. We should be checking the |buttons| flags instead. TEST=Open the Clear Browsing Data dialog, press Tab twice, press Esc and make sure that the dialog closes and nothing is cleared (from whatever checkbox was selected). BUG=8200 Review URL: http://codereview.chromium.org/28267 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10631 0039d316-1c4b-4281-b951-d872f2087c98
* Move DefaultNonClientView out into its own cc/h file.ben@chromium.org2009-02-274-795/+839
| | | | | | Review URL: http://codereview.chromium.org/28246 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10577 0039d316-1c4b-4281-b951-d872f2087c98
* Not DefProc'ing the NCActivate seems to cause the process not to be shown as ↵jcampan@chromium.org2009-02-271-1/+4
| | | | | | | | | | | activate when originally shown. BUG=4513 TEST=Start Chrome, the Chrome entry in the task bar should be shown as active. R=ben Review URL: http://codereview.chromium.org/28240 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10566 0039d316-1c4b-4281-b951-d872f2087c98
* An attempt at fixing a crasher reported from the field.jcampan@chromium.org2009-02-271-1/+4
| | | | | | | | BUG=5549 R=sky Review URL: http://codereview.chromium.org/27229 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10565 0039d316-1c4b-4281-b951-d872f2087c98
* Bringing the Task Manager to the front shouldn't cause it to lose topmost ↵pkasting@chromium.org2009-02-271-1/+7
| | | | | | | | | | status. Original patch by Kim Christensen (see http://codereview.chromium.org/28150 ), r=me,brettw, tweaked slightly. BUG=7227 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10558 0039d316-1c4b-4281-b951-d872f2087c98
* Non-functional cleanup:pkasting@chromium.org2009-02-272-3/+3
| | | | | | | | | | * Clarify some comments. * Simplify some redundant boolean logic. * Add a helper function for something a lot of callers were checking manually. * Fix lint. Review URL: http://codereview.chromium.org/27247 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10546 0039d316-1c4b-4281-b951-d872f2087c98
* Fix Linux shared build breakages due to undefined symbols.mmoss@chromium.org2009-02-271-0/+20
| | | | | | | Review URL: http://codereview.chromium.org/28206 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10545 0039d316-1c4b-4281-b951-d872f2087c98
* Makes it so windows opened from links in Windows Live Messenger cause the ↵ben@chromium.org2009-02-261-1/+8
| | | | | | | | | | | | | | | window to appear instead of being invisible. The discovery is that Windows enforces that you call ShowWindow with the value of STARTUPINFO's wShowWindow field first before calling it with any other value, otherwise all subsequent calls are ignored. I used to have code that flattened the return value of a function into something that would ensure the window is visible, but what I actually needed to do was show the window twice in this case. Ick. http://crbug.com/3126 TEST=Have someone send you a link in a Windows Live Messenger window, click it without Chrome running (Chrome must be default browser), and a Chrome window should appear, visible, loading the link. Also try running chrome.exe from bash to make sure that still works. Review URL: http://codereview.chromium.org/27190 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10502 0039d316-1c4b-4281-b951-d872f2087c98
* Adds ability for tree model to reorder its children. I'm going to usesky@google.com2009-02-263-15/+68
| | | | | | | | | | | this when sorting the contents of a bookmark folder. BUG=1750 TEST=none Review URL: http://codereview.chromium.org/28175 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10477 0039d316-1c4b-4281-b951-d872f2087c98
* Do not map virtual keycodes (VK_0 - VK_9) to characters when accelerators in ↵jungshik@google.com2009-02-261-2/+11
| | | | | | | | | | | | | | | the UI. If we do that, the result is the layout-dependent. For instance, in fr-FR layout, we get 'a with grave' in place of '0' for Ctrl+0 (normal in Zoom menu). Besides, in Slovak lazout, we get 'e with accent' This CL does not affect the actual behavior of accelerators (see issue 8043 for that), but only change the way they're displayed in the menu (even without this CL, ctrl-0 works fine in fr-FR AZERY layout and Slovak layout). BUG=7444 TEST=Change your kbd layout to French Azery and see what key is shown next to 'Normal' in Page-Zoom menu. It should be 'Ctrl+0'. Review URL: http://codereview.chromium.org/28121 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10476 0039d316-1c4b-4281-b951-d872f2087c98
* Handle keys like alt-f4 when focus has been cleared by making sure we don't ↵pkasting@chromium.org2009-02-253-32/+26
| | | | | | | | | | | eat them when no view wants to process them. I also took the opportunity to shorten ProcessKeyEvent(). BUG=8035 Review URL: http://codereview.chromium.org/28145 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10397 0039d316-1c4b-4281-b951-d872f2087c98
* This CL causes the autofill popup to hide when the browser window is moved ↵jcampan@chromium.org2009-02-251-0/+2
| | | | | | | | | | | or resized. TEST=Bring up an autofill popup in a form, move the browser. The autofill popup should be closed. BUG=7401 R=ben Review URL: http://codereview.chromium.org/28126 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10384 0039d316-1c4b-4281-b951-d872f2087c98
* An experimental fix for Issue 7707.hbono@chromium.org2009-02-251-0/+7
| | | | | | | | | | | To read crash dumps, it seems a rich-edit control crashes because it receives a WM_IME_CHAR message while it is processing a WM_IME_COMPOSITION message. Since a rich-edit control does not need WM_IME_CHAR messages, this code just blocks WM_IME_CHAR messages from being dispatched to view controls. Even though I'm not totally confident this code fixes this issue, I wish it does. BUG=7707 Review URL: http://codereview.chromium.org/21535 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10328 0039d316-1c4b-4281-b951-d872f2087c98
* ui test fail. revert.ben@chromium.org2009-02-252-0/+29
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10322 0039d316-1c4b-4281-b951-d872f2087c98
* AppModalDialogQueue shouldn't depend on views.ben@chromium.org2009-02-252-29/+0
| | | | | | | | Add a simple test, too. Review URL: http://codereview.chromium.org/27080 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10320 0039d316-1c4b-4281-b951-d872f2087c98
* Adds ability to sort the children of a node in the bookmark model. Isky@google.com2009-02-251-6/+3
| | | | | | | | | | | | plan on doing this in chunks, next phase is updating observers, then changing the bookmark manager to call into the new method. BUG=1750 TEST=none yet Review URL: http://codereview.chromium.org/27082 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10313 0039d316-1c4b-4281-b951-d872f2087c98
* Fix release build by including windows.h which wastc@google.com2009-02-251-0/+2
| | | | | | | | | | removed from a header file. TBR=sky Review URL: http://codereview.chromium.org/28099 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10310 0039d316-1c4b-4281-b951-d872f2087c98
* Move windows specific functions from l10n_util.h to l10n_util_win.h.tc@google.com2009-02-246-3/+6
| | | | | | Review URL: http://codereview.chromium.org/27103 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10307 0039d316-1c4b-4281-b951-d872f2087c98
* Fixing 8010: Missing options from Options dlg.finnur@google.com2009-02-241-1/+4
| | | | | | | | | | | | | This should also fix the hang in the interactive_ui_tests. The problem is in a one line change in view.cc where we return early from a Layout call. BUG=8010 Review URL: http://codereview.chromium.org/27102 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10294 0039d316-1c4b-4281-b951-d872f2087c98
* Use string for Histogram names since these are all ASCII anyway.dsh@google.com2009-02-241-2/+1
| | | | | | | | Wide-character literals cause problems between platforms. Review URL: http://codereview.chromium.org/28046 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10276 0039d316-1c4b-4281-b951-d872f2087c98
* Maximized popup windows couldn't be restored by double-clicking the ↵pkasting@chromium.org2009-02-241-2/+7
| | | | | | | | titlebar, because we gofed up the coordinate transforms while adding nonclient button handling to WidgetWin. Review URL: http://codereview.chromium.org/27095 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10272 0039d316-1c4b-4281-b951-d872f2087c98
* The find bar should be owned and managed from the BrowserView, not the ↵finnur@google.com2009-02-241-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | WebContentsView, since it's part of the "chrome". Design Doc: http://dev.chromium.org/developers/design-documents/find-bar Things done: - Pulled all of the find bar stuff out of WebContentsView* since it's no longer needed. - Moved OnFindReply delegate method from RenderViewHostDelegate::View to RenderViewHostDelegate, since it's no longer implemented on the view. - Moved find control methods to WebContents. - Added recent find result state to WebContents. - Updated the UI tests to accommodate the changes in the state that is broadcast when results are discovered. - Updated the find bar layout to obtain its bounding box from the BrowserView, which knows about toolbars, bookmark bars etc. - Updated the find bar itself to handle the fact that it can be displayed for multiple different tabs. - Moved the find bar manipulation methods for testing from TabProxy to BrowserProxy, since the find bar is now a feature of the window, not the tab. - view.h: Don't lay out child views again if they have a layout manager, it already updated them. TEST=Find box should work as before. BUG=3245 Review URL: http://codereview.chromium.org/27025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10231 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "Revert "Fullscreen mode UI.""kuchhal@chromium.org2009-02-231-0/+3
| | | | | | | | | This reverts commit 243e461e4a659a6e8008befc2c76a55680860f01. Review URL: http://codereview.appspot.com/21057 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10220 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "Fullscreen mode UI."kuchhal@chromium.org2009-02-231-3/+0
| | | | | | | | | This reverts commit d108cc705611554de13712935ec11942dd390a5d. Review URL: http://codereview.appspot.com/21056 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10217 0039d316-1c4b-4281-b951-d872f2087c98
* Fullscreen mode UI.pkasting@chromium.org2009-02-231-0/+3
| | | | | | | | | | This requires a change that is currently out for review from sky. BUG=534 TEST=App menu should have a "full screen mode" entry; going into fullscreen mode should display a bubble at the top of the screen, which should slide away after a few seconds; mousing to the screen top will show the bubble again, and clicking the link inside should exit fullscreen mode. Review URL: http://codereview.chromium.org/28012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10214 0039d316-1c4b-4281-b951-d872f2087c98
* A few minor changes to WidgetWin:pkasting@chromium.org2009-02-232-13/+26
| | | | | | | | | * Add a Show() method to match Hide(), and use it in existing code. This abstracts the specifics of this a bit and will be convenient for fullscreen UI. * Safe Hide() (and, for speed, Close()) behind IsWindow() checks just like CloseNow(), which I'll need for some tricky window-closing code in the fullscreen UI. (Right now, Hide() will eventually fail an assertion if you call it when the widget is no longer a window, which seems unnecessarily harsh.) Review URL: http://codereview.chromium.org/27017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10190 0039d316-1c4b-4281-b951-d872f2087c98
* This CL fixes issue 6099 -- bad display of multi-line English message in pop ↵xji@chromium.org2009-02-235-12/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ups. (http://crbug.com/6099) Currently, in RTL locales, a pure *multi-line* English message is displayed as right aligned and has RTL directionality (such as the ending punctuation appears at the very left). Single-line message works fine. I do not know why, but simply putting LRE-PDF around a multi-line English text which has the following flags DT_WORDBREAK | DT_RTLREADING wont render the English message as LTR. We have to remove the DT_RTLREADING to render multi-line English message correctly in LTR direction. The fix is that in RTL locales, for JavaScript message, if the message is pure English, the alignment is set to be left-aligned, and the directionality is set to be left-to-right. If the message is mixed BiDi text, the alignment and the directionality is determined by the directionality of the first character with strong directionality in the text. JavaScript message is a MessageBoxView, and the message is a view::Label. Both MessageBoxView and Label are used by Chrome's UI as well. If the message is one of Chrome UI's, the alignment and directionality of the message should be taken from that of the UI's. In order to distinguish where the message comes from, a new flag kFlagWebMessage is introduced in MessageBoxView, and a new argument is introduced in Label::SetHorizontalAlignment() to control whether the alignment need to be flipped or not for RTL locales. Consequently, quite a few files which calls Label::SetHorizontalAlignment() are changed. The main changes are in 5 areas. Other files are changed due to the signature change of Label::SetHorizontalAlignment(). 1. jsmessage_box_handler.cc: pass in extra flag kFlagWebPage when creating MessageBoxView to indicate the message box is one from a web page, not from Chrome UI. 2. l10n_util.h/.cc added function GetFirstStrongDirection() 3. label.h/.cc a new argument is introduced in Label::SetHorizontalAlignment() to control whether the alignment need to be flipped or not for RTL locales. 4. message_box_view.cc when init message box view, if the flag is kFlagWebPage, get the text directionality from the text itself (not Chrome UI's) and calls Label::SetHorizontalAlignment() to not resetting the flag for RTL locales. 5. chrome_canvas_win.cc 5.1 ComputeFormatFlags() only set flag DT_RTLREADING for RTL locales if the text contains strong RTL characters and the alignment is RIGHT aligned. All labels of Chrome's UI and other Chrome UI components in RTL locales have been set as (or flipped to) RIGHT aligned. 5.2 DoDrawText() Only adjust string for locale is the reading direction is DT_RTLREADING. Review URL: http://codereview.chromium.org/18863 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10178 0039d316-1c4b-4281-b951-d872f2087c98
* Update include paths for grit files. Go ahead and resorttc@google.com2009-02-2215-26/+18
| | | | | | | | the headers too. Review URL: http://codereview.chromium.org/21472 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10167 0039d316-1c4b-4281-b951-d872f2087c98
* Fix for a flag error introduced yesterday for non-client messages, which weidanan@chromium.org2009-02-191-6/+6
| | | | | | | | | | | | | | | | | | | do not handle actually but if we were to do it, we may have found out than an extra bit was sometimes set. For non-clicent mouse messages, the flag passed to the message procedure should not be ORed with the mouse-event because it contains the result of the last hit test instead. Added flags merged in: http://src.chromium.org/viewvc/chrome?view=rev&revision=9953 Review URL: http://codereview.chromium.org/21519 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10043 0039d316-1c4b-4281-b951-d872f2087c98
* Changes line endings from CRLF to LF and add svn:eol-style to LF.hbono@chromium.org2009-02-191-422/+422
| | | | | | | No code changes. This change just changes the CRLF line endings found by your change to make your change work on Mac and Linux trybots. Review URL: http://codereview.chromium.org/21445 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10001 0039d316-1c4b-4281-b951-d872f2087c98
* Make interstitial_page.cc compile on Posix.jhawkins@chromium.org2009-02-181-1/+1
| | | | | | Review URL: http://codereview.chromium.org/21467 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9971 0039d316-1c4b-4281-b951-d872f2087c98
* Solved 2 bugs which caused Chrome to maximize itself whendouble clicking, ↵idanan@chromium.org2009-02-187-36/+54
| | | | | | | | either on the new tab button, on the closetab button or on a single tab.BUG=2827BUG=3787The problem comes from the Windows event sequence upon adouble-click (simplified here):1 - hit-test2 - mouse-down4 - mouse-up/click5 - hit-test6 - mouse down7 - mouse up/double-clickThe 1st hit-test is always performed correctly, returningclient for tabs and non-client for the tab-strip (background).The 2nd hit test is not performed correctly to avoid crashesin Chromebot from events being processed while tabs are animating.Since we have no record of these crashes, Ben prefers we keepthis special-case, even though we are responding incorrectlyto the windows hit-test. So, when the tabs are animating wereturn a HTNOWHERE hit which the caller translates into anHTCAPTION hit. This even though a tab-control (new-tab/close-tab)may have been hit.The problem is that having returned HTCAPTION to Windows defaultmessage handling, we get a NON-CLIENT double-click event insteadof a standard one.To keep the behavior of the second hit-test AND prevent theChrome window from maximizing, this change simply declaresthe non-client double-click as handled when the tabs areanimating.Another trick we pulled in the hit-test is to return HTCAPTIONwhen a single tab is present. This allows the entire window to be dragged but causes the context menu to be wrong and the windowto maximize when double clicking on the single tab.The solution here is to correct return a client hit for a singletab and, upon handling a client single-click, delegate to thenon-client single-click default handler. Review URL: http://codereview.chromium.org/21268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9953 0039d316-1c4b-4281-b951-d872f2087c98
* Don't pass out pointers that belong to other processes.tommi@chromium.org2009-02-181-7/+13
| | | | | | Review URL: http://codereview.chromium.org/20385 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9931 0039d316-1c4b-4281-b951-d872f2087c98
* HtmlDialogs had focus problems.jcampan@chromium.org2009-02-185-3/+9
| | | | | | | | | | | | | | | | | | They would not be focused when shown and tab traversal was not working. This was caused by several issues: - HWNDView was not focusing its HWND when focused through the View::RequestFocus() method (it would rely on the default view behavior which is to focus the root view HWND), so it would not be focused by default. - DOMView (parent of HtmlDialogView) was not focusable so would not get the focus when pressing tab. - DOMView was not eating tab keys events (by returning false in View::CanProcessTabKeyEvents()), so the render view would not get the tab key press messages (for focus traversal in the render view). Note: most of the file changes in this CL are just the consequence of changing the constness of the WindowDelegate::GetInitiallyFocusedView method. BUG=6859 TEST=Open a web page, from the page menu, select the "Create application shortcut..." menu. In the dialog, press the TAB key, focus should alternate between the different fields Review URL: http://codereview.chromium.org/21439 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9925 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 9855.maruel@chromium.org2009-02-161-1/+1
| | | | | | | This change didn't have any description and it broke the tree Review URL: http://codereview.chromium.org/21393 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9856 0039d316-1c4b-4281-b951-d872f2087c98
* Review URL: http://codereview.chromium.org/20405yurys@google.com2009-02-161-1/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9855 0039d316-1c4b-4281-b951-d872f2087c98
* Make system menus show up at the right place for all frames, whether they're ↵pkasting@chromium.org2009-02-137-28/+42
| | | | | | | | | | | | | | | | triggered by clicking the window icon or hitting alt-space. Make clicking the icon for windows without a non-client view (e.g. the Bookmark Manager on Aero Glass) bring up the system menu. Clean up more dead code, verbose code, or unnecessary statics/members. TEST=Right-click titlebars, hit alt-space, and left-click window icons (where present), for: * Main window * Dialogs, e.g. the bookmark manager * Popups * App windows When right-clicking, a system menu should appear at the cursor. For the other cases, a system menu should appear at the system native location (roughly just below the titlebar). Review URL: http://codereview.chromium.org/20225 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9766 0039d316-1c4b-4281-b951-d872f2087c98
* Don't focus unfocusable things.pkasting@chromium.org2009-02-134-8/+4
| | | | | | Review URL: http://codereview.chromium.org/20348 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9765 0039d316-1c4b-4281-b951-d872f2087c98
* A patch from external contributor Yong Shin (already in AUTHORS list). I ↵finnur@google.com2009-02-131-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | also removed some lint errors. This was reviewed by me and Scott TBR=sky Original changelist description (http://codereview.chromium.org/17608): Context menu for title bar doesn't appear when a tab's context menu was open. --------------------------------------------------------------------------- * About the Bug --------------------------------------------------------------------------- - What steps will reproduce the problem? 1. Open the context menu for a tab of your choice. 2. Right-click on the title bar. - What is the expected result? The application context menu should show up. - What happens instead? Nothing (The tab's context menu is correctly closed, of course). - What is the reason? The context menu for an App is displayed when WM_NCRBUTTONDOWN event is processed on the Window::OnNCRButtonDown() handler. In normal case, when the right mouse button is clicked on the NC area, this event is generated. But in the case that the context menu for a tab is being displayed, WM_NCRBUTTONDOWN is not received. Instead, WM_NCLBUTTONDOWN is generated. (This is wrong because left mouse button is never pressed.) So the right handler (Window::OnNCRButtonDown()) cannot be called. --------------------------------------------------------------------------- * About the Fix --------------------------------------------------------------------------- What is modified? Modified MenuController::RepostEvent() method. This function is called when the mouse button is pressed while the context menu for a tab is being displayed. In this function, following two steps occur in order. 1st. Determine the event type. 2nd. Post this event using PostMessage(). On the 2nd step, In the case that the determined event on the 1st step is for the client area, there's no problem. But in the case of the non-client area, it doesn't use the right event type but use the fixed event type (WM_NCLBUTTONDOWN). This is the wrong implementation. So, I modified this part so that it use the right event type. Bug=5695 http://crbug.com/5695 Review URL: http://codereview.chromium.org/21354 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9761 0039d316-1c4b-4281-b951-d872f2087c98
* Fix an issue with HWNDView visibility where invisible (i.e. ↵pkasting@chromium.org2009-02-132-5/+3
| | | | | | | | SetVisible(false)) views would have ShowWindow() called on them, which was bogus. Review URL: http://codereview.chromium.org/21333 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9760 0039d316-1c4b-4281-b951-d872f2087c98
* Fix some focus traversal issues:pkasting@chromium.org2009-02-131-11/+9
| | | | | | | | * When we're on the only focusable view, AdvanceFocus() should just focus us again. * When only one focusable view exists, FindLastFocusableView() should return it, not NULL. Also the code here was longer than it needed to be. Review URL: http://codereview.chromium.org/20347 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9759 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-02 09:56:17 +0000