| KWin |
Decoration is destroyed at some point before DecorationButton, as seen
by the existing use of QPointer for holding the Decoration.
Use of a weak pointer without guarding seems wrong.
Every other connect (DecorationButton::Private::init) that proxies to
the decorationimplementation in kwin guards against this by setting the
connect lifespan to match decoration. This one connect was out of sync.
BUG: 396723
CCBUG: 396729
Ran kwin.
Checked I still had tooltips
Didn't try to reproduce the original crash
| No Linters Available |
| No Unit Test Coverage |
| Buildable 1052 | |
| Build 1065: arc lint + arc unit |
Probably stupid question, but still.. Why had only one receiver been changed to decoration.data()? Why that's not the case for
connect(this, &DecorationButton::hoveredChanged, this, updateSlot);
?
Just for reference
void DecorationButton::update(const QRectF &rect) { decoration()->update(rect.isNull() ? geometry().toRect() : rect.toRect()); }
Shouldn't decoration() be guarded there?
The hovered state cannot change if there is no decoration. Hover is from an event handler from Decoration. I doubt that this change here can fix the crash. Also that's the explanation for the update slot not checking: no hover change if there's no decoration.
The crash is weird: we did have a crash related to tooltips, but it's fixed.
What's really strange is that requestShowTooltip comes from the event loop. But nothing in kdecoration or in KWin goes through a queued event to KWin::Decoration::DecoratedClientImpl::requestShowToolTip.
Could it be a decoration plugin causing this?