[Wayland] Shift not registered first time after launching with Sway compositor
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Tracking
()
People
(Reporter: wbertrums, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0
Steps to reproduce:
I'm using Firefox 77.0-1 (with MOZ_USE_XINPUT2=1 and MOZ_ENABLE_WAYLAND=1) and Sway 1.4-2 on Debian Unstable.
- Open Firefox.
- Wait for the window to appear.
- Start holding Shift.
- Press for example 1.
When starting with holding Shift before the Firefox window appears, this bug doesn't happen. This bug also doesn't happen if you press any key before holding Shift.
Actual results:
1 appeared in the address bar.
Expected results:
! (assuming US keyboard layout) appears in the address bar.
![]() |
||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Hi Masayuki,
Could you please help to take a look? Thank you.
I don't have environment to run Wayland, and I don't know about our widget code for Wayland.
Makoto-san, do you know who could handle this in widget peers?
Comment 3•4 years ago
|
||
I cannot reproduce on Firefox Nightly 79 and Firefox 77.0.1 on Debian/sid with GNOME3 or Weston.
Wout, I have questions.
Q1. Do you reproduce this on the latest Firefox Nightly from https:///nightly.mozilla.org?
Q2. Do you reproduce this on other Wayland compositor such as Weston?
A1. I could reproduce it in Nightly. I found out that when clicking anywhere before holding Shift, the issue also doesn't occur.
A2. I couldn't reproduce this with a GNOME Shell session or with a nested Weston.
I want to do some more testing later and I'll update the issue then.
I just tried Firefox 66 and there the issue also happens.
I also tested with Xwayland on Sway and then it doesn't happen.
Comment 6•4 years ago
|
||
Thank you. is this issue Sway bug?
I don't know, Sway's issue tracker tells me:
Additionally, problems with Firefox are almost certainly Firefox bugs, not sway bugs. Start by submitting your issue to the Firefox Bugzilla and come back here only after they confirm otherwise.
It seems to be a Sway (or wlroots) issue in handling applications having multiple wl_keyboard instances, see https://github.com/swaywm/sway/issues/5462.
Fixed upstream in https://github.com/swaywm/wlroots/pull/2284
Comment 10•4 years ago
|
||
Thank you, emersion and Wout B.
Description
•