Closed Bug 1317536 Opened 8 years ago Closed 7 years ago

Top Sites is showing links to specific pages of a domain instead of just the domain's home page

Categories

(Firefox for iOS :: Home screen, defect, P1)

Other
iOS
defect

Tracking

()

RESOLVED FIXED
Iteration:
1.20
Tracking Status
fxios 8.0+ ---

People

(Reporter: farhan, Assigned: farhan)

References

Details

(Whiteboard: [MobileAS])

Attachments

(1 file, 1 obsolete file)

55 bytes, text/x-github-pull-request
Details | Review
On a fresh install

1. Go to http://digg.com/source/techcrunch.com
2. Click a few articles that take you to techcrunch. 
3. A top site tile should appear for techcrunch

Expected: The techcrunch tile should take you to the homepage

Actual: It takes you to one of the articles you visited.
Summary: Top Sites is showing links to specific articles instead of just home page → Top Sites is showing links to specific pages of a domain instead of just the domain's home page
Priority: -- → P3
(Obligatory back-pointer to Bug 1184582.)
I find this bug rather annoying.
tracking-fxios: --- → ?
See if this also is happening on our AS panel top sites.
Priority: P3 → P2
Whiteboard: [mobileAS] → [MobileAS]
Attached file Pull Request (obsolete) —
Attachment #8822566 - Flags: review?(bnicholson)
Assignee: nobody → fpatel
Iteration: --- → 1.12
Priority: P2 → P1
Comment on attachment 8822566 [details] [review]
Pull Request

Worth noting that this behavior will be less desirable in certain situations (e.g., I have https://people-mozilla.org/~bnicholson/test/ as a top site; https://people-mozilla.org is useless on its own), but I expect that as a sum, this will be an overall improvement.

Left one comment about components being stripped using domainURL -- I don't think we'll want to remove the www/mobile/m prefix.
Attachment #8822566 - Flags: review?(bnicholson) → review+
Isn't this the exact opposite of Bug 1231515, desktop's behavior, and the end result we worked out in Bug 1184582?

What we wanted to do was roughly what desktop does:

- If there's a clear winner, use that: if you go to the same TechCrunch article fifty times, because you love it, then we should take you there rather than techcrunch.com.
- If there isn't, use 'greatest common sub-path': perhaps you always go to amazon.com/mp3. Or say I visit pages under https://reddit.com/r/cats a lot, I'll end up with a 'reddit' tile… and it should take me to /r/cats, not /.
- Otherwise, use the domain.

We didn't get all the way there, but it's pretty likely that /r/cats will 'win' the tile, and so *mostly* Fennec's Top Sites does what you expect. If it doesn't, it will at least take you somewhere you've actually been.

Where that falls down is Gmail and the like, which have a broad spread of URLs, and each one is useless… but the best URL for Gmail is https://mail.google.com/mail, so we're back to greatest common sub-path.

If, on the other hand, you always go to bbc.com/news, this PR will cause your tile to always take you to bbc.com/. That's a regression -- you're introducing predictability, but it's a predictably bad result!

My opinion: if you want to fix this, do it right: calculate a 'winner' URL for a domain as part of the Top Sites computation, and use that for the tile. This PR alone isn't worth the churn in the user experience.
Iteration: 1.12 → 1.13
Top Sites shouldn't only support links to domain home pages. Top Sites should have a long (ish) view of a users activity and present to them their "for sure top utilized" sites. It should avoid recently interacted content since that's what highlights is meant to address. If a user is in fact a repeat user of a specific article and they have been for a long while then that would definitely be a Top Site. 

The desktop team has worked a long while on Top Sites, while its still not completely perfect it has been getting pretty good, can we look into evaluating the system the Desktop Team is using and mimic that or simple use that same system for mobile?
Assignee: fpatel → nobody
Iteration: 1.13 → ---
Priority: P1 → P2
I spent some time understand the SQL queries. Something weird is happening indeed. 


I have 3 different history items for google.ca.

1 - A search result page with one visit. (localvisit)
2 - A search result page with 3 visits. where one is a remoteVisit
3 - The google.ca homepage with 8 localvisits. 

So naturally, the TopSite url should be #3 but actually number 2 wins!? weird. 

Looking at the comments in the code and in the respective bugs localvisits are suppose to be weighted heavier but something funky is going on. 

I've been verifying this by opening my DB in a sqlite browser.
Assignee: nobody → fpatel
Iteration: --- → 1.19
Priority: P2 → P1
Attached file Pull Request
Attachment #8822566 - Attachment is obsolete: true
Attachment #8855356 - Flags: review?(rnewman)
Comment on attachment 8855356 [details] [review]
Pull Request

I left a pointer to Bug 1311150 Comment 2, which should explain why this isn't a fix.
Attachment #8855356 - Flags: review?(rnewman) → review-
Comment on attachment 8855356 [details] [review]
Pull Request

I've added a note about the GROUP BY usage. Ready for re-review
Attachment #8855356 - Flags: review- → review+
Attachment #8855356 - Flags: review+ → review?(rnewman)
Iteration: 1.19 → 1.20
Iteration: 1.20 → 1.19
Iteration: 1.19 → 1.20
Comment on attachment 8855356 [details] [review]
Pull Request

was marked as review on GH
Attachment #8855356 - Flags: review?(rnewman)
master https://github.com/mozilla-mobile/firefox-ios/commit/748e137dfd5b020b56fc481b25e0d2366acb3df2
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: