Closed Bug 689342 Opened 13 years ago Closed 13 years ago

http:// is prepended to copied/pasted strings

Categories

(Firefox :: Address Bar, defect)

Product:
Firefox
Component:
Address Bar
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: r_rom, Unassigned)

References

Details

http://somesite.com/somepage.html Sometimes I need to copy a domain name (somesite.com) and paste it somewhere. I used to be able to do that easily, but now http:// gets prepended, which causes me to do extra work (delete the characters I don't need) that didn't used to be necessary. This inconvenience has been caused by your trying to save the space in the location bar by hiding the protocol ID. The new feature isn't useful but causes problems.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Unfortunately this use case is uncommon, and conflicts with the more common use case of wanting to copy the entire URL in a universally recognized form (i.e. with the protocol included). There is a pref to disable the protocol-trimming behavior: browser.urlbar.trimURLs.
Resolution: DUPLICATE → WONTFIX
(In reply to Gavin Sharp (use gavin@gavinsharp.com for email) from comment #2) > Unfortunately this use case is uncommon, and conflicts with the more common > use case of wanting to copy the entire URL in a universally recognized form > (i.e. with the protocol included). They don't necessarily conflict... If we wanted, we could easily stop prefixing http:// in case case a sub string of the URL is selected, but no part of the path. This would however be inconsistent with selecting the whole URL when there is no path.
(In reply to Dão Gottwald [:dao] from comment #5) > They don't necessarily conflict... If we wanted, we could easily stop > prefixing http:// in case case a sub string of the URL is selected, but no > part of the path. True. I'm not sure that "path isn't selected" is a useful enough heuristic for "want to avoid the scheme addition", though - it seems just as likely that people making partial selections want the scheme in all cases. I suspect the general cases here are covered well enough by our current behavior, and anything more complicated probably isn't worth it.
The only reason this is complicated in the first place is because the developers chose to hide the http:// part. Hiding it has not made it any simpler as you still show https:// as well. With any website that requires a login now going to https://, people are still going to see it and be confused and wonder why some websites show it and some don't. I'm just glad they enabled a way to still show it as it would drive me crazy everytime I tried to copy just the hostname and having http:// prepended in front of it.
> Unfortunately this use case is uncommon, and conflicts with the more common > use case of wanting to copy the entire URL in a universally recognized form > (i.e. with the protocol included). Are there any actual metrics that show that this use case is less common? I.e. if the url is "http://subdomain.domain.com" and the user selects "subdomain", how often does he need to have "http://" prepended to it? I dare to say, almost never. At least in my experience. This "feature" of Firefox is horribly unintuitive and should have never been implemented in the first place. Or at least shouldn't be the default option.
(In reply to Timofei Shatrov from comment #8) > I.e. if the url is "http://subdomain.domain.com" and the user selects > "subdomain", how often does he need to have "http://" prepended to it? I > dare to say, almost never. At least in my experience. Sure, but that's an edge case. The really interesting question is what should happen when "subdomain.domain.com" is selected.
What's a truly interesting question is who really needed this feature. Have many users complained about seeing http://? I doubt it. They have complained and still do is about poor memory management, slow shutting down, frequent unresponsiveness of Firefox, etc.
Software that wants to be successful and innovative needs to base its UI decisions on more than just "user complaints". We rely on guidance from user interface design experts, experience, and judgement to make UI changes. Obviously this doesn't always satisfy everyone - changes have costs, and for some users the costs of any change at all may outweigh the benefits of the change. Evaluating that tradeoff is difficult, and even if we do a perfect job of that (we try to, but we don't), not everyone will be satisfied. It's impossible to achieve 100% satisfaction when your userbase is 450 million people.
100% were satisfied with the "http://" being there in the address bar. Less than 100% are satisfied with it not being there (because, as explained, it makes copy-pasting parts of URL extremely annoying). There is no tradeoff. It's a regression, plain and simple.
What this has done now is make copying and pasting a url be an unknown. What I highlight will not always be what is copied to the clipboard. If your website is on https://, then what happens is when you try to copy and paste the hostname in the url, it copies exactly what you have highlighted. When your website is on http://, then copying the hostname in the url doesn't copy what you have highlighted. Instead it has copied the hostname with http:// appended in front of it. The user seeing this becomes confused. They wonder why it is different between when https:// is there and when http:// is used because they're not aware that http:// is being hidden on them. So what you've now done is make the user experience in-consistent. This will lead to only confusion. I don't use chrome because of this. Do you really want users to have to remember this rule? I don't. I want it to be consistent no matter if I'm on http:// or https://.
I also suspect some users when copying and pasting a url, will see http:// before the hostname will then remove it because their browser doesn't show it. Programs who automatically parse text to create links will then not turn that url into a link because the http:// is not there. This will teach them that ordinary websites don't need http:// anymore. But for websites that require https://, they won't remove that because that is what their browser shows, so they will keep it when copying and pasting the url.
I understand that some people (like you) favor consistency very highly (I generally do too, though in this case I know what to expect because I implemented parts of the behavior). That needs to be traded off against the people who favor the simpler-to-understand URL that is produced when you strip away parts that aren't necessary for comprehension. Those people aren't as vocal (they generally don't have any clue what Bugzilla is!) and often don't even know that they want such a change (but appreciate it after the fact). If we value those people as users (we do), we need to be advocates for them in the face of the feedback from the (much more vocal) set of users that complain to us on Bugzilla.
Good point, Carl. Which reminds me of another problem with this approach. Since http protocol has proven to be insecure against man in the middle attacks (i.e. Firesheep), more and more sites are implementing HTTPS protocol. In this paradigm, the fact that a site is using plain old insecure HTTP protocol has to be highlighted, not hidden away. Mozilla assumes that HTTP is the default. However for sites with authentication, HTTPS increasingly becomes the default. Therefore any positive effects of removing http:// may be (I've yet to see a single one), they wouldn't affect a user who only visits secure sites.
(In reply to Gavin Sharp (use gavin@gavinsharp.com for email) from comment #15) > I understand that some people (like you) favor consistency very highly (I > generally do too, though in this case I know what to expect because I > implemented parts of the behavior). Then revert the default behavior to the previous one and add an option to turn on the new behavior for yourself and 3 or 4 other people who want it. The rest of the users will not appreciate this change, and some will be confused. This software will be successful if it stops freezing often and uses less RAM. Hiding http:// isn't something that will make Firefox more appealing to current or future users. This is somebody's pet project that is interesting to only a handful of users who want a change just for the sake of a change, not because the change is beneficial. Thus it needs to be off by default and made available to those handful of people. If you want to be an advocate for users, then do what's important to them, and this feature isn't one. I am going in a circle, so I will stop.
I don't know what good Mozilla is try to achieve by dropping http:// from the URL. First of all, the URL looks so silly without http in front of it. It's like I am roaming on roads with my head hidden under my shirt :-) (and something special needs to be done to pop it out, browser.urlbar.trimURLs) Just a seven characters is not going to take too much space at all, given the fact that now-a-days most of the screens are widescreen. The hiding could be default to smartphones, tables etc. where the horizontal space is premium. But come one why o why for desktop browser? These little, but drastic changes, are making the use of browser very difficult for old users as we are accustomed to one thing, and with a new update, suddenly, it's all different. It's like throwing me suddenly into the ocean while I was taking the pretty nice sandbath. And yes, I have been listening to the same "user experience" story for any issue related to the user interface. For example, I asked why did you move the very very old, View->Source to a different place? The answer was users wanted it. So who am I then who is using Mozilla right from Netscape 5? I asked why did you move "Show All Bookmarks" as the first item in the bookmarks menu? The answer was users wanted it. So now I have to unlearn my shortcut of Alt+B+Enter to create a bookmarks. The gentlemen of Bugzilla are suggesting that why don't you use Ctrl+D etc. etc. but that doesn't solve the purpose. When introducing new features, we should not be removing the old menu items, shortcuts, http:// etc. etc. which have been there from long long time. I became very emotional while typing this, so please forgive me if I have used any harsh words. Regards, Satish.
Well, yes, 692733 is a duplicate of this one. But this one is a "wontfix", so by making it a duplicate, you are just discarding it. Please reopen the bug. I was proposing that the http:// is included in the paste buffer only if the URL is included at least up to the first '/' or the end of line. I really doesn't make sense to add the protocol if you haven't included the full host name and the optinal port. But yes, my preference goes to always showing the "http://" prefix. In Gavin's word, the general case was covered well enough by that behaviour, and anything more complicated probably isn't worth it. The moment you realized that removing the http:// prefix causes a major issue when copying the URL, you should have stopped and wondered whether the extra complication is worth it. What is next? Display the hostname only in the rare occasions where it is not "facebook.com"?
Here's the main reasons for not hiding it, which is why I always show http:// 1. Copy and paste is consistent 2. If I copy just the hostname, then I get just the hostname 3. If I copy the http://hostname then I get http://hostname if another program requires that for it to be automatically turned into a link Now with hiding it, you have all these crazy scenarios: 1. What if I want to copy just the hostname? 2. What if I want to copy the hostname with the protocol? Can you distinguish these 2 cases with hiding it? No you can't, hence this only confuses users. You can't deny that. I think the way apple did it where they only hide http:// when you are viewing the url but they do show it when you try to highlight it or edit it is a good compromise. But me of course I'd rather see it regardless. Unless you've got another part of the gui that shows me what the protocol is so I can clearly see which one is in use, I don't want this. This was clearly only thought half-way through and because chrome did it, otherwise these issues would have come up.
I will take advantage of my ownership of this issue and reopen it with the hope that the devs have had enough time to be able to revisit this and take a fresh look at this, hopefully having let go of their emotional attachment to this, which they've spent a lot of time on. It's OK to keep this feature, but it should be off by default.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
(In reply to Roman R. from comment #23) > It's OK to keep this feature, but it should be off by default. If that's what this bug is about, it's not going to happen. I thought it was really about the "copying only the domain" case (e.g. bug 692733).
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → WONTFIX
(In reply to Dão Gottwald [:dao] from comment #24) > (In reply to Roman R. from comment #23) > > It's OK to keep this feature, but it should be off by default. > > If that's what this bug is about, it's not going to happen. Why? Because you're too proud to admit that it was a mistake? I don't know anybody who actually *likes* this feature. It's just a nuisance that adds absolutely nothing to the table. The reasons are outlined in the comments of this bug and Firefox developers are yet to address any of them. Firefox users don't want any dumb UI decision that Chrome developers come up with backported into their browser. Firefox users want a browser that *works*. This feature doesn't work. It's a failure. Which means it should be canned.
I think this feature, as of now, is just useless. If this feature has to be kept, I guess it must be turned off by default. It is just adding confusion and lot of bugs in Bugzilla.
(Don't forget to vote for the bug.) When I go to google and press "test", the Location Bar shows something like http://www.google.com/search?hl=en&q=+#sclient=psy-ab&hl=en&source=hp&q=test&pbx=1&oq=+test&aq=f&aqi=&aql=&gs_sm=e&gs_upl=3364l3601l1l3867l4l2l0l0l0l0l0l0ll0l0&bav=on.2,or.r_gc.r_pw.,cf.osb&fp=28e15923f347c457&biw=1377&bih=696 And you are telling me that the "http://" part is what confuses people?
(In reply to Florian Fischer from comment #27) > (Don't forget to vote for the bug.) > > When I go to google and press "test", the Location Bar shows something like > > http://www.google.com/search?hl=en&q=+#sclient=psy- > ab&hl=en&source=hp&q=test&pbx=1&oq=+test&aq=f&aqi=&aql=&gs_sm=e&gs_upl=3364l3 > 601l1l3867l4l2l0l0l0l0l0l0ll0l0&bav=on.2,or.r_gc.r_pw.,cf. > osb&fp=28e15923f347c457&biw=1377&bih=696 > > And you are telling me that the "http://" part is what confuses people? If this was regarding my comment... then... I was just telling the other way. What I said was, taking out http:// is confusing and it must not be taken out. If this really needs to be taken out "as an enhanced feature", the feature must not be "on" by default. We should be showing http:// by default, and let users decide if they want to hide it. As you see my comments, I want "http://" to be there with the URL. I don't know what Mozilla is trying to achieve by saving 5 characters of real estate in the awesome bar.
(In reply to Satish from comment #28) > (In reply to Florian Fischer from comment #27) > > (Don't forget to vote for the bug.) > > > > When I go to google and press "test", the Location Bar shows something like > > > > http://www.google.com/search?hl=en&q=+#sclient=psy- > > ab&hl=en&source=hp&q=test&pbx=1&oq=+test&aq=f&aqi=&aql=&gs_sm=e&gs_upl=3364l3 > > 601l1l3867l4l2l0l0l0l0l0l0ll0l0&bav=on.2,or.r_gc.r_pw.,cf. > > osb&fp=28e15923f347c457&biw=1377&bih=696 > > > > And you are telling me that the "http://" part is what confuses people? > > If this was regarding my comment... then... > > I was just telling the other way. What I said was, taking out http:// is > confusing and it must not be taken out. If this really needs to be taken out > "as an enhanced feature", the feature must not be "on" by default. We should > be showing http:// by default, and let users decide if they want to hide it. > As you see my comments, I want "http://" to be there with the URL. I don't > know what Mozilla is trying to achieve by saving 5 characters of real estate > in the awesome bar. I mean 7 characters... poor at counting :-)
(In reply to Timofei Shatrov from comment #8) > I.e. if the url is "http://subdomain.domain.com" and the user selects > "subdomain", how often does he need to have "http://" prepended to it? I > dare to say, almost never. At least in my experience. FYI: I submitted a bug specifically for this: Bug 707567
When you need hacks one after another to make the situation less worse, none of which can completely fix it, it's usually a sign that the first step was a bad one. And this bug is a good example: you first hide http://, and then you need to prepend it in copying, but then you need to exclude it sometimes, but then what if you need it included, or what if you don't need it, etc. By hiding http:// and trying to include it *sometimes* in copying, you break the consistency and it matters a lot. Consistency is not just a fancy concept that's nice to have but that can be also dispensed with; users base on it what to expect when they use features, and also what to try when they need something. When you do something to get A, based on your past experience, but you get A' in fact, that's a bad user experience resulting from inconsistency. "What gets highlighted gets copied" -- that's a big consistency rule that users depend on, not just in Mozilla, but across different applications and even across different operating systems. Some say that the URL looks "simpler" and that many users don't care anyway. Then why not leave just the host+domain part ("www.mozilla.org") and remove everything else? "Who cares" about the complex character soup that follows the domain? For those users, the proper "improvement" would be to hide everything but host+domain, and hiding just http:// doesn't help much. But for other users who care about URLs, hiding http:// can be the source of great nuisances. I wish to believe that this kind of change is backed up by a solid study of user experience, but I don't see any compelling argument anywhere anyway, and I'm led to suspect that some people in the development just thought this would be "cool" to try, as if on a toy project, when they shouldn't have on a product with a userbase of hundreds of millions of people. And many people keep complaining, only to get WONTFIX. I'm sad to experience similar things happen in many cases in Bugzilla.
As specified in the following URL specification documents, the "scheme" is part of the URL. Hiding the "scheme" in the address bar does not serve any purpose at all. In future if the URL spec changes and makes the scheme "optional", we can drop it altogether. Till then we need to have the good old "scheme". http:// etc. http://www.w3.org/Addressing/URL/url-spec.txt http://www.ietf.org/rfc/rfc1738.txt I don't even know if any one is really caring about the user complaints. I am forced to believe that with the frantic release schedule, Mozilla team is forced to show new stuff in each release, which in fact is ending up with these annoying type of annoying UI changes. And be hold, in the coming versions of Firefox, the "forward" button is "hidden" by default and appears only when there is a "forward" page to go. I could able to see my awesome bar move left/right so many times :-) Such an annoying feature and I don't know who is approving all these UI changes. Regards, Satish.
The only major thing that Firefox needs now is better memory management. This bug is a sign that the devs have gone bad.
I forgot about that bug. In the meantime I realized what is the correct behaviour for this case. Hide the http:// if you like, hide also the URL parameters (after the ?) if you think they are ugly. But when the focus is on the address bar, show the full address. Just hoping to inspire someone.
You need to log in before you can comment on or make changes to this bug.