Return early if close button accepts input event
ClosedPublic

Authored by davidedmundson on Tue, Feb 11, 9:29 PM.

Details

Summary

Otherwise we close the effect whenever the close is pressed which is a
behavioural change.

That in turn leads to bigger bugs

BUG: 415155

Test Plan

Ran effect
Clicked on the "Whitespace" of the dash
Clicked on the close

Now matches desktopgrid code

Diff Detail

Repository
R108 KWin
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
davidedmundson created this revision.Tue, Feb 11, 9:29 PM
Restricted Application added a project: KWin. · View Herald TranscriptTue, Feb 11, 9:29 PM
Restricted Application added a subscriber: kwin. · View Herald Transcript
davidedmundson requested review of this revision.Tue, Feb 11, 9:29 PM
zzag added a subscriber: zzag.Tue, Feb 11, 10:22 PM
zzag added inline comments.
effects/presentwindows/presentwindows.cpp
541

Wouldn't it be better to check QEvent::isAccepted() in EffectsHandlerImpl::checkInputWindowEvent()?

zzag accepted this revision.Tue, Feb 11, 10:50 PM
zzag added inline comments.
effects/presentwindows/presentwindows.cpp
541

Urgh, no, it seems like n effects can do mouse interception by design, please ignore me.

This revision is now accepted and ready to land.Tue, Feb 11, 10:50 PM
ngraham accepted this revision.Wed, Feb 12, 12:48 AM
ngraham added a subscriber: ngraham.

Fixes the bug. Can we get this on the stable branch?

This revision was automatically updated to reflect the committed changes.