Not all URLs have keyboard shortcuts visible #409

Closed
opened 7 months ago by zsolt-donca · 26 comments

When entering the URL mode with CTRL+SHIFT+u and subsequently pressing t, not all URLs have a keyboard shortcut visible. For example:

image

As you can see, only D is there, but the first link does not have a hotkey visible. Even though it's not visible, if I press a, it still opens the first URL (archlinux.org).

It might have something to do with the URL itself, as I I switch the order of the URLs, still the same URL has the highlight visible, even though the shortcut changed:

image

In both cases, both a and d work and open the respective URLs in the browser.

I am on Arch Linux, and using foot version 1.7.0-2 from the AUR package.

Since updating to 1.7.x I've actually updated my config file, and it should be mostly the same as the default one, with only some changes with regards to fonts and themes. I can paste the configuration if deemed relevant.

When entering the URL mode with `CTRL+SHIFT+u` and subsequently pressing `t`, not all URLs have a keyboard shortcut visible. For example: ![image](/attachments/cbfea3ea-20be-45f9-a04c-d246ef7a8899) As you can see, only `D` is there, but the first link does not have a hotkey visible. Even though it's not visible, if I press `a`, it still opens the first URL (archlinux.org). It might have something to do with the URL itself, as I I switch the order of the URLs, still the same URL has the highlight visible, even though the shortcut changed: ![image](/attachments/6c6d2dca-83ae-48a0-8b31-6d47a02f7102) In both cases, both `a` and `d` work and open the respective URLs in the browser. I am on Arch Linux, and using foot version `1.7.0-2` from the [AUR package](https://aur.archlinux.org/packages/foot/). Since updating to 1.7.x I've actually updated my config file, and it should be mostly the same as the default one, with only some changes with regards to fonts and themes. I can paste the configuration if deemed relevant.
Owner

Weird issue... And I'm afraid I can't reproduce...

Do the labels return if you press 't' again?

Which compositor, and version, are you running?

Would you be willing to test patches I send your way? I'm thinking of adding additional logging to try to figure out what's happening.

Weird issue... And I'm afraid I can't reproduce... Do the labels return if you press 't' again? Which compositor, and version, are you running? Would you be willing to test patches I send your way? I'm thinking of adding additional logging to try to figure out what's happening.
Poster

Do the labels return if you press 't' again?

The labels don't if I press t again, in fact, pressing t once the labels are shown doesn't do anything for me.

Which compositor, and version, are you running?

I am running latest master builds of sway and wlroots, and currently being on 03daa53a0e and e8ad05913f, respectively. Note that the reason I am on these development builds is because I am using a patched version of these (see https://aur.archlinux.org/packages/sway-hidpi-git/ and https://aur.archlinux.org/packages/wlroots-hidpi-git/).

If you suspect that this is related to the compositor, I can try with the latest official releases.

Would you be willing to test patches I send your way? I'm thinking of adding additional logging to try to figure out what's happening.

Of course, I'd gladly try out some patched build and get the logs back.

> Do the labels return if you press 't' again? The labels don't if I press `t` again, in fact, pressing `t` once the labels are shown doesn't do anything for me. > Which compositor, and version, are you running? I am running latest master builds of `sway` and `wlroots`, and currently being on https://github.com/swaywm/sway/commit/03daa53a0ef63d2a72acda05e94e5ba5c0b50d33 and https://github.com/swaywm/wlroots/commit/e8ad05913fb9fbefd2aa4b89cebfca03ab2bd1eb, respectively. Note that the reason I am on these development builds is because I am using a patched version of these (see https://aur.archlinux.org/packages/sway-hidpi-git/ and https://aur.archlinux.org/packages/wlroots-hidpi-git/). If you suspect that this is related to the compositor, I can try with the latest official releases. > Would you be willing to test patches I send your way? I'm thinking of adding additional logging to try to figure out what's happening. Of course, I'd gladly try out some patched build and get the logs back.
Owner

The labels don't if I press t again, in fact, pressing t once the labels are shown doesn't do anything for me.

With "label", I mean the yellow rectangle showing both the shortcut, and the URL itself. The URL shouldn't be visible initially. Pressing t should toggle the visibility of the URLs, but the labels themselves, with the shortcut, should always be visible.

So are you saying that after pressing 't' the first time (thus revealing the URLs), pressing 't' again doesn't hide the URLs?

If you suspect that this is related to the compositor, I can try with the latest official releases.

I tested on both 1.5.1, and adf7a6f8921a025fd07cfd1e58f19f589c8f31b3.

If you could test with a Sway build without any sway- or wlroots patches, that would be great.

Of course, I'd gladly try out some patched build and get the logs back.

If you're still having issues on vanilla Sway, I'll whip something together.

> The labels don't if I press t again, in fact, pressing t once the labels are shown doesn't do anything for me. With "label", I mean the yellow rectangle showing both the shortcut, and the URL itself. The URL shouldn't be visible initially. Pressing <kbd>t</kbd> should toggle the visibility of the URLs, but the labels themselves, with the shortcut, should always be visible. So are you saying that after pressing 't' the first time (thus revealing the URLs), pressing 't' again doesn't hide the URLs? > If you suspect that this is related to the compositor, I can try with the latest official releases. I tested on both 1.5.1, and [adf7a6f8921a025fd07cfd1e58f19f589c8f31b3](https://github.com/swaywm/sway/commit/adf7a6f8921a025fd07cfd1e58f19f589c8f31b3). If you could test with a Sway build without any sway- or wlroots patches, that would be great. > Of course, I'd gladly try out some patched build and get the logs back. If you're still having issues on vanilla Sway, I'll whip something together.
Poster

With "label", I mean the yellow rectangle showing both the shortcut, and the URL itself. The URL shouldn't be visible initially. Pressing t should toggle the visibility of the URLs, but the labels themselves, with the shortcut, should always be visible.
So are you saying that after pressing 't' the first time (thus revealing the URLs), pressing 't' again doesn't hide the URLs?

Yes, that is true. This whole thing behaves very differently for me. I'll try to show it step-by-step:

Step 0: I just have some URLs in my terminal:

image

Step 1: I press CTRL+SHIFT+u:

image

Step 2: I press t:

image

At this state, pressing t again doesn't do anything. I can press a and d to open the links, even though d doesn't show.

I can exit by pressing Esc.

If you could test with a Sway build without any sway- or wlroots patches, that would be great.

Yes, I will do that and get back here with the results.

>With "label", I mean the yellow rectangle showing both the shortcut, and the URL itself. The URL shouldn't be visible initially. Pressing t should toggle the visibility of the URLs, but the labels themselves, with the shortcut, should always be visible. >So are you saying that after pressing 't' the first time (thus revealing the URLs), pressing 't' again doesn't hide the URLs? Yes, that is true. This whole thing behaves very differently for me. I'll try to show it step-by-step: Step 0: I just have some URLs in my terminal: ![image](/attachments/c0c56dd4-2a84-45cd-bf8b-3c702a4fc616) Step 1: I press `CTRL+SHIFT+u`: ![image](/attachments/e7aef899-0cbf-4852-b428-61118a0d3570) Step 2: I press `t`: ![image](/attachments/38398219-7f00-4eb9-b931-17be44f824b0) At this state, pressing `t` again doesn't do anything. I can press `a` and `d` to open the links, even though `d` doesn't show. I can exit by pressing `Esc`. >If you could test with a Sway build without any sway- or wlroots patches, that would be great. Yes, I will do that and get back here with the results.
Owner

Yes, that is true. This whole thing behaves very differently for me. I'll try to show it step-by-step:

Thanks for the detailed description. That sounds a lot like a compositor issue, where it is having issues synchronizing sub-surfaces (the labels) with their parent surface (the main window).

> Yes, that is true. This whole thing behaves very differently for me. I'll try to show it step-by-step: Thanks for the detailed description. That sounds **a lot** like a compositor issue, where it is having issues synchronizing sub-surfaces (the labels) with their parent surface (the main window).
Poster

If you could test with a Sway build without any sway- or wlroots patches, that would be great.

I just installed sway version 1.5.1-1 and wlroots version 0.12.0-1 from the official repos and the URLs functionality works just as you described in your previous post, such as after pressing CTRL+SHIFT+u:

image

What should we do now? If this is a sway/wlroots issue, then I could maybe bisect to find the culprit and report it there, but I cannot really tell more than foot is not showing some labels well.

I will also confirm if this is somehow related to my patches, but I doubt that, since that's supposed to be related to XWayland.

> If you could test with a Sway build without any sway- or wlroots patches, that would be great. I just installed `sway` version `1.5.1-1` and `wlroots` version `0.12.0-1` from the official repos and the URLs functionality works just as you described in your previous post, such as after pressing `CTRL+SHIFT+u`: ![image](/attachments/7066eb9f-011a-44a0-921a-91280a371e81) What should we do now? If this is a sway/wlroots issue, then I could maybe bisect to find the culprit and report it there, but I cannot really tell more than foot is not showing some labels well. I will also confirm if this is somehow related to my patches, but I doubt that, since that's supposed to be related to XWayland.
Owner

Let's start with a bisect and see where that takes us.

Let's start with a bisect and see where that takes us.
Poster

Thank you for the investigation so far. I will start bisecting wlroots and sway, will probably take me a few days, will get back here once I learn anything.

Thank you for the investigation so far. I will start bisecting wlroots and sway, will probably take me a few days, will get back here once I learn anything.
Owner

FWIW, I just tested Sway 03daa53a0ef63d2a72acda05e94e5ba5c0b50d33 and wlroots 6230f7be4f92b83df7ea8e6487410b3b81dd4b1d, and those still work as intended for me.

FWIW, I just tested Sway [03daa53a0ef63d2a72acda05e94e5ba5c0b50d33](https://github.com/swaywm/sway/commit/03daa53a0ef63d2a72acda05e94e5ba5c0b50d33) and wlroots [6230f7be4f92b83df7ea8e6487410b3b81dd4b1d](https://github.com/swaywm/wlroots/commit/6230f7be4f92b83df7ea8e6487410b3b81dd4b1d), and those still work as intended for me.
Poster

FWIW, I just tested Sway 03daa53a0e and wlroots 6230f7be4f, and those still work as intended for me.

I just installed an untouched version of those exact revisions (those being the latest as of writing this) using the AUR packages sway-git and wlroots-git, and the issue is still there for me.

This screenshot should show both the versions of my packages and the issue itself:

image

How could it be that we are having different behavior for the same commits?

EDIT: Right now I have nothing left of the "hidpi" patch set on my system, so at least that's ruled out.

> FWIW, I just tested Sway https://github.com/swaywm/sway/commit/03daa53a0ef63d2a72acda05e94e5ba5c0b50d33 and wlroots https://github.com/swaywm/wlroots/commit/6230f7be4f92b83df7ea8e6487410b3b81dd4b1d, and those still work as intended for me. I just installed an untouched version of those exact revisions (those being the latest as of writing this) using the AUR packages [sway-git](https://aur.archlinux.org/packages/sway-git/) and [wlroots-git](https://aur.archlinux.org/packages/wlroots-git/), and the issue is still there for me. This screenshot should show both the versions of my packages and the issue itself: ![image](/attachments/56640c5d-42e7-4a2c-8f9f-58150cc8059e) How could it be that we are having different behavior for the same commits? EDIT: Right now I have nothing left of the "hidpi" patch set on my system, so at least that's ruled out.
826 KiB
Owner

How could it be that we are having different behavior for the same commits?

Good question... We're obviously missing something... but a bisect is probably still the best place to start an investigation.

> How could it be that we are having different behavior for the same commits? Good question... We're obviously missing something... but a bisect is probably still the best place to start an investigation.
Poster

I found through experimentation that the issue is related to DPI.

With a scaling factor on my display (swaymsg "output eDP-1 scale 1"), no matter what the dpi-aware settings are in my foot.ini, the URL highlighting works well, there are no issues:

image

However, with a scaling factor of 2 (which I normally use), if I set dpi-aware=no in foot.ini, then the issue is there. That's what I was using when opening this report. The issue is not there with dpi-aware=yes even with a scaling factor > 1.

When I checked the latest stable sway and wlroots releases, I used my usual config, which is with scale = 2 and dpi-aware=no, and it worked, so it's still related to the compositor. I did not yet have time to do the bisecting, but I hope I'll soon do.

I found through experimentation that the issue is related to DPI. With a scaling factor on my display (`swaymsg "output eDP-1 scale 1"`), no matter what the `dpi-aware` settings are in my `foot.ini`, the URL highlighting works well, there are no issues: ![image](/attachments/08869eed-1e23-41ce-83c1-1a38aca2bdf7) However, with a scaling factor of 2 (which I normally use), if I set `dpi-aware=no` in `foot.ini`, then the issue is there. That's what I was using when opening this report. The issue is not there with `dpi-aware=yes` even with a scaling factor > 1. When I checked the latest stable `sway` and `wlroots` releases, I used my usual config, which is with scale = 2 and `dpi-aware=no`, and it worked, so it's still related to the compositor. I did not yet have time to do the bisecting, but I hope I'll soon do.
Owner

Just to be sure, you're explicitly setting dpi-aware=no|yes? I.e it's never using its default value?

I find this intriguing... I can sort of see how the scale factor can be related. But the dpi-aware option should only affect the font size...

Anyway, nice find!

Just to be sure, you're explicitly setting dpi-aware=no|yes? I.e it's never using its default value? I find this intriguing... I can sort of see how the scale factor can be related. But the dpi-aware option should only affect the font size... Anyway, nice find!
Poster

Just to be sure, you're explicitly setting dpi-aware=no|yes? I.e it's never using its default value?

Yes, I was explicitly setting it to either yes or no in the config.

> Just to be sure, you're explicitly setting dpi-aware=no|yes? I.e it's never using its default value? Yes, I was explicitly setting it to either `yes` or `no` in the config.
Owner

I've been able to reproduce on latest sway+wlroots, with scale=2 and dpi-aware=no

I've been able to reproduce on latest sway+wlroots, with scale=2 and dpi-aware=no
Owner

And, fwiw, it does not reproduce under gnome, with the same setup.

And, fwiw, it does **not** reproduce under gnome, with the same setup.
Owner

Weston also seems fine

Weston also seems fine
Owner

I don't think dpi-aware has anything to do with this. But font size does. Or rather, I think it has to do with the location of the labels

I don't think dpi-aware has anything to do with this. But font size does. Or rather, I think it has to do with the location of the labels
Owner

This is almost funny... It appears the labels must have an even width and an even height for them to be shown.

If either the width or the height is odd, the labels don't show up.

This is almost funny... It appears the labels must have an even width and an even height for them to be shown. If either the width or the height is odd, the labels don't show up.
Owner

Would you mind opening a bug on Sway?

[10:33] dnkl: Here's an interesting bug, on recent Sway+wlroots, sub-surfaces with either an odd width, or and odd height isn't displayed by Sway, when the scale factor is > 1. #409
[10:33] dnkl: Works add intended on Sway 1.5.1 and wlroots 0.12, mutter and weston
[10:34] emersion: hm, please report a bug
[10:37] dnkl: emersion: ok, will do later today. Or ask the user who reported the issue.

Would you mind opening a bug on Sway? > [10:33] dnkl: Here's an interesting bug, on recent Sway+wlroots, sub-surfaces with either an odd width, or and odd height isn't displayed by Sway, when the scale factor is > 1. https://codeberg.org/dnkl/foot/issues/409 [10:33] dnkl: Works add intended on Sway 1.5.1 and wlroots 0.12, mutter and weston [10:34] emersion: hm, please report a bug [10:37] dnkl: emersion: ok, will do later today. Or ask the user who reported the issue.
Owner

I've also verified the other sub-surfaces used by foot has the same problem.

I've also verified the other sub-surfaces used by foot has the same problem.
Poster

I just opened an issue in sway: https://github.com/swaywm/sway/issues/6136

I just opened an issue in sway: https://github.com/swaywm/sway/issues/6136
Owner

Thanks. Looks like it's foot's fault after all:

It should be noted that buffer sizes must be divisible with their buffer scale, so if foot sets the buffer scale to 2, then the size must not be odd

Thanks. Looks like it's foot's fault after all: > It should be noted that buffer sizes must be divisible with their buffer scale, so if foot sets the buffer scale to 2, then the size must not be odd
Poster

Thanks. Looks like it's foot's fault after all:

That would be a weird conclusion to me given that you checked with all other Wayland compositors and it was working fine, including weston, the reference compositor. I'm not saying that those cannot have bugs or anything, but if the protocol doesn't allow such surfaces, then why isn't it implemented/enforced in other compositors? And is it a good idea to still do so in sway? I am worried about such small isuees, and possible fragmentation.

I don't claim to understand what I'm talking about, these are just some ideas from the top of my head.

EDIT: the issue was closed with this conclusion: https://github.com/swaywm/sway/issues/6136

> Thanks. Looks like it's foot's fault after all: That would be a weird conclusion to me given that you checked with all other Wayland compositors and it was working fine, including `weston`, the reference compositor. I'm not saying that those cannot have bugs or anything, but if the protocol doesn't allow such surfaces, then why isn't it implemented/enforced in other compositors? And is it a good idea to still do so in sway? I am worried about such small isuees, and possible fragmentation. I don't claim to understand what I'm talking about, these are just some ideas from the top of my head. EDIT: the issue was closed with this conclusion: https://github.com/swaywm/sway/issues/6136
Owner

It's actually documented: 1349d3d15b/protocol/wayland.xml (L1399)

The new size of the surface is calculated based on the buffer
size transformed by the inverse buffer_transform and the
inverse buffer_scale. This means that at commit time the supplied
buffer size must be an integer multiple of the buffer_scale. If
that's not the case, an invalid_size error is sent.

It's actually documented: https://gitlab.freedesktop.org/wayland/wayland/-/blob/1349d3d15bf7d100d0eae52d976a121d2dcf32ce/protocol/wayland.xml#L1399 > The new size of the surface is calculated based on the buffer size transformed by the inverse buffer_transform and the inverse buffer_scale. This means that at commit time the supplied buffer size must be an integer multiple of the buffer_scale. If that's not the case, an invalid_size error is sent.
dnkl added the
bug
label 7 months ago
dnkl closed this issue 7 months ago
Poster

Thanks for the prompt fix! I just switched over to foot-git in AUR and can confirm that the issue is resolved!

Not sure if it's relevant to this fix or not, since using foot-git, my mouse cursor is now suddenly huge when over a foot window; I will open an separate issue for it.

Thanks for the prompt fix! I just switched over to [foot-git](https://aur.archlinux.org/packages/foot-git/) in AUR and can confirm that the issue is resolved! Not sure if it's relevant to this fix or not, since using foot-git, my mouse cursor is now suddenly huge when over a foot window; I will open an separate issue for it.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.