fix: prevent touchscreen right-click context menu#1539
fix: prevent touchscreen right-click context menu#1539qxp930712 wants to merge 1 commit intolinuxdeepin:masterfrom
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: qxp930712 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Reviewer's guide (collapsed on small PRs)Reviewer's GuideThis PR restricts notification context menu activation to mouse right-clicks by updating TapHandler conditions to ignore right-click-style presses originating from touchscreen devices, preventing unintended context menus on touch long-press gestures. Sequence diagram for notification context menu activation with pointer device filteringsequenceDiagram
actor User
participant MouseDevice
participant TouchDevice
participant NotifyViewDelegate
participant TapHandlerRightClick
participant ContextMenu
rect rgb(230,230,250)
User->>MouseDevice: right_click
MouseDevice->>TapHandlerRightClick: press event
TapHandlerRightClick->>TapHandlerRightClick: onPressedChanged
Note over TapHandlerRightClick: pressed && point.device.type != PointerDevice.TouchScreen
TapHandlerRightClick->>NotifyViewDelegate: setting(point.position)
NotifyViewDelegate->>ContextMenu: open at position
end
rect rgb(250,230,230)
User->>TouchDevice: long_press
TouchDevice->>TapHandlerRightClick: press event
TapHandlerRightClick->>TapHandlerRightClick: onPressedChanged
Note over TapHandlerRightClick: pressed && point.device.type == PointerDevice.TouchScreen
TapHandlerRightClick--xContextMenu: do not open
end
Flow diagram for TapHandler onPressedChanged context menu conditionflowchart TD
A[onPressedChanged triggered] --> B{pressed}
B -->|false| Z[Exit without action]
B -->|true| C{point.device.type != PointerDevice.TouchScreen}
C -->|false| Z
C -->|true| D[Read pos = point.position]
D --> E[Call setting with pos]
E --> F[Context menu opens at pos]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've found 1 issue, and left some high level feedback:
- The
onPressedChangedguards assumepoint.deviceis always defined; consider defensively checkingpoint.device && point.device.type !== PointerDevice.TouchScreen(or equivalent) to avoid runtime errors in edge cases where no device is associated. - The two
TapHandlerblocks now contain identical logic for filtering out touchscreen right-clicks; consider extracting the shared behavior into a helper or common component to avoid duplication and keep future behavior changes in one place.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The `onPressedChanged` guards assume `point.device` is always defined; consider defensively checking `point.device && point.device.type !== PointerDevice.TouchScreen` (or equivalent) to avoid runtime errors in edge cases where no device is associated.
- The two `TapHandler` blocks now contain identical logic for filtering out touchscreen right-clicks; consider extracting the shared behavior into a helper or common component to avoid duplication and keep future behavior changes in one place.
## Individual Comments
### Comment 1
<location path="panels/notification/center/NotifyViewDelegate.qml" line_range="118" />
<code_context>
acceptedButtons: Qt.RightButton
onPressedChanged: function () {
- if (pressed) {
+ if (pressed && point.device.type !== PointerDevice.TouchScreen) {
let pos = point.position
setting(pos)
</code_context>
<issue_to_address>
**suggestion:** Use TapHandler's acceptedDevices instead of checking device type inside the handler.
Rather than checking `point.device.type !== PointerDevice.TouchScreen` in `onPressedChanged`, configure the appropriate `acceptedDevices` (e.g. `PointerDevice.Mouse`) on `TapHandler`. This keeps the handler focused on the press logic and centralizes device filtering in the declarative properties, avoiding duplicated conditions.
Suggested implementation:
```
TapHandler {
acceptedButtons: Qt.RightButton
acceptedDevices: PointerDevice.Mouse
onPressedChanged: function () {
if (pressed) {
let pos = point.position
setting(pos)
}
```
```
TapHandler {
acceptedButtons: Qt.RightButton
acceptedDevices: PointerDevice.Mouse
onPressedChanged: function () {
if (pressed) {
let pos = point.position
setting(pos)
}
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| acceptedButtons: Qt.RightButton | ||
| onPressedChanged: function () { | ||
| if (pressed) { | ||
| if (pressed && point.device.type !== PointerDevice.TouchScreen) { |
There was a problem hiding this comment.
suggestion: Use TapHandler's acceptedDevices instead of checking device type inside the handler.
Rather than checking point.device.type !== PointerDevice.TouchScreen in onPressedChanged, configure the appropriate acceptedDevices (e.g. PointerDevice.Mouse) on TapHandler. This keeps the handler focused on the press logic and centralizes device filtering in the declarative properties, avoiding duplicated conditions.
Suggested implementation:
TapHandler {
acceptedButtons: Qt.RightButton
acceptedDevices: PointerDevice.Mouse
onPressedChanged: function () {
if (pressed) {
let pos = point.position
setting(pos)
}
TapHandler {
acceptedButtons: Qt.RightButton
acceptedDevices: PointerDevice.Mouse
onPressedChanged: function () {
if (pressed) {
let pos = point.position
setting(pos)
}
Modified notification view delegate to check for touchscreen device type before showing context menu on right-click. Added PointerDevice.TouchScreen type check to both TapHandler instances in the DelegateChooser. The previous implementation would trigger context menu on right-click gestures from touchscreen devices, which was unintended behavior. Touchscreen right-clicks are typically long-press gestures that should not open the same context menu as mouse right-clicks. This change ensures context menus only appear when using mouse input devices. Influence: 1. Test right-click with mouse on notification items - context menu should appear 2. Test long-press/touch gestures on touchscreen devices - context menu should not appear 3. Verify regular left-click functionality remains unchanged 4. Test touchscreen interactions with other gestures to ensure no regression PMS: BUG-355017
Modified notification view delegate to check for touchscreen device type before showing context menu on right-click. Added PointerDevice.TouchScreen type check to both TapHandler instances in the DelegateChooser.
The previous implementation would trigger context menu on right-click gestures from touchscreen devices, which was unintended behavior. Touchscreen right-clicks are typically long-press gestures that should not open the same context menu as mouse right-clicks. This change ensures context menus only appear when using mouse input devices.
Influence:
PMS: BUG-355017
Summary by Sourcery
Bug Fixes: