1284046 - Firefox Android show incorrect partial URL on HTTP

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect, P5)

Description

[brice.marc]

Attachment: Firefox Android show incorrect URL by removing subdomain (different from www)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.60 Safari/537.36
Firefox for Android

Steps to reproduce:

With Firefox Android, go to a website with a subdomain with HTTP.

ie http://mobile.free.fr/assistance/

After loading, Firefox show free.fr/assistance/ as URL ! Subdomain is not www but subdomain is ignored.

Now change protocol, set HTTPS :

ie https://mobile.free.fr/assistance/

Now Firefox Android show full URL


Actual results:

Firefox AndroID show incorrect URL with HTTP; firefox remove the subdomain, subdomain is not www so Firefox must mention the subdomain.


Expected results:

Firefox must show the exact URL and the subdomain because subdomain is not www.

Comment 1

[Théo Chevalier]

Confirming, I can reproduce with latest Nightly build.

That might be related to "mobile" sub-domains, since http://portail.free.fr is displayed correctly.

Comment 2

[Théo Chevalier]

Same happen with http://mobile.lamonde.fr.

Nick, maybe you know the reason? My guess is that we’re hiding "mobile" sub-domains because they are generally the mobile version of the desktop web site. However, in the case of mobile.free.fr it’s a website dedicated to mobile activities of a French ISP, not a mobile version of free.fr.
I suppose those cases have been considered as edge cases?

Comment 3

[Théo Chevalier]

(In reply to Théo Chevalier [:tchevalier] from comment #2)
> Same happen with http://mobile.lamonde.fr.

 Grr, typo. http://mobile.lemonde.fr

Comment 4

[Nick Alexander :nalexander [he/him]]

(In reply to Théo Chevalier [:tchevalier] from comment #2)
> Same happen with http://mobile.lamonde.fr.
> 
> Nick, maybe you know the reason? My guess is that we’re hiding "mobile"
> sub-domains because they are generally the mobile version of the desktop web
> site. However, in the case of mobile.free.fr it’s a website dedicated to
> mobile activities of a French ISP, not a mobile version of free.fr.
> I suppose those cases have been considered as edge cases?

I don't really know anything about this, but it seems related to Bug 1236431.  Sebastian addressed that ticket, so I'll route the NI to him.  Thanks, tchevalier!

Comment 5

[Sebastian Kaspari (:sebastian; :pocmo)]

You are guessing right. We are stripping some common subdomains (www, mobile, m); but only from http URLs. You can prevent this globally by flipping the "browser.urlbar.trimURLs" pref in about:config.

I don't know the history of that feature (I followed it back to at least Firefox 29 but it seems to be even older) but I guess it's just to make the "important" part of the domain more visible. We can't really do that for https for security reasons. See bug 1271998 and the linked bugs for more about that and related discussions.

This is now a special case where we might not want to strip the subdomain. I don't think it makes sense to handle those special cases so we should either ignore the special case (use the config flag if you are unhappy about that) or do not strip at all (maybe just do not strip 'mobile' and keep stripping of 'm' and 'www'?). I flag Anthony (UX) and Barbara (Product) to decide.

Related code:
* https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/toolbar/ToolbarDisplayLayout.java?q=path%3AToolbarDisplayLayout&redirect_type=single#277-279
* https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/util/StringUtils.java#123-141

Comment 6

[brice.marc]

Stripping mobile subdomain is predisposing that's the subdomain is a mobile version of the website, but that's an incorrect decision. 

In the example I mention that is not the case. I think there is no RFC mentionning that we must not host other content than a mobile version of a website on the "mobile" subdomain.

Comment 7

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

(In reply to Sebastian Kaspari (:sebastian) from comment #5)

> I don't know the history of that feature (I followed it back to at least
> Firefox 29 but it seems to be even older) but I guess it's just to make the
> "important" part of the domain more visible. We can't really do that for
> https for security reasons. See bug 1271998 and the linked bugs for more
> about that and related discussions.
> 
> This is now a special case where we might not want to strip the subdomain. I
> don't think it makes sense to handle those special cases so we should either
> ignore the special case (use the config flag if you are unhappy about that)
> or do not strip at all (maybe just do not strip 'mobile' and keep stripping
> of 'm' and 'www'?). I flag Anthony (UX) and Barbara (Product) to decide.
> 

I've noticed over the last few months that preserving the URL (https://bugzilla.mozilla.org/show_bug.cgi?id=1236431) is very important to users. 
The URL is the most powerful thing about the web and the main entry point. So if our recent changes seems to be causing issues for our users, we need to re-think and address this. 

Anthony, can we revisit Sebastian's proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1271998?


Thanks

Comment 8

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

(In reply to Barbara Bermes [:barbara] from comment #7)
> Anthony, can we revisit Sebastian's proposal:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1271998?

Sure!

Comment 10

[Jan Henning [:JanH]]

Bug 1271998 has been implemented now and this particular issue has been brought up recently in bug 1404815, so maybe we want to revisit this again?

Comment 11

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

Leaving this to product to prioritize given the Yall Hands presentation about the 2018 focus areas. :)

Comment 13

[moz-nuc]

Regardless of what happens with this bug, can someone update the docs at https://developer.mozilla.org/en-US/docs/Mozilla/Preferences/Preference_reference/browser.urlbar.trimURLs to reflect the full trimming behaviour?

About this issue:

I'm guessing this is was implemented in legitimate pursuit of space saving on mobile.

However, fundamentally, the problem with the stripping of specific prefixes is it is misinforming the user - m.example.com and www.example.com are *not* example.com.

To reconcile these two conflicting problems, a straightforward solution would be to just display a (tappable) ellipsis if the subdomain has been hidden:

[…]example.com/path

The […] could be styled as a button, and could take the place of the globe icon on HTTP pages.

Then, a tap of the ellipsis button would un-hide the subdomain and show the standard globe icon. Tapping on the globe icon would then lead to the page info pop-over as usual:

[…]example.com/path

-> User taps […]:

[

Comment 14

[moz-nuc]

OK, Bugzilla mangles comments if an extended UTF-8 char is used apparently :J

Following on from above:

[…]example.com/path

-> User taps […]:

[globe icon]m.example.com/path

-> User taps [globe icon]:

┌───────────────────┐
│m.example.com      │
│Insecure connection│
│Edit Site Settings │
└───────────────────┘

This solution visually differentiates between subdomain-trimmed and complete domains.

Comment 15

[Jan Henning [:JanH]]

Before thinking up anything too complicated, we shouldn't forget that the URL is now scrollable and the base domain is initially aligned with the right edge of the URL bar, so long subdomains can no longer push the base domain off the screen (they might still impact the path part, though). Therefore I'd say that the need for trimming should already be greatly reduced.

Comment 16

[moz-nuc]

True, in which case FF Android is actually showing *incorrect* information in preference to having a few extra path characters scrolled off the right edge.

Even worse, it does this *even if* there is enough space in the URL bar for the *entire* URL including the subdomain.

Given all this, it seems that the special-cased hiding of subdomains (m., www., mobile., others?) should be dropped entirely.

Comment 17

[Jan Henning [:JanH]]

I'd tend to agree, which is why I brought this up again after the scrollable URL bar was implemented (which was comparatively recently, though), but I'm not the one to make the final decision here.

Comment 18

[Firefox Bug Husbandry Bot]

Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.

Comment 19

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.