1915595 - bottom-of-window URLs shown when hovering on a link don't percent-encode the same way as the addressbar

Status: NEW

(Firefox :: General, defect)

Description

[little.sock3082]

Attachment: safari-status-bar.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:129.0) Gecko/20100101 Firefox/129.0

Steps to reproduce:

Was reading https://embracethered.com/blog/posts/2024/m365-copilot-prompt-injection-tool-invocation-and-data-exfil-using-ascii-smuggling/ and got to the section titled "An Example Link With Hidden Data". When I hover over the link in Firefox, it doesn't render the trailing Unicode characters.

Actual results:

The status bar only shows https://wuzzi.net/ instead of https://wuzzi.net/%F3%A0%81%94%F3%A0%81%B2%F3%A0%81%B5%F3%A0%81%B3%F3%A0%81%B4%F3%A0%81%8E%F3%A0%81%AF%F3%A0%81%81%F3%A0%81%89

Expected results:

The status bar should show the full URL and not drop the trailing Unicode characters.

Safari/Chrome both show the Unicode. I've attached a screenshot of safari.

Comment 1

[Francesco Lodolo [:flod]]

Not sure if there's a better component for this, as we don't have a status bar anymore.

Comment 2

[Daniel Veditz [:dveditz]]

The "status bar" (vestigial) hover-text is a lie. On a malicious site you can never ever trust it (e.g. bug 229050 for one example)

Comment 3

[James Teow [:jteow]]

I'm a little confused :flod, isn't the the status bar the text on the bottom left? It still appears for me on the bottom left.

Daniel, is the current behaviour intentional? If so and given the fact that a site could customize the result, it seems like this bug could be closed but we just want to make sure.

Comment 4

[Francesco Lodolo [:flod]]

(In reply to James Teow [:jteow] from comment #3)

I'm a little confused :flod, isn't the the status bar the text on the bottom left? It still appears for me on the bottom left.

Firefox used to have a "proper" status bar that showed more info, was always visible, and could be extended by extension. I wouldn't call the current link preview a status bar, but I also don't have a better name for it.

Comment 5

[Daniel Veditz [:dveditz]]

Firefox used to have a "proper" status bar that showed more info, was always visible, and could be extended by extension.

If anyone is curious to see how it worked you can try Thunderbird. If the status bar isn't visible by default you can enable it under "Toolbars" on the "View" menu.

I wouldn't call the current link preview a status bar, but I also don't have a better name for it.

Same!

Daniel, is the current behaviour intentional? If so and given the fact that a site could customize the result, it seems like this bug could be closed but we just want to make sure.

First let's define the "current behavior" for clarity since the original description that Firefox "doesn't render all Unicode Tags" is the opposite of what happens. In the status-y bottom hover text we ARE rendering the URL as Unicode, whereas in the address bar we would show the characters in THIS example percent-encoded. These particular characters are essentially invisible missing glyphs, but we ARE displaying their nothingness and didn't do anything special to "strip them off". Apparently the status bar text uses Services.textToSubURI.unEscapeURIForUI() which more aggressively decodes the URL for a prettier presentation. The address bar has to more scrupulously preserve a syntactically valid URL that can be edited and reused, and can be copied into other programs without causing errors.

I understand the allure of "prettier", but in THIS case it would be better if the hover-text matched what will appear in the URL bar (assuming the site doesn't play tricks). That would better align with what people think they are getting out of inspecting that hover text.

What people don't understand is that the hover text is only reliable on a benign site. But then, most users spend most of their time on benign sites. Changing the hover text to match the address bar escaping would be an improvement for people. But it's not a security protection against malicious sites so it would be fair to give it a low priority.

Comment 6

[James Teow [:jteow]]

Thank you :dveditz and :flod. This came up in our General Triage meeting.

With that context, it makes sense to keep it open. And I'll leave it in General since Link Target Display is located in browser.js