Skip to content

GitLab

T
tangled
Switch branch/tag
  1. 17 Jul, 2018 3 commits
    • Jennifer Apacible's avatar
      [Picture in Picture] Track window positioning when updating bounds. · 1bbb4fbd
      Jennifer Apacible authored 
      Currently, entering Picture-in-Picture multiple times from the same page
will reset the location of the window to the default location, or the
bottom right of the screen.

When the window has been moved, the user has indicated they want the
window positioned elsewhere. This change keeps the window origin, or
the top left corner coordinates, when the window bounds are updated.

Bug: 863710
Change-Id: I0cf0a23b549ef52bf06c78e28af6753e4735f186
Reviewed-on: https://chromium-review.googlesource.com/1137837
Commit-Queue: apacible <apacible@chromium.org>
Reviewed-by: default avatarMounir Lamouri <mlamouri@chromium.org>
Cr-Commit-Position: refs/heads/master@{#575489}
      1bbb4fbd
    • Trent Apted's avatar
      MacViews IME: Fix handling of phonetic/inline IME (e.g Korean) · 27a4cd8f
      Trent Apted authored 
      Currently IME for phonetic languages such as Korean is pretty
broken in MacViews text fields. Even in stable, the last character
entered in a textfield ('ㅂ', say, from pressing 'q') will disappear
when pressing tab. A similar thing happens with the Return key in
the Omnibox. This is a huge dealbreaker.

Phonetic languages such as Korean and Vietnamese use an IME style
that doesn't _mark_ text while it is being composed. This breaks
some assumptions around how unicode insertText: events are attached
to ui::KeyEvents. It also comes with some weird behaviour from the IME
on macOS (e.g. sending 2 identical replaceText messages), adding extra
complexity.

The handling got extra bad after r565848 when attaching to a Tab key
could cause 2 focus changes while the IME was dismissing itself, causing
the input context to change again, thereby triggering an IME
dismissal recursively.

To fix these issues, only dispatch character events as a ui::KeyEvent
in insertText: when the character attached to the key event matches
the first unicode text given to insertText: (in addition to the other
checks). This prevents a tab keypress that dismisses an IME (and
inserts text) as being treated as a tab. But, for inline IME, we still
want to process that tab, so also leave it "unhandled" to be picked
up by the unhandled key event handler.

This also prevents recursive calls to updateWindows coming from known
client code. However, the badness is bad enough that we should also
protect against recursive calls. Add logic for that and test coverage
that simulates the IME interaction.

Test: Enable the "2-Set Korean" IME on Mac and interact with the omnibox.
E.g. pressing the return key should not cause the last character to
disappear (and not appear in the search result).

Bug: 860362
Change-Id: I04fc7d9590563413021de99921864ab079f9b044
Reviewed-on: https://chromium-review.googlesource.com/1128685Reviewed-by: default avatarElly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#575488}
      27a4cd8f
    • Ted Choc's avatar
      Restrict compositor view sizing fix to only when the keyboard is showing. · a0d2e0e0
      Ted Choc authored 
      This applies the same heuristic that Chrome uses to determine
whether a keyboard is showing before using the alternative sizing
path in the CompositorViewHolder introduced to handle keyboard
input while in fullscreen.

This is to avoid any further glitches when viewing video content.

BUG=852297

Change-Id: I2cf3372e8c607bee500ab31f8b876381b11fca7d
Reviewed-on: https://chromium-review.googlesource.com/1138853Reviewed-by: default avatarMatthew Jones <mdjones@chromium.org>
Commit-Queue: Ted Choc <tedchoc@chromium.org>
Cr-Commit-Position: refs/heads/master@{#575487}
      a0d2e0e0
  3. 16 Jul, 2018 37 commits