summaryrefslogtreecommitdiffstats
path: root/ui/gfx/render_text.cc
Commit message (Collapse)AuthorAgeFilesLines
* Uses and returns the fractional width in text elidingjianli@chromium.org2013-10-101-0/+5
| | | | | | | | | | | | | | | On Mac, the width is repsented as CGFloat due to possible sub-pixel rendering and extra kerning. We need to return the fractional widt, instead of the integral width. Some tests have been updated with the hack removed. BUG=288987 TEST=new tests plus updating existing tests Review URL: https://codereview.chromium.org/24883002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@227905 0039d316-1c4b-4281-b951-d872f2087c98
* Fix multiple problems with omnibox text handling across focus changes.pkasting@chromium.org2013-09-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | (1) RenderText was drawing unfocused selections with the non-selection background color, but the selected text color, leading to white-on-white text. Fix by drawing unfocused selected text as unselected. (2) OmniboxViewViews was preserving selections across focus changes using SaveStateToTab(), leading to problems when something about the omnibox state changed after the omnibox was unfocused -- a later state restoration would restore a selection model that no longer lined up with the rest of the omnibox state (e.g. the current text). Fix by tracking selection across focus changes in the same way OmniboxViewWin does. (3) On tab changes, OnTabChanged() could be followed by an OnBlur()/OnFocus() call if changing from a tab where the omnibox was focused to one where it wasn't (or vice versa). This led to the selection state being stomped. Fixed by making Browser give BrowserWindow first crack at handling the tab change. This makes tabbing out of the omnibox, changing tabs away and back, and tabbing back in correctly restore the selection even when changing between tabs that disagree about whether the omnibox is focused. BUG=293258 TEST=Following steps in bug comment 0 does not result in invisible text R=msw@chromium.org, shess@chromium.org, sky@chromium.org Review URL: https://codereview.chromium.org/23536075 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@225074 0039d316-1c4b-4281-b951-d872f2087c98
* Remove explicit namespace resolution from code in gfx namespaceckocagil@chromium.org2013-09-181-23/+20
| | | | | | | | | BUG=103304 R=sky@chromium.org Review URL: https://codereview.chromium.org/24053002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@223952 0039d316-1c4b-4281-b951-d872f2087c98
* Windows implementation of multiline RenderTextckocagil@chromium.org2013-09-161-11/+113
| | | | | | | | | | | | | | Multi-line text rendering in the Chromium UI is currently done by slicing the string into multiple lines by using text metrics from cross-platform libraries and rendering text by using different RenderText instances - one for each line. This approach has poor performance and is very bug-prone. This CL adds a cross-platform interface and data structures to RenderText to support multi-line text rendering. This CL also implements the required platform-specific bits for Windows. Support for other platforms will be implemented in subsequent CLs. Multi-line rendering as implemented in this CL is limited. Newline characters are ignored. RTL and complex scripts are supported, while there are be issues with selection highlights. Text-space <-> view-space mappings do not support RTL/complex scripts. BUG=248597 Review URL: https://chromiumcodereview.appspot.com/16867016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@223394 0039d316-1c4b-4281-b951-d872f2087c98
* Move a bunch of windows stuff from ui/base/win to ui/gfx/winben@chromium.org2013-09-121-3/+3
| | | | | | | | | R=sky@chromium.org BUG=103304 Review URL: https://codereview.chromium.org/23769011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222860 0039d316-1c4b-4281-b951-d872f2087c98
* Move text_elider to gfx.ben@chromium.org2013-09-091-2/+2
| | | | | | | | | R=sky@chromium.org http://crbug.com/103304 Review URL: https://codereview.chromium.org/23731010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222106 0039d316-1c4b-4281-b951-d872f2087c98
* Move Range code to gfx.ben@chromium.org2013-09-061-18/+19
| | | | | | | | | | | Part of a set of changes to fix the circular dependency between ui/base and ui/gfx, with the aim of making gfx its own component. R=jam@chromium.org, jschuh@chromium.org, rsesek@chromium.org BUG=285385,103304 Review URL: https://codereview.chromium.org/24012002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@221762 0039d316-1c4b-4281-b951-d872f2087c98
* when dragging from textfield, draw text without subpixel aa and in blackscottmg@chromium.org2013-08-091-1/+13
| | | | | | | | | | | | | | | | | | | | | | When dragging text from a views textfield on Windows, we have to make sure not to use subpixel AA (because it'll be rendered transparently when dragged), and we need to override the theme color to render in black (otherwise, the text without selection background will be white). Neither of these happen to show up on Linux because render_text_linux.cc always has subpixel AA off, and the theme leaves the text as black whether it's selected or not. This only fixes the views textfield dragging mentioned in the linked bug. Unfortunately, the omnibox dragging boldness must be caused by something else. R=msw@chromium.org BUG=224425 Review URL: https://chromiumcodereview.appspot.com/22477004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@216594 0039d316-1c4b-4281-b951-d872f2087c98
* Fix RenderText offset issue with trailing cursors.msw@chromium.org2013-08-021-3/+3
| | | | | | | | | | | | | | | | | | | | The text display offset is unstable with a cursor at the end. Some text moves by 1px when setting a trailing cursor, etc. The -1 and >= from xji's http://crrev.com/99998 were okay at the time. Since then, GetContentWidth has accounted for the cursor width. Remove the OBO error in offset calculation to fix this. No-op when (cursor.right == display.right), it's visible. The text I tested is stable and still shows trailing cursors. BUG=104150,131660,239635,266826 TEST=Long Views Textfield text doesn't jiggle by 1px with a trailing cursor/selection. R=asvitkine@chromium.org,ckocagil@chromium.org TBR=sky@chromium.org Review URL: https://chromiumcodereview.appspot.com/20912004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@215377 0039d316-1c4b-4281-b951-d872f2087c98
* Supports FontList in Textfield.yukishiino@chromium.org2013-08-011-5/+6
| | | | | | | | | | | | | | | | | | | The current interface of Textfield does not support FontList while RenderText supports FontList. This CL supports FontList in Textfield. The direct cause of crbug.com/263169 was that RenderText always uses the IDS_UI_FONT_FAMILY_CROS font set ignoring what font is specified for Textfield on ChromeOS. (See https://code.google.com/p/chromium/codesearch#chromium/src/ui/views/controls/textfield/native_textfield_views.cc&q=IDS_UI_FONT_FAMILY_CROS&sq=package:chromium&type=cs&l=88 ) The Omnibox font size is carefully calculated, but the font is ignored right now. This CL changes the following: - Supports FontList in Textfield so Omnibox layer can specify the font set, such as IDS_UI_FONT_FAMILY_CROS, for the underlying Textfield. - Makes NativeTextfieldViews follow the specified font set via Textfield on ChromeOS. BUG=263169,263196 TEST=Test manually. Review URL: https://chromiumcodereview.appspot.com/19666006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@215055 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes vertical alignment of RenderText.yukishiino@chromium.org2013-07-201-3/+1
| | | | | | | | | | | | | | | (was: Issue 18848002: Shows Japanese and English mixed queries correctly.) The CL 18848002 was reverted because the new unit test, which I added, depended on the specific fonts and didn't run well on some of platforms. I've carefully chosen another font for the unit test, which is available on all platforms. BUG=244323 TEST=Test manually. Review URL: https://chromiumcodereview.appspot.com/19352002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@212792 0039d316-1c4b-4281-b951-d872f2087c98
* Replace third_party/icu/public with third_party/icu/source in the include ↵jshin@chromium.org2013-07-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | directives. This is to move back icu headers in third_party/icu/public/{i18n,common}/unicode back to their upstream locations in third_party/icu/source/{i18n,common}/unicode. http://codereview.chromium.org/18836004 has is a CL to move ICU header files. Roll ICU to the version with the above ICU CL (http://crrev.com/211851 ). In addition to the global replacement of third_party/icu/public with third_party/icu/source, the top-level DEPS, DEPS in printing and chrome/ are tightened up. (the latter two were too permissive (it used to allow any header from third_party/icu). Besides, sync '-foo' list in ios/public/DEPS with '+foo' in the top-level DEPS and build/linux/unbundled/icu.gyp is updated. BUG=251433 TEST=Compile succeeds on all bots. checkdeps.py does not find any error. TBR=brettw,sky,wtc Review URL: https://chromiumcodereview.appspot.com/18252003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@212324 0039d316-1c4b-4281-b951-d872f2087c98
* This caused failures in ui_unittests FontListTest.Fonts_GetHeight_GetBaselinemark@chromium.org2013-07-151-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | http://build.chromium.org/p/chromium.mac/buildstatus?builder=Mac%2010.6%20Tests%20%28dbg%29%284%29&number=30356 http://build.chromium.org/p/chromium.mac/buildstatus?builder=Mac%2010.7%20Tests%20%28dbg%29%284%29&number=13543 Revert 211664 "Shows Japanese and English mixed queries correctly." > Shows Japanese and English mixed queries correctly. > > This CL respects the common height and baseline of the fonts in the given font list, and draw text according to the baseline. > > The cause of vertically-misaligned queries was that > 1. ASCII characters have 23 pixels in height > 2. Japanese characters have 17 pixels in height > > pango_layout_get_pixel_size(), which is called in RenderTextLinux::GetStringSize(), returns the above size. > > Also see: > https://docs.google.com/a/chromium.org/document/d/1e2n9lEM_usn37Pld8tMeo_qpfLRQQjkx-O1hTHi3sPo/edit?usp=sharing > > BUG=244323 > TEST=Test manually. > > Review URL: https://chromiumcodereview.appspot.com/18848002 TBR=yukishiino@chromium.org Review URL: https://codereview.chromium.org/19270002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@211669 0039d316-1c4b-4281-b951-d872f2087c98
* Shows Japanese and English mixed queries correctly.yukishiino@chromium.org2013-07-151-3/+1
| | | | | | | | | | | | | | | | | | | | This CL respects the common height and baseline of the fonts in the given font list, and draw text according to the baseline. The cause of vertically-misaligned queries was that 1. ASCII characters have 23 pixels in height 2. Japanese characters have 17 pixels in height pango_layout_get_pixel_size(), which is called in RenderTextLinux::GetStringSize(), returns the above size. Also see: https://docs.google.com/a/chromium.org/document/d/1e2n9lEM_usn37Pld8tMeo_qpfLRQQjkx-O1hTHi3sPo/edit?usp=sharing BUG=244323 TEST=Test manually. Review URL: https://chromiumcodereview.appspot.com/18848002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@211664 0039d316-1c4b-4281-b951-d872f2087c98
* Don't draw unfocused selections in RenderText.pkasting@chromium.org2013-07-021-6/+2
| | | | | | | | | | | | | | The primary editable control in Chrome's UI is the omnibox, which doesn't want this behavior, at least on Windows. We can always restore it in a switchable fashion if other consumers decide they want this. BUG=256789 TEST=none R=msw@chromium.org Review URL: https://codereview.chromium.org/18029027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@209822 0039d316-1c4b-4281-b951-d872f2087c98
* Clamp RenderTextWin layout length to 10,000 code points.msw@chromium.org2013-06-291-25/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add RenderText::truncate_length_ and setter to clamp layout text length. Avoid system limitations and performance degradation on Win/Uniscribe. This does not impact underlying text data, only what's shown on screen. Truncate text_ to layout_text_ in UpdateLayoutText() and append ellipsis. Only reveal obscured characters within the layout text range. Ensure the run and glyph limits are actually tried in their loops. Add unit tests for reasonable truncation behavior. Bail if layout fails, this will leave text un-rendered instead of crashing. Clamp run length to avoid exceeding the glyph limit later on. Clamp layout indices in conversion, fix run index bounds checks. TODO(followup): Truncate text on Linux/Pango as needed. TODO(followup): Increase supported text length and run counts. TODO(followup): UMA text lengths, run counts, failures, and truncations. BUG=235854,236406,248960,131660 TEST=Paste more than 10k characters on Win to see ellipsis and no crashes. (note that omnibox specific codepaths will cause additional performance degradation in that field). No crash on Windows with Search by Image extension use (tried various sizes 16x16 -> 96x96 -> 1900x1200 -> 3840x2160). Normal text behavior with <10k code points, and no behavior change on ChromeOS/Linux_Aura. R=asvitkine@chromium.org,oshima@chromium.org,sky@chromium.org Review URL: https://chromiumcodereview.appspot.com/17745005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@209286 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a couple of problems with bold text in the omnibox dropdown.pkasting@chromium.org2013-06-141-0/+5
| | | | | | | | | | | | | | | | | (1) RenderText::GetFont() will never return a bold font, so code that tried to elide bold strings, or to decide whether to use a bold ellipsis, always got the wrong result. To fix this I added an accessor for RenderText styles. (2) DeriveFont() needs to take gfx::Font::BOLD, not gfx::BOLD. (Boo to having both of these!) BUG=none TEST=Paste a long URL in the address bar and check that it's elided, not clipped, in the dropdown R=msw@chromium.org Review URL: https://codereview.chromium.org/17106006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@206519 0039d316-1c4b-4281-b951-d872f2087c98
* ui/gfx: Use base::string16 now that string16 was moved into base namespace.tfarina@chromium.org2013-06-091-2/+2
| | | | | | | | | | | | base/string16.h was moved into base namespace in r191198 by Brett. BUG=None TBR=ben@chromium.org NOTRY=true Review URL: https://chromiumcodereview.appspot.com/16051006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@205096 0039d316-1c4b-4281-b951-d872f2087c98
* cros: Password echo support for keyboard driven OOBE.xiyuan@chromium.org2013-06-071-2/+30
| | | | | | | | | | | | - Add support to reveal last typed char in obscured text field backed by NativeTextfieldViews; - Enable that for keyboard drive OOBE; BUG=238290 Review URL: https://chromiumcodereview.appspot.com/16051005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@204794 0039d316-1c4b-4281-b951-d872f2087c98
* Fix cursor positioning regression from r201136. GetCursorPos() shouldn't assumepkasting@chromium.org2013-05-241-8/+4
| | | | | | | | | | | | vertically-centered text. BUG=242801 TEST=Arrow through the omnibox in 200% mode and ensure the cursor does not appear vertically too low R=asvitkine@chromium.org, msw@chromium.org Review URL: https://codereview.chromium.org/15746013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@201944 0039d316-1c4b-4281-b951-d872f2087c98
* Add configurable vertical alignment to Textfields. The default is for text topkasting@chromium.org2013-05-201-16/+25
| | | | | | | | | | | | | be vertically centered. The upcoming larger omnibox will use top-aligned text plus a manually set vertical margin to position text precisely where it wants. BUG=231005 TEST=none R=asvitkine@chromium.org Review URL: https://codereview.chromium.org/15070015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@201136 0039d316-1c4b-4281-b951-d872f2087c98
* Only use skia::RefPtr for refcountingenne@chromium.org2013-05-181-1/+1
| | | | | | | | | | | | | | | | | | | | | For consistency and sanity in Chromium, only use skia::RefPtr in Chromium to ref count skia classes. SkRefPtr is unsafe to use for newly created objects because it refs the object that is passed to its constructor. skia::RefPtr makes this adoption explicit it via skia::AdoptRef and so is much clearer. This patch also adds a skia::ShareRef function which makes it explicit that the callsite is adopting a ref which is already owned somewhere else. Using AdoptRef vs. ShareRef seems much clearer than using SkRefPtr vs. skia::RefPtr. These are the remaining code sites that use internal Skia reference counted classes. Once these have been removed, then we can use a PRESUBMIT rule to prevent new uses from being added. BUG=none Review URL: https://chromiumcodereview.appspot.com/15004024 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@200989 0039d316-1c4b-4281-b951-d872f2087c98
* Views Textfield: Select whole words when the user double clicks and dragsckocagil@chromium.org2013-05-141-13/+14
| | | | | | | | | BUG=234366 TEST=NativeTextfieldViewsTest.KeepInitiallySelectedWord, RenderTextTest.SelectMultipleWords Review URL: https://chromiumcodereview.appspot.com/14457003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@199989 0039d316-1c4b-4281-b951-d872f2087c98
* Plumb text width from RenderText to Omnibox.pkasting@chromium.org2013-04-271-4/+4
| | | | | | | | | | BUG=232303 TEST=none R=sky@chromium.org Review URL: https://codereview.chromium.org/14523002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@196967 0039d316-1c4b-4281-b951-d872f2087c98
* NativeTextfieldViews: Do not allow dropping text in the same placeckocagil@chromium.org2013-04-271-10/+10
| | | | | | | | BUG=229841 Review URL: https://chromiumcodereview.appspot.com/14054002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@196945 0039d316-1c4b-4281-b951-d872f2087c98
* Re-land: NativeTextfieldViews: Show the drop cursor when dragging textckocagil@chromium.org2013-04-181-20/+19
| | | | | | | | | | | | | First landed as r193674, reverted due to breaking tests skipped by the try bots. This CL fixes the breakage too. NativeTextfieldViews: Show the drop cursor when dragging text. Enables RenderText users to draw cursors at specified positions through RenderText::DrawCursor. Uses this method to implement the drop cursor in NativeTextfieldViews. BUG=229661 TEST=Use Views Textfield; select text in omnibox; drag it around the omnibox; a cursor should be displayed at where the text will be dropped Review URL: https://chromiumcodereview.appspot.com/14264004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@194903 0039d316-1c4b-4281-b951-d872f2087c98
* Select last word when double clicked after the last characterckocagil@chromium.org2013-04-181-0/+3
| | | | | | | | | | | When RenderText::SelectWord is called while the cursor is on a boundary, the word to the right is selected. This patch specially handles the case where the cursor is at the rightmost position to select the word to the left. BUG=232023 TEST=See repro steps at http://crbug.com/232023 Review URL: https://chromiumcodereview.appspot.com/13972015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@194901 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 193674 "NativeTextfieldViews: Show the drop cursor when d..."dmazzoni@chromium.org2013-04-111-9/+10
| | | | | | | | | | | | | | | | Caused ui_unittests to fail on Mac > NativeTextfieldViews: Show the drop cursor when dragging text. Enables RenderText users to draw cursors at specified positions through RenderText::DrawCursor. Uses this method to implement the drop cursor in NativeTextfieldViews. > > BUG=229661 > TEST=Use Views Textfield; select text in omnibox; drag it around the omnibox; a cursor should be displayed at where the text will be dropped > > Review URL: https://chromiumcodereview.appspot.com/13982003 TBR=ckocagil@chromium.org Review URL: https://codereview.chromium.org/14029017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@193680 0039d316-1c4b-4281-b951-d872f2087c98
* NativeTextfieldViews: Show the drop cursor when dragging text. Enables ↵ckocagil@chromium.org2013-04-111-10/+9
| | | | | | | | | | | RenderText users to draw cursors at specified positions through RenderText::DrawCursor. Uses this method to implement the drop cursor in NativeTextfieldViews. BUG=229661 TEST=Use Views Textfield; select text in omnibox; drag it around the omnibox; a cursor should be displayed at where the text will be dropped Review URL: https://chromiumcodereview.appspot.com/13982003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@193674 0039d316-1c4b-4281-b951-d872f2087c98
* Add ability to draw only the selected portion of text in RenderText so that wevarunjain@chromium.org2013-02-151-0/+11
| | | | | | | | | | | can provide a drag image when the user tries to drag selected text. BUG=115237 Review URL: https://chromiumcodereview.appspot.com/12262043 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@182614 0039d316-1c4b-4281-b951-d872f2087c98
* Views Textfield: Copy on Ctrl+Insert, fix and disable overtype.msw@chromium.org2013-02-071-9/+2
| | | | | | | | | | | | | | | | | | | | Copy/paste on [Ctrl]/[Shift]+[Insert]; no-op on [Ctrl]+[Shift]+[Insert]. Disable insert/overtype mode toggling on [Insert]. (both of these match Windows native textfield behavior) (note: there is no other way to access overtype mode) Fix overtype cursor rendering for potential future use. (use an unfocused selection color for overtype cursors) (do not attempt to re-color the cursor's associated graphemes) See a screenshot at http://crbug.com/163107#c5 BUG=163107 TEST=Views textfield/omnibox will copy on [Ctrl]+[Insert], paste on [Shift]+[Insert], and no-op on [Insert] and [Ctrl]+[Shift]+[Insert]. R=asvitkine@chromium.org,sky@chromium.org Review URL: https://chromiumcodereview.appspot.com/12238002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@181250 0039d316-1c4b-4281-b951-d872f2087c98
* Replace StyleRange with BreakList; update RenderText, etc.msw@chromium.org2013-02-011-222/+168
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a functional rewrite with no observable behavior/appearance changes. (it helps by merging adjacent equivalent styles, reducing artificial run breaks) (it helps disambiguate font/adornment styles for application in layout/drawing) Remove gfx::StyleRange and its use within gfx::RenderText[Win|Linux|Mac]. Add new BreakList class for managing [ranged] colors and styles; add/update tests. Add gfx::TextStyle enum for bold, italic, underline, strike, and diagonal strike. Split ApplyStyleRange into [Set|Apply]Color and [Set|Apply]Style. Split ApplyDefaultStyle and |default_style_| into the first colors_ and styles_. Split up SkiaTextRenderer::DrawDecorations for Underline/Strike/DiagonalStrike. Update ApplyCompositionAndSelectionStyles, add UndoCompositionAndSelectionStyles. Add temporary StyleIterator convenience class for RenderText subclass style iteration. Update RenderText[Win|Linux|Mac], Textfield classes, and other users. Simplify OmniboxResultView (nix bold font, and ClassificationData). Rename gfx::Font::FontStyle::UNDERLINE (was UNDERLINED); TODO(followup): Only break runs for bold/italic, color/adorn while drawing. TODO(followup): Support more custom/ranged colors; merge TextStyle/FontStyle? BUG=90426,164047,131660 TEST=No observable appearance/performance/behavior changes. R=asvitkine@chromium.org,pkasting@chromium.org,sky@chromium.org Review URL: https://chromiumcodereview.appspot.com/11535014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@180067 0039d316-1c4b-4281-b951-d872f2087c98
* Fix Views textfield/omnibox diagonal strikethrough appearance.msw@chromium.org2012-12-061-3/+3
| | | | | | | | | | | | | | Double the RenderText diagonal strike stroke width. Flip the angle by swapping y coordinates. ( see the original impl at http://crrev.com/119478 ) BUG=164040 TEST=Views Omnibox diagonal strikethrough looks like Windows native. R=oshima@chromium.org Review URL: https://chromiumcodereview.appspot.com/11442030 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@171585 0039d316-1c4b-4281-b951-d872f2087c98
* Use min 1dip width for caretoshima@chromium.org2012-12-061-6/+4
| | | | | | | | | BUG=164100,161902 TEST=manual. see bug for repro step Review URL: https://chromiumcodereview.appspot.com/11416348 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@171483 0039d316-1c4b-4281-b951-d872f2087c98
* ui: Use skia::RefPtr<T> for implicit safe reference counting.danakj@chromium.org2012-12-051-18/+17
| | | | | | | | | | | R=sky BUG=163454 Depends on: https://codereview.chromium.org/11418217/ NOTRY=true Review URL: https://chromiumcodereview.appspot.com/11299262 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@171107 0039d316-1c4b-4281-b951-d872f2087c98
* ui: Prefer +/- operators to apply offsets.danakj@chromium.org2012-11-101-1/+1
| | | | | | | | | | | | | | | | | Adds +/- operators to gfx::Rect that are applied to its origin Point. Removes gfx::Point method a.OffsetFrom(b) in favor of (b - a). Begin use +/- instead of Offset() in ui/gfx/ and cc/ New tests: ui_unittests:RectTest.Offset R=pkasting,enne BUG=158416 Review URL: https://codereview.chromium.org/11293194 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@167012 0039d316-1c4b-4281-b951-d872f2087c98
* ui: Remove gfx::Point Add() and Subtract() which were non-mutating member ↵danakj@chromium.org2012-11-091-2/+2
| | | | | | | | | | | | | | | | methods. Replace use of these with operator +, +=, -, -=. Covered by existing unit tests. R=sky BUG=158416,160158 Review URL: https://chromiumcodereview.appspot.com/11362173 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166933 0039d316-1c4b-4281-b951-d872f2087c98
* Change RenderText::GetOriginForDrawing() to GetOffsetForDrawing and return a ↵danakj@chromium.org2012-11-011-2/+2
| | | | | | | | | | | | | | Vector2d. This method should return a Vector instead of a Point. Covered by existing tests; no change in behaviour. R=sky,pkasting Review URL: https://codereview.chromium.org/11367012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@165388 0039d316-1c4b-4281-b951-d872f2087c98
* Add Vector2d classes that represent offsets, instead of using Point.danakj@chromium.org2012-10-311-29/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously Point served two purposes, to be a position in 2d space, and also an offset from the origin. This introduces a Vector2d class to represent an offset, allowing typesafety checks for geometric operations. The following are now the case: Point +/- Vector = Point - A point plus/minus an offset gives you a point at a position offset by the vector. Vector +/- Vector = Vector - Two offsets can be added together to make a new offset. Point - Point = Vector - Subtracting one point from another gives you the offset between the two points. We add some new methods to perform these operations: Rect::OffsetFromOrigin() gives the offset between the position of the rect and the origin. Point::OffsetFromOrigin() gives the offset between the point and the origin. PointAtOffsetFromOrigin(Vector2d) converts a Vector2d to a Point at the given offset away from the origin. Rect::Offset(), Point::Add(), and Point::Subtract() now receive a Vector2d instead of a point. BUG=147395 R=sky Review URL: https://codereview.chromium.org/11269022 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@165198 0039d316-1c4b-4281-b951-d872f2087c98
* Support obscured RenderTextWin passwords.msw@chromium.org2012-09-281-7/+15
| | | | | | | | | | | | | | | | | | | | | Use asterisks instead of actual text when obscured on Win. Use GetLayoutText() and index conversion in RenderTextWin. Add UpdateObscuredText(), called on Set[Text|Obscured](). Shortcut word breaking when obscured like RenderTextLinux. Expand upon tests and enable on Windows; refactoring; etc. Fix and simplify TextfieldViewsModelTest.Clipboard. ( It incorrectly expected obscured text to support word-break cursor movement ) ( It was disabled on Linux Aura for long-fixed http://crbug.com/97845 ) BUG=97845,138222 TEST=Views examples and ftp auth --enable-views-textfield password textfields work, etc. R=xji@chromium.org,asvitkine@chromium.org TBR=sky@chromium.org Review URL: https://chromiumcodereview.appspot.com/10821079 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@159335 0039d316-1c4b-4281-b951-d872f2087c98
* Add RenderText::SetFont() function to simplify some call sites.asvitkine@chromium.org2012-09-181-0/+4
| | | | | | | | | BUG=none TEST=existing unit tests Review URL: https://chromiumcodereview.appspot.com/10933129 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157365 0039d316-1c4b-4281-b951-d872f2087c98
* Don't reset the layout on RenderText display rect width change.asvitkine@chromium.org2012-08-091-2/+0
| | | | | | | | | | | | | | | Previously, I thought width was used in layout in render_text_linux.cc, but it turns out that the width that's passed in to SetupPangoLayout() gets cleared right after. So the width of the display rect does not actually affect layout and thus does not need to cause the layout to be reset. BUG=137064 TEST=No behavior change. Review URL: https://chromiumcodereview.appspot.com/10829261 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@150908 0039d316-1c4b-4281-b951-d872f2087c98
* Add RenderText DirectionalityMode enum and support; etc.msw@chromium.org2012-08-011-0/+43
| | | | | | | | | | | | | | | | | | | Add gfx::DirectionalityMode enum. Add RenderText::SetDirectionalityMode and member. Revise/consolidate RenderText::GetTextDirection. Expand on existing unit tests; minor cleanup. Consume GetTextDirection in layout initialization: -Windows: RenderTextWin::ItemizeLogicalText() -Linux: SetupPangoLayoutWithoutFont() -Mac: Add TODO in RenderTextMac::EnsureLayout() BUG=134746 TEST=Existing/updated unit tests, no behavioral changes! Review URL: https://chromiumcodereview.appspot.com/10807082 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@149503 0039d316-1c4b-4281-b951-d872f2087c98
* Add and specify Views::Textfield::SelectAll |reversed| flag, etc.msw@chromium.org2012-07-131-8/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SelectAll should be consistent and explicit with range reversal. This dictates if leading or trailing text is shown when textfields overflow. Currently, NativeTextfield[Win|Views]::SelectAll behavior is implicit and differs. (Windows native reverses the selection, while ChromeOS/Views doesn't) Revise SelectAll in RenderText, NativeTextfieldWin, and OmniboxViewViews. Add the |reversed| parameter and plumbing to related interfaces/functions. Add/update RenderTextTest.SelectAll and TextfieldViewsModelTest.Selection. Specify explicit reversal behavior in all the following cases: 1) Use reversed selection (changes ChromeOS/Views behavior) in: a) BookmarkBubbleView::ShowBubble (focus on bookmark title when shown). b) BookmarkEditorView::Accept (focus on invalid bookmark URL on "Save"). c) BookmarkEditorView::Show (focus on bookmark title when shown). d) FindBarView::UpdateForResult (find bar matches are found/iterated). e) FindBarView::SetFocusAndSelection (find bar shown, etc.). f) FindBarView::SearchTextfieldView::RequestFocus (click find bar parts, etc.). g) EditSearchEngineDialog::Show (focus on search engine title when shown). h) LoginView::OnAutofillDataAvailable (HTTP/FTP auth window shown). i) MessageBoxView::ViewHierarchyChanged (JS dialog with text input shown). 2) Use forward selection (changes Windows native behavior) in: a) NativeTextfieldWin::ExecuteCommand (textfield context menu "Select All"). (note: the Omnibox context menu "Select All" already uses forward selection) b) Textfield::AboutToRequestFocusFromTabTraversal (focus via tab-traversal). (note1: THIS IS CONTENTIOUS! Though OmniBoxViewWin is unaffected) (note2: OmniboxViewViews should be fixed later as per crbug.com/134701#c9) c) TreeView::StartEditing (editing tree view nodes ex/ collected cookies). d) NativeTextfieldViewsTest.* and ViewTest.* (changes inconsequential to tests) 3) Formally specify existing implicit behavior (no behavioral change): a) NativeTextfieldWin::OnAfterPossibleChange (temporary selection is reversed). b) NativeTextfieldViews::OnGestureEvent (double tap is forwards). c) NativeTextfieldViews::ExecuteCommand (context menu "Select All" is forwards). d) NativeTextfieldViews::HandleKeyEvent (CTRL-A is forwards). e) NativeTextfieldViews::HandleMousePressEvent (triple-click is forwards). f) TextfieldViewsModel::SetText (temporary selection is forwards). g) TextfieldViewsModelTest.* is mostly forwards, |Selection| tests reversed. TBR=ben@chromium.org BUG=134762 TEST=New RenderTextTest.SelectAll, updated TextfieldViewsModelTest.Selection, other unit tests, manual. Review URL: https://chromiumcodereview.appspot.com/10693160 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@146520 0039d316-1c4b-4281-b951-d872f2087c98
* Fix tab title fading direction in RTL locales.asvitkine@chromium.org2012-06-281-1/+4
| | | | | | | | | | BUG=134759, 134746 TEST=On Windows, launch chrome.exe with --lang=he and go to http://en.wikipedia.org/wiki/Main_Page. Observe that the text is faded on the right. Open another tab and go to http://www.bbc.co.uk/arabic/topics/syria/ and observe that the text is faded on the left. Observe the same is true with LTR locales. Review URL: https://chromiumcodereview.appspot.com/10689013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@144791 0039d316-1c4b-4281-b951-d872f2087c98
* Removes DCHECK that I *always* hit when running chromeos on a linuxsky@chromium.org2012-06-281-1/+0
| | | | | | | | | | | | | | | box. I'm TBRing since this is supremely annoying. TBR=msw@chromium.org,xji@chromium.org R=msw@chromium.org,xji@chromium.org BUG=none TEST=none Review URL: https://chromiumcodereview.appspot.com/10722003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@144781 0039d316-1c4b-4281-b951-d872f2087c98
* RenderText: Expose a flag to disable clipping to workaround a Skia bug in ↵asvitkine@chromium.org2012-06-221-5/+10
| | | | | | | | | | | | | the PDF path. (See bug for context.) BUG=133548 TEST=Verify that the clipping problem is solved with (currently unlanded) RenderTextMac code in print preview. Review URL: https://chromiumcodereview.appspot.com/10638015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@143726 0039d316-1c4b-4281-b951-d872f2087c98
* Use pango underline metrics in RenderTextLinux.asvitkine@chromium.org2012-06-121-5/+21
| | | | | | | | | | | Also, changes type of SkiaTextRenderer::SetTextSize() to SkScalar to match the underlying Skia type, which is needed for future RenderTextMac implementation. BUG=126506, 125664, 105550 TEST=Eyeball underlined text in views_examples' text style example. Review URL: https://chromiumcodereview.appspot.com/10520017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@141772 0039d316-1c4b-4281-b951-d872f2087c98
* Remove trace code from render_text.cc.asvitkine@chromium.org2012-05-311-9/+2
| | | | | | | | | | | This was added to debug a perf problem that has since long been fixed. BUG=105550 TEST=render_text.o file is 3k smaller on Linux-64 in a release build Review URL: https://chromiumcodereview.appspot.com/10442084 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@139697 0039d316-1c4b-4281-b951-d872f2087c98
* Update std::vector<ShadowValue> to ShadowValues.xiyuan@chromium.org2012-05-291-2/+1
| | | | | | | | | | | This is a follow-up clean up for http://crrev.com/139162. BUG=none. TEST=none. Review URL: https://chromiumcodereview.appspot.com/10453057 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@139412 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-03-12 11:00:08 +0000