Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reset Cursor type when pointer exits #320

Merged

Conversation

tonikitoo
Copy link
Member

If user places the pointer/mouse on any end of a browser window, cursor
type changes accordingly, to indicated a possible interactive resize operation.

If the user crosses the browser window bounds through the same end, the mouse
type stored in ui::CursorManager isn't reset. If pointer reenters the
window through the same end, Aura tries to set the cursor type to the
same as previously (to indicate it is over the same end). During the
call chain, CursorManager::SetCursor compares the last Cursor stored
and the new one and updates the cursor instance if they differ.

In case of regular Chrome/x11 builds, the check passes because
CursorData is set to the Cursor instance, and values always differ
from the CursorData cached by CursorManager.
In case of Linux/Ozone builds, CursorData is only set on Ozone side,
so the call bail out and cursor is not updated.

Patch fixes it by resetting the cursor type whenever pointer leaves
the browser window. This ensures, when reentering from the same end, the
comparison in CursorManager::SetCursor passes, and cursor gets updated.

Issue #317

@tonikitoo tonikitoo self-assigned this Nov 23, 2017
If user places the pointer/mouse on any end of a browser window, cursor
type changes accordingly, to indicated a possible interactive resize operation.

If the user crosses the browser window bounds through the same end, the mouse
type stored in ui::CursorManager isn't reset. If pointer reenters the
window through the same end, Aura tries to set the cursor type to the
same as previously (to indicate it is over the same end). During the
call chain, CursorManager::SetCursor compares the last Cursor stored
and the new one and updates the cursor instance if they differ.

In case of regular Chrome/x11 builds, the check passes because
CursorData is set to the Cursor instance, and values always differ
from the CursorData cached by CursorManager.
In case of Linux/Ozone builds, CursorData is only set on Ozone side,
so the call bail out and cursor is not updated.

Patch fixes it by resetting the cursor type whenever pointer leaves
the browser window. This ensures, when reentering from the same end, the
comparison in CursorManager::SetCursor passes, and cursor gets updated.

Issue Igalia#317
Copy link
Member

@msisov msisov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

r+

@tonikitoo tonikitoo merged commit 6cebc88 into Igalia:ozone-wayland-dev Nov 23, 2017
msisov pushed a commit that referenced this pull request Dec 23, 2018
The scheme check added at
https://crrev.com/43b8facd3a2fbfb8f75b455f07d64acc2c13fb5c caused some
issues on WebView. This change deletes the check temporarily.

TBR=yhirano@chromium.org

(cherry picked from commit 14314b0)

Bug: 898589
Change-Id: I6126b3b25f8700fc0547fa2c70b62bd183cc5e23
Reviewed-on: https://chromium-review.googlesource.com/c/1298828
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Richard Coles <torne@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#602736}
Reviewed-on: https://chromium-review.googlesource.com/c/1299436
Reviewed-by: Richard Coles <torne@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#320}
Cr-Branched-From: 4226ddf-refs/heads/master@{#599034}
msisov pushed a commit that referenced this pull request Jan 31, 2019
According to metrics, 0.3% of forms have >100 fields (the current limit), increase the limit to 250 in order to cover all forms.

Autofill throttling limits the number of queries/uploads are sent for a given form by a given user. Therefore, uploading huge forms wouldn't flood network.

Bug: 857454
Change-Id: Ia92a3d6f2033159df121d8728a263c70ee7914f7
Reviewed-on: https://chromium-review.googlesource.com/c/1369772
Reviewed-by: Vadym Doroshenko <dvadym@chromium.org>
Commit-Queue: Maxim Kolosovskiy <kolos@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#615523}(cherry picked from commit ba5fd2a)
Reviewed-on: https://chromium-review.googlesource.com/c/1375114
Reviewed-by: Maxim Kolosovskiy <kolos@chromium.org>
Cr-Commit-Position: refs/branch-heads/3626@{#320}
Cr-Branched-From: d897fb1-refs/heads/master@{#612437}
msisov pushed a commit that referenced this pull request Mar 14, 2019
… mode

- Adds any preconfigured shares that do not match an explicitly known mode
to the dropdown.
- If new policies are added to later milestones that are unknown in older
versions of Chrome, the preconfigured shares will fallback to being added
in the dropdown. This ensures that we can gracefully handle adding new
enterprise policies in the future.

TBR=baileyberro@chromium.org

(cherry picked from commit ccc08e1)

Bug: chromium:929322
Change-Id: I693ad6d102e0cfe3129ee349b86df84851038eb2
Reviewed-on: https://chromium-review.googlesource.com/c/1456945
Reviewed-by: Zentaro Kavanagh <zentaro@chromium.org>
Commit-Queue: Bailey Berro <baileyberro@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#630444}
Reviewed-on: https://chromium-review.googlesource.com/c/1461548
Reviewed-by: Bailey Berro <baileyberro@chromium.org>
Cr-Commit-Position: refs/branch-heads/3683@{#320}
Cr-Branched-From: e510299-refs/heads/master@{#625896}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Ozone/Wayland
Awaiting triage
Development

Successfully merging this pull request may close these issues.

None yet

2 participants