[ozone/wayland] reset cursor #435
Labels
desktop_aura
issues that are part of desktop aura integration (aka refactoring)
Comments
jkim-julie
pushed a commit
to jkim-julie/chromium
that referenced
this issue
May 15, 2018
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 Issue Igalia#435
jkim-julie
added
the
desktop_aura
jkim-julie
pushed a commit
that referenced
this issue
May 21, 2018
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 Issue #435
msisov
pushed a commit
that referenced
this issue
May 24, 2018
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 Issue #435
msisov
pushed a commit
that referenced
this issue
May 28, 2018
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 Issue #435
jkim-julie
pushed a commit
that referenced
this issue
Jun 4, 2018
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 Issue #435
msisov
pushed a commit
that referenced
this issue
Jun 12, 2018
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 Issue #435
jkim-julie
pushed a commit
that referenced
this issue
Jun 18, 2018
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 Issue #435
msisov
pushed a commit
to msisov/chromium
that referenced
this issue
Jun 21, 2018
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 Issue Igalia#435
jkim-julie
pushed a commit
that referenced
this issue
Jul 9, 2018
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 Issue #435
jkim-julie
pushed a commit
that referenced
this issue
Jul 16, 2018
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 Issue #435
msisov
pushed a commit
to msisov/chromium
that referenced
this issue
Jul 31, 2018
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 Issue Igalia#435
msisov
pushed a commit
that referenced
this issue
Aug 6, 2018
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 Issue #435
jkim-julie
pushed a commit
to jkim-julie/chromium
that referenced
this issue
Aug 13, 2018
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 Issue Igalia#435
msisov
pushed a commit
to msisov/chromium
that referenced
this issue
Aug 16, 2018
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 Issue Igalia#435
jkim-julie
pushed a commit
to jkim-julie/chromium
that referenced
this issue
Aug 20, 2018
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 Issue Igalia#435
msisov
pushed a commit
that referenced
this issue
Aug 27, 2018
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 Issue #435
msisov
pushed a commit
that referenced
this issue
Sep 11, 2018
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 Issue #435
msisov
pushed a commit
that referenced
this issue
Sep 11, 2018
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 Issue #435
msisov
pushed a commit
that referenced
this issue
Dec 23, 2018
Bug: b/118454994 Test: Manual Test Change-Id: I477a33cbb64a518d858584ac3f97d1550861ed7c Reviewed-on: https://chromium-review.googlesource.com/c/1300016 Commit-Queue: Yue Li <updowndota@chromium.org> Reviewed-by: Xiaohui Chen <xiaohuic@chromium.org> Reviewed-by: Xiyuan Xia <xiyuan@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#603349}(cherry picked from commit d46bc64) Reviewed-on: https://chromium-review.googlesource.com/c/1310565 Reviewed-by: Yue Li <updowndota@chromium.org> Cr-Commit-Position: refs/branch-heads/3578@{#435} Cr-Branched-From: 4226ddf-refs/heads/master@{#599034}
msisov
pushed a commit
that referenced
this issue
Jan 31, 2019
title. Bug: 915834 Change-Id: I0a2da5bc8d2184d0a73271b3d73a61b4a946977e Reviewed-on: https://chromium-review.googlesource.com/c/1381143 Commit-Queue: Jason Guo <jiahuiguo@chromium.org> Reviewed-by: Evan Stade <estade@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#617337}(cherry picked from commit cdc1ff1) Reviewed-on: https://chromium-review.googlesource.com/c/1382863 Reviewed-by: Jared Saul <jsaul@google.com> Cr-Commit-Position: refs/branch-heads/3626@{#435} Cr-Branched-From: d897fb1-refs/heads/master@{#612437}
msisov
pushed a commit
that referenced
this issue
Mar 14, 2019
By carefully removing un-necessary libc++ and android_support code, it is possible to reduce the size of the Chromium linker to a slim 38 kiB! This is achieved by using the quasi-magical |no_default_deps|. See bug for more details. BUG=931266 R=agrieve@chromium.org, pasko@chromium.org, yfriedman@chromium.org Change-Id: I1603d9ff44ae97bb4ae6213057687084866637b2 Reviewed-on: https://chromium-review.googlesource.com/c/1467101 Reviewed-by: Egor Pasko <pasko@chromium.org> Reviewed-by: Andrew Grieve <agrieve@chromium.org> Commit-Queue: David Turner <digit@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#631315}(cherry picked from commit 3bbb626) Reviewed-on: https://chromium-review.googlesource.com/c/1474291 Cr-Commit-Position: refs/branch-heads/3683@{#435} 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
Related commit b1f69a5.
The text was updated successfully, but these errors were encountered: