Skip to content

GitLab

T
tangled
Switch branch/tag
  1. 16 Aug, 2014 5 commits
    • spang@chromium.org's avatar
      ozone: Implement GetFlingData · dee45a43
      spang@chromium.org authored 
      BUG=none
TEST=build

Review URL: https://codereview.chromium.org/471163004

Cr-Commit-Position: refs/heads/master@{#290062}
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@290062 0039d316-1c4b-4281-b951-d872f2087c98
      dee45a43
    • rpaquay@chromium.org's avatar
      Fix Bluetooth Classic device polling issue. · 2977264c
      rpaquay@chromium.org authored 
      With the recent device polling changes
(https://codereview.chromium.org/424093004/), any failure in enumerating
devices/services prevents the background polling task from reporting
changes (to avoid reporting inconsistent configuration). However, when
devices are offline and polling is done in "discovery" mode,
enumerating services fails because the underlying SDP request fails.
The workaround if to ask for cached services only instead, so that at
least the services already previously known are returned and the
polling operation can succeed.

BUG=396337

Review URL: https://codereview.chromium.org/476823003

Cr-Commit-Position: refs/heads/master@{#290061}
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@290061 0039d316-1c4b-4281-b951-d872f2087c98
      2977264c
    • jeun@chromium.org's avatar
      [Findit] Fixed a bug where blame information is not correctly filtered and · 703d04a4
      jeun@chromium.org authored 
      normalization was not working properly.

BUG=
NOTRY=true

Review URL: https://codereview.chromium.org/468653003

Cr-Commit-Position: refs/heads/master@{#290060}
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@290060 0039d316-1c4b-4281-b951-d872f2087c98
      703d04a4
    • mpearson@chromium.org's avatar
      Omnibox: Prevent Asynchronous Suggestions from Changing Default Match · 8366a42f
      mpearson@chromium.org authored 
      Calls to the suggest server may normally result in a new inline
autocompletion.  This can be disruptive because it means pressing enter
may bring the user to different places depending on how long he/she
waits after typing the last key.

This change prevents new suggestions from becoming the default match.
In other words, the default match is only allowed to change on a
keystroke, not due to a reply coming back from the server.

The consequence of this change is that if previously we'd show an
inline suggestion on a server reply, now we only show it one keystroke
later.  I think this trade-off (one keystroke versus inconsistent
omnibox behavior) is a good one to make.

We still end up with default matches (inline autocompletions within
the omnibox) from the suggest server after this change.  Here's an
example of why:

User types "facebo"
We send a suggest server request.
Server asynchronously returns "facebook" as a top suggestion,
  beating the server-provided verbatim score for "facebo".
We decide not to show it within the omnibox.  It's instead shown
  somewhere in the dropdown.
User types "o".
We send a suggest server request.
We reuse our cached suggestions and suggestion scores.  <<< THE KEY
We show "facebook" as an inline suggestion because it beats
  the default verbatim score that gets assigned to "faceboo".
  (This is the score that we assign by default without having
  yet received the most recent suggest server response.)
We receive the response, which includes "facebook" as a top
  suggestion, beating the server-provided verbatim score
  for "faceboo".
We show "facebook" as an inline suggestion.  i.e., we decide
  not to demote it because it was already being shown inline

TESTED:
unit tests plus interactive tests (facebook.com/l, google.com/a)

BUG=398135
R=msw@chromium.org

Review URL: https://codereview.chromium.org/471673002

Cr-Commit-Position: refs/heads/master@{#290058}
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@290058 0039d316-1c4b-4281-b951-d872f2087c98
      8366a42f
    • gcasto@chromium.org's avatar
      [Password Manager] Setup experiment to restrict autofilling of sync credential · 524dd70e
      gcasto@chromium.org authored 
      By default there is no change in behavior, but autofilling can now be disabled
for the sync credential entirely or just disabled for reauth pages that support
transactional reauth.

Note that this also changes GetSyncUsername() to not return the username if
password sync is disabled if it is possible to determine. This makes GetSyncUsername() a little inconsistent depending on the state of sync setup, but it's important to be as specific as possible when disabling autofilling, since it's a
usability hit.

BUG=386692
R=isherman@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=290030

Review URL: https://codereview.chromium.org/451853003

Cr-Commit-Position: refs/heads/master@{#290057}
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@290057 0039d316-1c4b-4281-b951-d872f2087c98
      524dd70e
  3. 15 Aug, 2014 35 commits