User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110203 Firefox/4.0b12pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110203 Firefox/4.0b12pre Currently the link target has the odd Chrome-like behavior of omitting http from the start of the URL. There are several problems with this: 1.) This is very inconsistent, especially when both ftp and https URLs display normally. Why should http get special treatment? Also, why are we assuming that users know a URL without http:// is really a http link? 2.) Eyes have to look in separate places for domain name between http and ftp/https. For http links, I have to start at the edge of the screen to find domain name. For https/ftp links, I have to start after the http://. This is bad because I now have to look in two locations depending on what the url type is. You may think this is a nitpicky thing, but it makes a big difference for me in terms of glancing speed. The link target is supposed to be something that you look at real quick. Having to scan your eyes across the URL to find the beginning of the domain name slows me down. 3.) Without the http://, the URL constantly looks cut-off for links without "www". Often times I'd mouse over a link (e.g. digg.com) and I would think that part of my Firefox window was outside my screen space and that's why the "http://www" was cut off. 4.) Having http:// present is a good reminder to the user that the link target is NOT encrypted. Without it, the user really doesn't have any idea what protocol the link is using. 5.) Removing http:// doesn't save much space and adds more code complexity. Reproducible: Always Actual Results: "http://" is removed for link targets Expected Results: Link targets display http:// in front of URL

Why was this done? Mangling URLs is not right on general principles. Restoring link hover status to the lower left should not have a confounding change like this in any case. This needs to get fixed for Firefox 4. /be

(In reply to comment #1) > Why was this done? Mangling URLs is not right on general principles. Pretty sure because Chromium does it =(

(In reply to comment #2) > Pretty sure because Chromium does it =( Alex, unless you would like your Bugzilla access revoked, learn to keep your snide comments to yourself. Bugzilla is not your message board. It is our workplace and I will not tolerate this kind of pollution. Brendan, I believe that this is the result of carrying down the changes that were made for hovered URLs in the addressbar, where it probably made more sense and not an independent decision about the design of the new pop-up.

It may have worked in the address bar (let's not debate that here) but wasn't the starting position of the hovered link a variable that depended on the link url's length, the loaded url's length, the width of the window, etc.?

(In reply to comment #3) > (In reply to comment #2) > > Pretty sure because Chromium does it =( > > Alex, unless you would like your Bugzilla access revoked, learn to keep your > snide comments to yourself. Bugzilla is not your message board. It is our > workplace and I will not tolerate this kind of pollution. Didn't mean to be snide nor pollution. I happen to have a Chromium window and the behavior was the same hence my comment.

(In reply to comment #5) > Didn't mean to be snide nor pollution. I happen to have a Chromium window and > the behavior was the same hence my comment. Alex, Your (wrong) guess about the motivations for work that you were not a part of is not a valuable contribution to Firefox or the Mozilla project. I'm not sure what it is that you're doing in Bugzilla, but you're not helping here. If you'd like me to explain to you what Bugzilla is and where you might contribute productively, please reply to my email. Brendan, yes, and I believe that this is a bug in the new feature. As such, I'm confirming it. We should get input from the UX folks or the implementers. Turning on that bat signal now with the uiwanted whiteboard status. (I think that's how it's done.)

I think this should work... Untested.

Comment on attachment 509840 [details] [diff] [review] patch - v1 uir=beltzner The goal here was to recreate what we had in the Status Bar with the Status Tooltip. While I actually disagree with many of the arguments in comment 0 (f.e., I don't for a second believe that general users discern meaningfully between http and https) I also don't think it's the time for us to be making this sort of change in our product without proper vetting, as the issue is obviously a bone of some contention. So, yes this gets a ui-r+, but no, I don't think that means we shouldn't revisit this sort of discussion or debate in the future.

(In reply to comment #8) > Comment on attachment 509840 [details] [diff] [review] > patch - v1 > > uir=beltzner > > The goal here was to recreate what we had in the Status Bar with the Status > Tooltip. > > While I actually disagree with many of the arguments in comment 0 (f.e., I > don't for a second believe that general users discern meaningfully between http > and https) If general users don't discern meaningfully between http and https then they won't care if http is there. Meanwhile advanced users will know the difference and DO care. There is no need to hurt advanced users to cater to general users who probably won't care about whether http is removed or not. My main concern is that there's a lot of other protocols that can be used. Assuming that the lack of http:// in a URL means it is using HTTP doesn't make any sense. We should not make a special case for http.

Verified using Mozilla/5.0 (Windows NT 6.1; rv:2.0b12) Gecko/20100101 Firefox/4.0b12.