Consider hiding scheme and hash in moz-extension:// scheme URLS

NEW
Unassigned

Status

()

Toolkit
WebExtensions: Frontend
P5
normal
3 months ago
2 months ago

People

(Reporter: jkt, Unassigned)

Tracking

54 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [design-decision-approved] triaged)

(Reporter)

Description

3 months ago
After Bug 1266012 lands we should have a clear way to indicate a web extension.

I think we should hide "moz-extension://uuid/" as Firefox does for "http" as I think this is clear what has loaded it.

The uuid and moz-extension scheme are confusing for extension authors and their users. I think it would be great to hide and only show the path after "uuid/" in the URL bar.

So:

moz-extension://83c32c28-0d5a-4350-90cc-dcf2e0e0c79c/confirm-page.html?url=https://github.com/

Would only show:

[Extension (Containers)] /confirm-page.html?url=https://github.com/
The difference to HTTP is that for HTTP if you're editing the truncated displayed URI then it would still result in a valid URI (because you can omit the http:// when submitting). In your case, let's say I as a user want to change the url query parameter to "google.com", what happens if I do that and submit the new path "/confirm-page.html?url=https://google.com/" to the urlbar?
(Reporter)

Comment 2

3 months ago
The URL bar would have to make the change based on if there is an existing moz-extension:// in the site identity.
The same would be true if we decide to hide https:// in the URL also, with the exception Firefox would need to remember the uuid also.
(In reply to Jonathan Kingston [:jkt] from comment #2)
> The URL bar would have to make the change based on if there is an existing
> moz-extension:// in the site identity.

Depending on how you want to implement this you need to be aware of a couple of edge cases: In case you make the leading slash mandatory you're unable to tell if the user doesn't want to access a file:// location instead. In case we leave out the leading slash we don't have that problem, but the user could try to open a new page with confirm-page.html as a domain (we don't have a way of telling if a TLD is valid, see bug 1080682) or search for this exact thing.

Another approach would be to restore the full URL on urlbar focus and keep it around if pageproxystate is invalid (the urlbar was edited).

I'm also not sure if Toolkit/WebExtensions Frontend is the right component for this.
(Reporter)

Comment 4

3 months ago
Restoring the full URL seems on par with how I think Safari handles the editing HTTPS urls also so that is likely an easier pattern based on the other implementation idea.

Not sure on component either, this is where Bug 1266012 sits though. Feel free to move. I don't have time to implement this :andym asked me to raise it though.

Updated

3 months ago
Priority: -- → P5
Whiteboard: [design-decision-needed] triaged
Hi Jonathan, this has been added to the agenda for the June 13 WebExtension APIs triage meeting. Will you be able to join us? 

Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Next_Meeting

Agenda: https://docs.google.com/document/d/1A_M0YD86Plcs6eHyM2KXkDXY074BHZ3fZvaWXCljQLI/edit#heading=h.34n4lirhljve
Whiteboard: [design-decision-needed] triaged → [design-decision-approved] triaged
You need to log in before you can comment on or make changes to this bug.