1268741 - Hot new favicon placeholder letter can be more representative of a site

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect)

Description

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: Screenshot of the issue

On my device, I have pages like, "search.yahoo.com" that have "s" as their favicon placeholder letter, rather than "y", as I'd expect.

Sebastian, I think you were involved previously when we did some magic to get the expected website name from the url (i.e. we can't take the part of the host prior to the the TLD because of multi-TLD's like .co.uk). Do you remember? [1]

Credit to liuche for showing me the issue.

[1]: Sounds like it'd be a great utility function! ;)

Comment 1

[Sebastian Kaspari (:sebastian; :pocmo)]

There are multiple things here:

1) The fallback is triggered way to often. I'm currently debugging various reasons why we do not show the actual favicon. In the screenshot there should be just a Yahoo icon (If this isn't "remote history" here).

2) I don't think "s" for search.yahoo.com is necessarily wrong. I can see that "Y" might make more sense but this seems to be harder than just using the first character of "public suffix + 1" (What we do in the URL bar):

- URLs with sub domains that offer different content/services: maps.google.com, plus.google.com, mail.google.com - Do we want to use the prefix of the service (M, P, M) or really just G? Same situation for bugzilla.mozilla.org (B vs. M)

- URLs where the subdomain is actually representative: mykzilla.blogspot.com (M vs. B), cookupastory.wordpress.com (C vs. W), espn.go.com (E vs. G)

3) For the URL bar we use the "base domain" (public suffix + 1) provided by Gecko. As part of the realted bug I explored options to bring this functionality to Java (Ported from Guava): It's a bunch of code to get all the lists and parse them efficiently. We could try to hook into Gecko but I'd prefer this helper to not require Gecko. And before we do that we have to see if this actually improves the situation (I think for some domains the result could be worse).

Comment 2

[Richard Newman [:rnewman]]

https://github.com/mozilla/firefox-ios/blob/master/Utils/Extensions/NSURLExtensions.swift

has a nice self-contained base domain implementation that should be easily portable to Java.

Comment 3

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(In reply to Sebastian Kaspari (:sebastian) from comment #1)
> 1) The fallback is triggered way to often.

If we can get the favicons (bug 1269821?) to show up often enough than I'd say there are better things we should spend our time on and we should WONTFIX – adding soft-dep.

> 2) I don't think "s" for search.yahoo.com is necessarily wrong.

Agreed.

> - URLs with sub domains that offer different content/services:
> maps.google.com, plus.google.com, mail.google.com - Do we want to use the
> prefix of the service (M, P, M) or really just G? Same situation for
> bugzilla.mozilla.org (B vs. M)

I don't think I'm passionate about either. In the case, of Google, I might prefer G.

> - URLs where the subdomain is actually representative: mykzilla.blogspot.com
> (M vs. B), cookupastory.wordpress.com (C vs. W), espn.go.com (E vs. G)

Fair point.

If we're being nitty, I think the base domain is a better compromise than the subdomain because subdomains are often implementation details rather than content details, e.g. I'd rather see "B" for mykzilla.blogspot.com than see "S" for search.yahoo.com.

We could also consider using two letters, e.g. "M.B" for mkzilla.blogspot.com

(In reply to Richard Newman [:rnewman] from comment #2)
> https://github.com/mozilla/firefox-ios/blob/master/Utils/Extensions/
> NSURLExtensions.swift
> 
> has a nice self-contained base domain implementation that should be easily
> portable to Java.

I skimmed this and it uses effective_tld_names.dat, which is in m-c:
  http://mxr.mozilla.org/mozilla-central/find?text=&string=effective_tld

Comment 4

[:Margaret Leibovic]

We should also follow along with the activity stream team to see what they're doing, since the same problem applies to them.

Comment 5

[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.