Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ge and gE don't work properly with text fragments #4564

Open
leoheitmannruiz opened this issue Oct 26, 2024 · 4 comments
Open

ge and gE don't work properly with text fragments #4564

leoheitmannruiz opened this issue Oct 26, 2024 · 4 comments

Comments

@leoheitmannruiz
Copy link
Contributor

Describe the bug

When at a URL that has a text fragment and pressing ge or gE, the text fragment part of the URL is not shown in the vomnibar.

Interestingly, yy works fine.

Also, while at the URL mentioned below, pressing gu doesn't seem to do anything, while gU correctly sends you to https://example.com/. I'm not sure whether I want gu to do the same as gU, here, but it certainly felt a little weird for the text fragment to stay.

To Reproduce

  1. Go to https://example.com/#:~:text=for
  2. Press ge or gE

Browser and Vimium version

Firefox 131.0.3-1
macOS Sequoia 15.0.1
Vimium 2.1.2

@leoheitmannruiz
Copy link
Contributor Author

Perhaps of interest to you @UncleSnail ? :)

@UncleSnail
Copy link
Contributor

I don't really use those commands, or almost ever use text fragments, so I can't speak into them too much. It does appear that the ge/E functionality is incorrect, and it should probably include the text fragment, although that behavior might be intentional.

The gu vs gU functionality also might be wrong. Since both gU and yy work correctly, I would imagine this is just a "bug" in how the URL is parsed into levels in the hierarchy, and those two commands work because they just take the whole thing, or the root, respectively. However, since ge does not just edit the whole URL, like yy does, it seems like they might possibly be intentionally cutting off "extra" stuff. However, query params etc. stay, so... I'd say this probably isn't intended functionality.

But I also don't want to go change how these commands parse URLs when I don't actually understand how they are intended to do so. So I'd say this is probably a bug, and I theoretically could fix it, but it might not be a bug and it's not really in a domain I am familiar with.

@leoheitmannruiz
Copy link
Contributor Author

However, since ge does not just edit the whole URL, like yy does, it seems like they might possibly be intentionally cutting off "extra" stuff.

I tried taking a quick look and it doesn't seem like there's any cutting of extra stuff. Though, I might as well completely misunderstand:

https://github.com/philc/vimium/blob/master/content_scripts/vomnibar.js#L42-L48

@UncleSnail
Copy link
Contributor

Good point. The code you point out there uses the window.location.href property to get the URL, which returns a location object. Looking at the spec, it does include a hash, but clearly not text fragments.

In the Text fragment doc it says "In a similar manner to document fragments, text fragments are appended onto a URL after a hash symbol (#).", which would imply that text fragments are different and potentially "aren't considered a part of the URL" (they are appended on the end, not a part of it?), so that could make sense. Also of note from the same page is "Text fragments are invoked only on full (non-same-page), user-initiated navigations." which might give us trouble using them in a URL edit anyway.

The case that does work, yy, uses a different method: chrome.runtime.sendMessage({ handler: "getCurrentTabUrl" }.... I imagine if we wanted to support text fragments everywhere, we could use this method for getting the URL instead.

I can see the use of having text fragment support, although editing one that is in the URL already doesn't seem very frequently useful (text fragments are more for sharing links, not typing them and going there yourself. You can still edit the current URL, type a text fragment on the end, copy it, and share, but if text fragments are supported somewhere, it's true we should support them everywhere. Currently you can edit to add a text fragment and it works mostly properly as long as the fragment is one word, or you encode the URI component yourself: IE, don't type spaces).

Something that I would potentially use them for in vimium is if there were a single command to add the highlighted text to a text fragment, then copy that URL to the clipboard for sharing. That would be very convenient for referencing web pages, and I'd happily look into building that feature if Phil thinks it's a good idea. Chrome has a "Copy Link to Highlight" feature on right click that does this, but I don't know of a good way to do it in Firefox (without an addon). A keypress in Vimium for this functionality would be nicer though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants