228612 - Abbreviate (shorten) long username/passwords in URL bar

Status: VERIFIED DUPLICATE of bug 157354

(SeaMonkey :: Location Bar, enhancement)

Description

[Damian Yerrick]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208

I've observed in bug 184074 that the common objection to emphasizing the
host name is that the user/pass could be long enough to push the host name
completely out of the URL bar, negating any effect, and the objection to
hiding it entirely (bug 122445) is that it breaks FTP links in e-mails
sent by web host.  To solve this, show only the first 16 characters of the
user/pass in the URL bar until the user focuses it.

For example:
http://[e-mail]/
would expand to
http://[e-mail]/
on focus.

Reproducible: Always

Steps to Reproduce:
1. Resize the browser to a narrow width.
2. Visit the URL.
Actual Results:  
User name pushes host name off the right side of the visible URL bar.

Expected Results:  
User name is shortened, and host name becomes visible in URL bar,
emphasized if bug 184074 is implemented.

Comment 1

[Damian Yerrick]

Oh, and it's not OS-specific either.

Comment 2

[Peter Kroll]

Actually this is a good idea, I would suggest instead of 16 characters, we would
shorten after 8 or 10.

www.bank.ca
is 11 characters.

16 characters would not protect against www.paypal.com from showing up in the
url bar.

I know the goal of this bug is to avoid the hostname from being pushed. but it
would help with the spoofing bug#122445

Comment 3

[Mikko Rantalainen]

I don't like the idea of URL bar changing when I focus it. If I wasn't aware of
this bug, I'd guess that some javascript hack was used to change the URL bar
before I entered it (that shouldn't be possible, but bugs and exploits do exist)
and I wouldn't trust the content I see.

I think that the best way is to drop user and password from URL bar. The
resulting addresses are still valid, the user only needs to re-enter username
and password to access the content. If the user isn't aware that some username
and password is required, then it's better not to directly access the resource
via URL bar, IMO.

Perhaps add a new menu item to URL bar context menu labeled "Copy link location
including username and password" or some shorter variant of that.

Comment 4

[Ben Bucksch (:BenB)]

Discussed in bug 122445 (which is *not* about hiding the username/pw). Dup?

Comment 5

[Damian Yerrick]

I see it more as a genus/species than as a duplicate.  Now that I've read a
bit more, I see bug 122445 as a meta-bug that states a general problem, and
bug 184074 and this bug as possible solutions to the problem.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> breaks FTP links in e-mails sent by web host

Details, please?

Comment 7

[Damian Yerrick]

User signs up for web hosting.  Provider sends an e-mail:

    From: web hosting provider
    To: customer
    Subject: yourhostedsite.tld is now active

    You can configure your site here:
    https://user:[e-mail]/admin/
    You can upload web pages here:
    ftp://user:[e-mail]/
    .

Comment 8

[Boris Zbarsky [:bzbarsky]]

So? What exactly is broken there by us not showing the username/password to the
user in the url bar or status bar, as long as we still send it?

Comment 9

[Damian Yerrick]

Unconditionally hiding the user/pass may break copying the URL out of the
URL bar.  That's why I suggested showing it again on focus.

Comment 10

[Boris Zbarsky [:bzbarsky]]

We actually have bug reports that request not showing it in the URL bar at all,
no matter what, since it gets stored in session history and url bar history,
letting people just walk up and pretend to be you....

Comment 11

[Peter Kroll]

As far as I know the only thing broken by not showing the username and password
is the copying and pasting of urls with that information.

We can have an about:config variable which lets advanced users see the username
and password so they can have the copy/paste functionality.

That way no website is broken and no functionality is lost.

Comment 12

[Peter Kroll]

Attachment: removes display of username and password for http and https

Comment 13

[Boris Zbarsky [:bzbarsky]]

Darin, what was that other bug?  We really need to focus effort on this issue...

Comment 14

[Robert Parenton]

Boris, I think the bug you are refering to is Bug 232567.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Yeah, that's it.

Comment 16

[Daniel Veditz [:dveditz]]

Comment on attachment 143514 [details] [diff] [review]
removes display of username and password for http and https

r- for same reasons given in bug 122445 and bug 157354 where this same patch is
found.

Comment 17

[Daniel Veditz [:dveditz]]

I don't think very many people like the "magic changing urlbar" aspect of the
original request, so this has turned into a duplicate of bug 157354

*** This bug has been marked as a duplicate of 157354 ***

Comment 18

[benc]

V dupe.
The original bug morphed, so this duplicate fits the currently targeted problem.