1268753 - provide a way for users to show the full address in the awesomebar

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Chris Babcock]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160421124000

Steps to reproduce:

Open browser.  Go to the home page of a web site.  Note the urlbar says the domain root. Then click a link.  You will notice no change in the urlbar.  To see the path where you are, you have to click in the urlbar.


Actual results:

Urlbar truncates path after domain regardless of what page you are on.  This is beyond frustrating.  Makes FF for droid not usable, at least for me.  I can't tell where I am.  It's like trying to navigate Boston with a 36 inch globe.  Clicking in the urlbar to find out where you are is silly.


Expected results:

It should show the full path without clicking.    You MUST at least be able to change this behavior in about:config, though in my opinion it should be this way default.

Comment 1

[Chris Babcock]

This is my first bug reported to Mozilla.  I hope I have behaved according to standards and rules.  Please look at this issue.  It amazing how such a small change has such a major impact.

Comment 2

[Chris Babcock]

See also previous bugs:

https://bugzilla.mozilla.org/show_bug.cgi?id=1236431

https://bugzilla.mozilla.org/show_bug.cgi?id=1250671

Comment 3

[Kevin Brosnan [Ex-Mozilla]]

We should discuss this again before release.

Comment 6

[Sandra]

Agree, extremely frustrating and counter productive. Please fix this.

Comment 8

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Thanks for the feedback Chris!

It'd be helpful if you could help me understand your actual pain points here. For instance, why is it that you don't know what site/URL you're on? and how do you find clicking the URL bar to see a URL silly?

This will help us understand the issues we're trying to solve and provide the best option to serve our users.

Comment 9

[:Margaret Leibovic]

Tracking for 47 because we need an answer to this complaint one way or the other.

It is technically difficult to add a preference for this, and I don't think it's worth maintaining it. As Antony says, I'd like to understand what the real pain points are here. As it is, you can't see the whole URL on small screens anyway.

Barbara, I think we should WONTFIX this, but I want you to be on board with that.

Comment 10

[adria]

This was linked from 1249594 but doesn't seem to be the exact same issue.

Whatever. You hid the URL. The entire URL. If space is so limited that we are forced to choose between a PKI-me-harder indicator, or the URL, then one of them has got to go. (Hint: it's that first one).

On tablet, the browser menu is hidden automatically when scrolling though an article. That's a good use of limited screen space, but it also means that all hints about your location (including those provided by the webpage itself) go off-screen for minutes at a time. This is a burden on short-term memory, restored by flicking upwards to view the location.

Regarding concealing it behind a tap: All actions on a touch-screen, especially presses in the top/left quadrant have a much higher cost than their desktop equivalents. This is mystery-meat navigation, except hiding the current, rather than the destination location.

Comment 11

[Trel]

(In reply to Anthony Lam (:antlam) from comment #8)
> Thanks for the feedback Chris!
> 
> It'd be helpful if you could help me understand your actual pain points
> here. For instance, why is it that you don't know what site/URL you're on?
> and how do you find clicking the URL bar to see a URL silly?
> 
> This will help us understand the issues we're trying to solve and provide
> the best option to serve our users.

There's any number of things that can redirect someone to a page they're not expecting.  If you hide the url bar fully, a malicious script could make overwrite the content of the page with a message saying "please wait while your site loads" and then direct you to another site.

In the case of what it's currently doing in the beta which is to say only showing the top level domain, rather than including subdomains, it is actually misrepresenting the site you're on.

An example case would be amazon.com vs smile.amazon.com

It's one thing to hide the full path of a URL until clicked, but it's an entirely different ballgame to hide the hostname/subdomain.  Another example is the free hosting site webs.com.  Your url there is <yoursite>.webs.com

What then would I see differently in the URL between

site-I-trust.webs.com/shoppingcart/checkout  
and
maliciouscopycat.webs.com/creditcardstealer/I-copied-site-I-trusts-layout/

I'd look up and see "webs.com" and think, yep, I'm in the right place.

Truncating off as much as the beta is doing is actually hurting security, not helping.

Comment 12

[Richard Robertson]

I really dislike the change and I feel really disoriented by the lack of URL. It's confusing not to see where I am in a site and at first I thought I had been hit by some redirecting bug or ad that was returning me to the site root when I tried to load a bookmark right after the update. I've been watching this bug so I can find out when this feature is removed or at least made optional. The whole point of the beta is to user test new features right? Well here are several negative opinions as shown by this bug and duplicates.

Comment 13

[Richard Robertson]

(In reply to :Margaret Leibovic from comment #9)
> It is technically difficult to add a preference for this, and I don't think
> it's worth maintaining it.
If the URL can be shown in full on a tablet, why is it difficult to add another if case for a preference? Referring to https://bugzilla.mozilla.org/show_bug.cgi?id=1250671

Comment 14

[Chris Babcock]

(In reply to Anthony Lam (:antlam) from comment #8)
> Thanks for the feedback Chris!
> 
> It'd be helpful if you could help me understand your actual pain points
> here. For instance, why is it that you don't know what site/URL you're on?
> and how do you find clicking the URL bar to see a URL silly?
> 
> This will help us understand the issues we're trying to solve and provide
> the best option to serve our users.

OK. The awesomebar only shows the domain.  This means I dont know what page I'm in under that domain.  I 'm struggling to explain differently I guess. Let's try this:

Right now I'm on the page and my desktop version of Firefox show me the entire URL in the URL bar:

https://bugzilla.mozilla.org/show_bug.cgi

But in the Firefox for Android beta version the I would only see this in the URL(aka awesomebar):

https://bugzilla.mozilla.org/

This does not tell me what page I'm on.  I cant even begin to explain how useless it makes the browser at least for me.  I will have to switch to something else if this change is permanent.  I understand the intention, and applaud you for trying, but it's not the right way to go about it. In fact, one could argue, that not knowing if you have been redirected could be a security risk.

Comment 15

[Chris Babcock]

(In reply to :Margaret Leibovic from comment #9)
> Tracking for 47 because we need an answer to this complaint one way or the
> other.
> 
> It is technically difficult to add a preference for this, and I don't think
> it's worth maintaining it. As Antony says, I'd like to understand what the
> real pain points are here. As it is, you can't see the whole URL on small
> screens anyway.
> 
> Barbara, I think we should WONTFIX this, but I want you to be on board with
> that.

Hi Margaret,

I'm not sure what kind of phone you use, but I can often see the entire URL on my S4,S5,S6 Active.  Even if I cant see the whole thing, I can almost see enough to glean where I am.  Obviously, if what you are saying is true I would not have created the bug report because there would be nothing to report. So please fix, you are taking away function from donating users who care enough to use the beta channel and spend the time to post here.  Thanks.

Chris

Comment 16

[Sandra]

Similarly to what Trel above explained, please see the following two examples. The first is a subdomain/account I own with smugmug.com. If I link someone to the main page, the link is fatgraftpatients.smugmug.com. It shows properly on my Samsung Note 5, FF 46.0.1, but only shows smugmug.com on FF Beta. Second example is an item I am viewing on smile.amazon.com (subdomain "smile" is how you contribute a percentage of your purchase amount to your participating charity). FF 46.0.1 shows full URL properly, and FF Beta does not show subdomain, nor item number.

46.0.1
http://i.imgur.com/KJfNDxK.png
http://i.imgur.com/gGxtaXp.png

Beta
http://i.imgur.com/HDIBr4v.png
http://i.imgur.com/ZG2sxr6.png

Comment 18

[Sandra]

There seem to now be more than enough examples of why this change is unacceptable. Are there any updates on when it will be corrected?

Comment 19

[:Margaret Leibovic]

As an update to those following along, we've decided to put this behind a switchboard flag to prevent it from riding to release as we address feedback:
https://bugzilla.mozilla.org/show_bug.cgi?id=1271698

This is a valuable security change, so we don't want to give up on this feature, but we realize there improvements that could be made before we ship this.

Thank you beta users for your feedback. One of the main reasons we have a beta channel is for gathering feedback like this before we release features.

Comment 20

[Richard Robertson]

Why can't it just be left up to the user? Pick a default and let us pick the actual setting. And worse still, most of the Android UI is in Java instead of XUL so even an addon won't fix this for us.

Comment 21

[Trel]

(In reply to :Margaret Leibovic from comment #19)
> This is a valuable security change, so we don't want to give up on this
> feature, but we realize there improvements that could be made before we ship
> this.

Have we been reading the same bug?  There's more than enough evidence that this is a security RISK, not an improvement.  What you just said is akin to driving with a blindfold on and saying that it's a "valuable vision change".

Security isn't increased with this change, it's crippled.  It obscures without manual interaction the location a user is actually visiting.  It completely disregards that specific subdomains are important, and that the actual path is important.

It makes no distinction in either of the two cases below

safesite.hosting.com
and
dangeroussite.hosting.com


downloadsite.com/path/to/download/safe/file/download.html
and
downloadsite.com/path/to/download/malicious/file/download.html


To use my car analogy from earlier, it's akin to solving people using their cell phones while driving by blindfolding them.  It helps in a single case, but makes the overall experience much worse and much more dangerous.

Comment 22

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to Trel from comment #21)
> It makes no distinction in either of the two cases below
> 
> safesite.hosting.com
> and
> dangeroussite.hosting.com

This is not entirely true. We are using the public suffix list[1] to determine which part of the domain we are showing. If hosting.com is a domain under which users can register subdomains and it's registered in the public suffix list then we show the subdomain too.

For example we do show:
* somesite.blogspot.com (and not blogspot.com)
* somesite.github.io (and not github.io)
[..]

[1] https://publicsuffix.org/learn/

> downloadsite.com/path/to/download/safe/file/download.html
> and
> downloadsite.com/path/to/download/malicious/file/download.html

I understand your concern but I feel like this example is too constrcuted. Even with the release version of Firefox, which does not include those changes here, you do not see the important parts of your example. Right now the URL is already truncated. And it's pretty random what part you see.

Comment 23

[Trel]

Ok, here's a less constructed example

Page contents
"Thank you for selecting our software, your download will begin shortly.  Click 'here' if your download doesn't begin."

softwaresite.com/download/release
and
softwaresite.com/download/pre-alpha

I'm thinking of these all as I go along.  If I can think of these so fast off the top of my head, then there's obviously even more I'm NOT thinking of.


As far as the public suffix list, I'd prefer not to have to depend on someone ELSE being proactive for my security.

Comment 24

[Sandra]

(In reply to Sebastian Kaspari (:sebastian) from comment #22)
> (In reply to Trel from comment #21)
> > It makes no distinction in either of the two cases below
> > 
> > safesite.hosting.com
> > and
> > dangeroussite.hosting.com
> 
> This is not entirely true. We are using the public suffix list[1] to
> determine which part of the domain we are showing. If hosting.com is a
> domain under which users can register subdomains and it's registered in the
> public suffix list then we show the subdomain too.
> 
> For example we do show:
> * somesite.blogspot.com (and not blogspot.com)
> * somesite.github.io (and not github.io)
> [..]
> 
> [1] https://publicsuffix.org/learn/
> 
> > downloadsite.com/path/to/download/safe/file/download.html
> > and
> > downloadsite.com/path/to/download/malicious/file/download.html
> 
> I understand your concern but I feel like this example is too constrcuted.
> Even with the release version of Firefox, which does not include those
> changes here, you do not see the important parts of your example. Right now
> the URL is already truncated. And it's pretty random what part you see.

Did you disregard my screenshots above???

smile.amazon.com shows as amazon.com
fatgraftpatients.smugmug.com shows as smugmug.com

And everything after .com does NOT show

Again, this is unacceptable in a browser.

Comment 25

[:Margaret Leibovic]

Sebastian, you're on the hook to figure out a path forward here. I think we should probably just disable this feature until someone has time to revisit it.

Comment 26

[Sebastian Kaspari (:sebastian; :pocmo)]

Attachment: GitHub: Disable URL bar changes on all channels.

This patch disables the recent URL bar changes (short URL and EV certificate owner) on all channels (Switchboard experiment). Bug 1271998 tracks an alternative solution, but currently we do not have the time to explore this further. Therefore we decided to disable the experiments for now.


Approval Request Comment
[Feature/regressing bug #]: Bug 1236431 (Short URL), Bug 1249594 (Short certificate owner)
[User impact if declined]: This experiment is currently held on Nightly, Aurora, Beta.
[Describe test coverage new/current, TreeHerder]: Local testing. Switchboard flags introduced in bug 1271698.
[Risks and why]: Low. This restores the previous behavior which was still partially the default behavior on tablets (bug 1250671)
[String/UUID change made/needed]: -

Comment 27

[Chris Babcock]

Thank you for listening.

I just want to say again that I appreciate that Mozilla took a stab at improving security, even it didn't quite work out as intended.

Comment 28

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8755364 [details] [review]
GitHub: Disable URL bar changes on all channels.

Disabling awesome bar changes, Aurora48+, Beta47+

Comment 29

[Sorina Florean [:sflorean]]

Verified as fixed in build:
- Aurora 48.0a2 (2016-05-26);
- Nightly 49.0a1 (2016-05-26);
Device: Nexus 5 (Android 6.0.1) and LG G4 (Android 5.1).

Comment 30

[Barbara Bermes [:barbara] - NI please!]

(In reply to :Margaret Leibovic from comment #9)
> Tracking for 47 because we need an answer to this complaint one way or the
> other.
> 
> It is technically difficult to add a preference for this, and I don't think
> it's worth maintaining it. As Antony says, I'd like to understand what the
> real pain points are here. As it is, you can't see the whole URL on small
> screens anyway.
> 
> Barbara, I think we should WONTFIX this, but I want you to be on board with
> that.

Sorry for the delay but as discussed outside Bugzilla, yes let's park this for now.

Comment 31

[Sorina Florean [:sflorean]]

Verified as fixed in build 47 Beta 10.
Device: Nexus 5 (Android 6.0.1) and Samsung Galaxy R (Android 2.3.4).