Bug 1829130 - tooltips do not appear
Summary: tooltips do not appear
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: waybar
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Aleksei Bavshin
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-04-29 00:07 UTC by copr
Modified: 2020-05-30 01:53 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-30 01:53:47 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description copr 2020-04-29 00:07:36 UTC
Description of problem:

tooltips do not appear, printing the following warning:

"Couldn't map window 0x5642c99d1440 as subsurface because its parent is not mapped."


Version-Release number of selected component (if applicable): 0.9.2


How reproducible: every waybar start


Steps to Reproduce:
1. start with default config
2. hover over some module with a tooltip, e.g clock

Actual results:

tooltip does not appear, warning appears in log

Expected results:

tooltip appears

Additional info:

Comment 1 Aleksei Bavshin 2020-04-29 00:33:32 UTC
Can you please try setting "layer": "top" in the waybar config file?

There is an issue[1] in sway where popups for layer-shell surfaces are rendered on the same layer as a main surface. For instance, waybar's default layer is "bottom" and any tooltips from waybar would be displayed behind the windows on active workspace. This is already fixed in sway git master and will be included in next release.

Also, warning is completely unrelated to the issue. That's just a harmless consequence of forcing GTK to work with custom wayland surfaces.

[1] https://github.com/swaywm/sway/issues/4684
See also: https://github.com/Alexays/Waybar/issues/16

Comment 2 Till Hofmann 2020-04-29 06:52:54 UTC
Would it make sense to apply the patch in sway before a new sway is released?

Comment 3 copr 2020-04-29 13:00:08 UTC
I can confirm the "layer": "top" workaround works.

If sway can't be patched, perhaps it would make sense to make this the default so the package ships in a working state?

Comment 4 Aleksei Bavshin 2020-05-01 01:49:43 UTC
Considering the reason for default layer change, conflict with dmenu/bemenu/wofi/etc...[1], it really makes sense to patch sway instead of guessing which default layer annoys more users. And maybe look into changing sway code so that newer (or not exclusive) surfaces come up first when going through the list of layer surfaces for the layer.

Anyways, the sway patch is small, looks safe and I haven't seen any reports that it breaks something. I made a PR[2] for `rpms/sway`, and I'll merge it into f32 unless anyone has objections.

[1] https://github.com/Alexays/Waybar/issues/114
[2] https://src.fedoraproject.org/rpms/sway/pull-request/7

Comment 5 Fedora Update System 2020-05-04 08:21:19 UTC
FEDORA-2020-189a42d65a has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-189a42d65a

Comment 6 Fedora Update System 2020-05-05 05:11:49 UTC
FEDORA-2020-189a42d65a has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-189a42d65a`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-189a42d65a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 7 Fedora Update System 2020-05-30 01:53:47 UTC
FEDORA-2020-189a42d65a has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.