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?

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.

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.

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