Enhance tiles more specifically than eTLD+1/baseDomain (e.g., no enhance bugzilla.mozilla.org for mozilla.org)

VERIFIED FIXED in Firefox 33

Status

()

Firefox
New Tab Page
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: Mardak, Assigned: Mardak)

Tracking

(Blocks: 1 bug)

Trunk
Firefox 34
Points:
5
Dependency tree / graph
Bug Flags:
firefox-backlog +
in-testsuite +
qe-verify +

Firefox Tracking Flags

(firefox33 verified, firefox34 verified)

Details

Attachments

(1 attachment, 3 obsolete attachments)

(Assignee)

Description

3 years ago
jaws points out that the current eTLD+1/baseDomain enhancement causes bugzilla.mozilla.org to be enhanced by mozilla.org's enhanced tile.

Fyi, bug 990322 is to only show one thumbnail from a given eTLD+1, so if the user would have both bugzilla.mozilla.org and mozilla.org, only one of them would be shown, and we would probably want to enhance that one tile.

An alternative I mentioned in bug 990322 comment 4 is that maybe we should just take the whole domain.
If we did this, we need to treat 'www.example.com' as the same as 'example.com', and potentially any other generic subdomains.
(Assignee)

Updated

3 years ago
Blocks: 1030832
(Assignee)

Comment 2

3 years ago
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #1)
> If we did this, we need to treat 'www.example.com' as the same as
> 'example.com', and potentially any other generic subdomains.
Not sure what's a good way to handle this and if that blocks fixing this bug or not.

Doing a quick scan through my top tiles, I see prefixes including www. wwws. online. m. web. for english sites.
Flags: needinfo?(clarkbw)
(Assignee)

Comment 3

3 years ago
Also, dao has a patch in bug 990322 to remove repeat tiles from the same eTLD+1, but we probably want to use the same logic here and there.
(Assignee)

Updated

3 years ago
Depends on: 990322
(Assignee)

Comment 4

3 years ago
We won't do something smarter than eTLD+1 initially especially given bug 990322 probably landing soon where there wouldn't be multiple tiles from the same eTLD+2 but same eTLD+1.
No longer blocks: 1030832
Flags: needinfo?(clarkbw)
(Assignee)

Updated

3 years ago
Blocks: 1050643
This has more or less broken the new tab page for me. I went from having 9 useful tiles to 1 often used tile, 5 infrequently visited tiles and 9 blank tiles.
(Assignee)

Comment 6

3 years ago
(In reply to Kevin Brosnan [:kbrosnan] from comment #5)
> I went from having 9 useful tiles to 1 often used tile, 5 infrequently visited
This bug 1045760 is part of making that smarter instead of only going by eTLD+1. Curious, are the tiles getting merged all mozilla.org? You can drag bookmarks into the new tab tiles to pin a site (where pinned sites don't get duped).

Comment 7

3 years ago
(In reply to Ed Lee :Mardak from comment #6)
> Curious, are the tiles getting merged all mozilla.org? You can drag bookmarks  
> into the new tab tiles to pin a site (where pinned sites don't get duped).

Yes, multiple manually pinned tiles are getting the mozilla.org "banner" image and identical tile title. You have to hover to reveal the actual link.
(Assignee)

Updated

3 years ago
Assignee: nobody → edilee
Points: --- → 5
Flags: firefox-backlog+
(Assignee)

Comment 8

3 years ago
Created attachment 8481075 [details] [diff] [review]
v1
Attachment #8481075 - Flags: review?(dao)

Updated

3 years ago
Status: NEW → ASSIGNED
Flags: qe-verify?
(Assignee)

Comment 9

3 years ago
Created attachment 8481076 [details] [diff] [review]
v1
Attachment #8481075 - Attachment is obsolete: true
Attachment #8481075 - Flags: review?(dao)
Attachment #8481076 - Flags: review?(dao)
(Assignee)

Comment 10

3 years ago
With my own profile, the patch here shows these additional sites:

(tbpl.mozilla.org current top eTLD+1 mozilla.org)
bugzilla.mozilla.org
air.mozilla.org
hg.mozilla.org
addons.mozilla.org
trychooser.pub.build.mozilla.org
intranet.mozilla.org

(cloud.feedly.com current top eTLD+1 feedly.com)
feedly.com

(mail.google.com current top eTLD+1 google.com)
docs.google.com
maps.google.com
news.google.com
drive.google.com
www.google.com (/flights)
plus.google.com
Comment on attachment 8481076 [details] [diff] [review]
v1

>+      let eTLD2 = Services.eTLD.getBaseDomain(uri, 1);

eTLD+2 doesn't make much sense to me. It seems arbitrary...? Why not use the full domain at this point?

>+      // Strip off common subdomains of the same site (e.g., www, load balance)
>+      return eTLD2.replace(/^(m(obile)?|secure|www*s?)\d*\./, "");

This is kind of annoying, this list will get very long if it should cover a wide range of non-distinctive subdomains (let alone for different locales). And then there will be false positives, e.g. there might be good reasons why a user would choose between secure.foo.bar and foo.bar depending on the situation.

By the way, what's wws / wwws? I don't recall having ever seen this.
Attachment #8481076 - Flags: review?(dao)
(Assignee)

Comment 12

3 years ago
Created attachment 8481450 [details] [diff] [review]
v2

(In reply to Dão Gottwald [:dao] from comment #11)
> >+      let eTLD2 = Services.eTLD.getBaseDomain(uri, 1);
> eTLD+2 doesn't make much sense to me. It seems arbitrary...? Why not use the
> full domain at this point?
That's exactly what I said in bug 990322 comment 4! ;) Switched to just asciiHost.

At least from my own top 100 links, the only difference between eTLD+2 vs asciiHost (assuming the same www-type cleanup) is build.mozilla.org vs trychooser.pub.build.mozilla.org.

> >+      // Strip off common subdomains of the same site (e.g., www, load balance)
> >+      return eTLD2.replace(/^(m(obile)?|secure|www*s?)\d*\./, "");
> This is kind of annoying, this list will get very long if it should cover a
> wide range of non-distinctive subdomains (let alone for different locales).
Nod. I was analyzing all the hosts in my moz_hosts and there were other ones that came up such as i\d*. s\d*. although the latter would have incorrectly trimmed off s3.amazonaws.com.

> And then there will be false positives, e.g. there might be good reasons why
> a user would choose between secure.foo.bar and foo.bar depending on the
> situation.
> By the way, what's wws / wwws? I don't recall having ever seen this.
The secure and www*s are related where some sites use "wwws" to imply a secure subdomain. Actually, I only see it for mint.com. Removed secure/wwws.
Attachment #8481076 - Attachment is obsolete: true
Attachment #8481450 - Flags: review?(dao)
Comment on attachment 8481450 [details] [diff] [review]
v2

>+    // Strip off common subdomains of the same site (e.g., www, load balancer)
>+    return uri.asciiHost.replace(/^(m(obile)?|www*)\d*\./, "");

I'd prefer m|mobile over m(obile)?.

I don't think m\d, mobile\d, ww or wwww are common enough to be included here. Can you remove them too?
(Assignee)

Comment 14

3 years ago
Created attachment 8481542 [details] [diff] [review]
v3
Attachment #8481450 - Attachment is obsolete: true
Attachment #8481450 - Flags: review?(dao)
Attachment #8481542 - Flags: review?(dao)

Updated

3 years ago
Attachment #8481542 - Flags: review?(dao) → review+
(Assignee)

Comment 15

3 years ago
Comment on attachment 8481542 [details] [diff] [review]
v3

Approval Request Comment
[Feature/regressing bug #]: bug 990322 / bug 1036299
[User impact if declined]: Only one mozilla.org tile will be shown/enhanced limiting our ability to multiple mozilla directory tiles (e.g., mozilla, android, customize, mdn, etc.). Some *.mozilla.org users have reported reduced usefulness of the newtab page because those get collapsed into one.
[Describe test coverage new/current, TBPL]: Adds tests for what should be consolidated into a single tile or not with existing tests updated from eTLD+1 to full host.
[Risks and why]: Small tweak from eTLD+1 to whole host, and would uplift after it bakes on m-c.
[String/UUID change made/needed]: none
Attachment #8481542 - Flags: approval-mozilla-aurora?
status-firefox33: --- → affected
status-firefox34: --- → affected
https://hg.mozilla.org/mozilla-central/rev/29d70a643e65
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 34

Updated

3 years ago
Iteration: --- → 34.3
Attachment #8481542 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Comment 17

3 years ago
http://hg.mozilla.org/releases/mozilla-aurora/rev/111405b7a28a
status-firefox33: affected → fixed
status-firefox34: affected → fixed
Flags: qe-verify? → qe-verify+
QA Contact: cornel.ionce
Verified fixed on Windows 7 64bit, Mac OS X 10.9 and Ubuntu 14.04 using Firefox 34.0a1 Nightly (build ID: 20140902030202) and Firefox 33.0a2 Aurora (build ID: 20140902004002).
Status: RESOLVED → VERIFIED
status-firefox33: fixed → verified
status-firefox34: fixed → verified

Updated

3 years ago
See Also: → bug 1112018
You need to log in before you can comment on or make changes to this bug.