1298549 - When browser.urlbar.trimURLs is false, the URL bar still prefixes "http" for URIs while the page is loading when copying them

Status: RESOLVED WONTFIX

(Firefox :: Address Bar, defect)

Description

[fbrfa8.g]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160601155443

Steps to reproduce:

open a blank tab
navigate to a slow loading page, like 127.0.0.1
url bar displays: 127.0.0.1
While page is loading, copy the url from the url bar
http://127.0.0.1/


here is a test script that can start a slow loading page
var http = require('http');
http.createServer(function(request, response) {
}).listen(80);



Actual results:

url bar displays bare ip, but copied value has protocol included


Expected results:

copied value should be identical to value displayed in url bar.

Comment 1

[:Gijs (away/busy until Mar 10)]

We always prefix http back on so links actually work. I don't think we should do something different for bare IPs or "slow loading sites". Links should work. Resolving wontfix.

Comment 2

[fbrfa8.g]

That's not the point.  If the url is changed, then the value displayed in the url bar should be updated to accurately display the correct value.

In this case, the value displayed in the urlbar is not updated until the page loads, even though the "actual" value is different

Comment 3

[:Gijs (away/busy until Mar 10)]

(In reply to co463 from comment #2)
> That's not the point.  If the url is changed, then the value displayed in
> the url bar should be updated to accurately display the correct value.
> 
> In this case, the value displayed in the urlbar is not updated until the
> page loads, even though the "actual" value is different

How does what is displayed change? Both values are http://127.0.0.1/ - the whole point of trimURLs is that we don't display the http bit either way. We also normally don't revert the URL bar to the URL of the currently visible page after you input a URL to replace that page with, while waiting for the new page to load, so that can't be it either.

The only explanation I can think of is that you're actually setting the pref to false, but NOWHERE in your post is that reflected, so my assumption when you say "trim URLs is not working" is that you expect the protocol to not be there when the pref is set to true (rather than false). Please clarify.

Comment 4

[fbrfa8.g]

Sorry about the confusion.

trimurls is set to false, but the displayed value stays as 127.0.0.1 until the page loads, after which it is updated to http://127.0.0.1/ which is the proper value

The value displayed in the urlbar should be updated immediately to reflect the actual value.

Comment 5

[:Gijs (away/busy until Mar 10)]

(In reply to co463 from comment #4)
> Sorry about the confusion.
> 
> trimurls is set to false, but the displayed value stays as 127.0.0.1 until
> the page loads, after which it is updated to http://127.0.0.1/ which is the
> proper value
> 
> The value displayed in the urlbar should be updated immediately to reflect
> the actual value.

We update it based on network getting back to us, which is also approximately when whatever is currently displayed unloads. Updating it before that would require replicating whatever network is doing, with the risk that behaviour diverges when network changes. That's a bunch of extra code and risk.

On the reward side, the pref is default-off and has no UI - you have to use about:config to change it. So very few users are affected. The negative effect of the current behaviour is negligible - you're already getting the same copy-paste result as if we did display the entire URI. If you want the IP/domain without the "http" prefix, you'd be better served by a trivial add-on that gives you a button or context menu or shortcut for that.

The risk/reward balance here is not good, so I don't think we should do this. Resolving wontfix.