Closed Bug 934702 Opened 8 years ago Closed 5 years ago

Model, expose, and use the concept of a 'site'

Categories

(Firefox for Android Graveyard :: General, defect)

All
Android
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: rnewman, Unassigned)

References

Details

We expose Top Sites front-and-center in our UI. Unfortunately, the user concept of a "site" falls down pretty hard in the face of URLs -- see Bug 934030, Bug 934644, and the well-known "m.foo.com" problem (e.g., Send Tab or bookmarking the mobile version of a page is unpleasant when you revisit that page on a different device).

The symptoms of this: not show favicons or thumbnails when we could, just because a 3xx got in the way; doing redundant network operations because we don't record the chain of favicon (or page!) redirects (Bug 925878); failing to boost the Top-ness of a site, just because your desktop visits are being recorded under a different URL; perhaps others.

We should consider recording and maintaining a shared conception of a "site" which would accrete into a single entity different URLs related by a translation (e.g., a network redirect).

mfinkle uttered the forbidden word "docshell" when I mentioned this idea. Gulp.
If I suspect oceans need to be boiled to make this happen, I will push to shut it down. This has "Yak Shaving Expedition" written all over it.
(In reply to Mark Finkle (:mfinkle) from comment #1)
> If I suspect oceans need to be boiled to make this happen, I will push to
> shut it down. This has "Yak Shaving Expedition" written all over it.

I don't think it is necessarily as crazy as it might seem. Places is 90% of the way there:

---
Every visit is identified by its visit date, and a visit type (also known as transition type) that represents how we have come to that page (typed, click, redirect, bookmark, etc.). An additional property of a visit is the visit we have come from, this is used to track visit chains in global history, so for example if clicking a link causes a redirect the from visit will allow to follow up the chain of visits. At the moment this is used when catching favicons or bookmarks for redirected pages.
---

which means that much of the plumbing will be there, too. We'd need to:

* Extend our own Java-side DB with a notion of visits (which would also save Sync from having to maintain its parallel and ever-growing JSON visit table, which is as awful as it sounds).
* Successfully coordinate page load events with visits across the bridge.
* Expose visit chains in a useful way: redirect-centered chain fragments would be used to find thumbnails and favicons, and to compute frecency.
Duplicate of this bug: 934644
Blocks: 1004484
See Also: → 1064925
Blocks: 838332
No longer blocks: 838332
See Also: → 838332
Duplicate of this bug: 1158381
No longer blocks: 699577
It's been years and this bug has gone nowhere. I don't want us to block on a perfect solution to start fixing some obvious problems with our top sites logic.
No longer blocks: 1237038
I don't think we should try to do this, since I think it's impossible to do it correctly. We should first come up with some simple heuristics to make our current top sites more useful.

See also comment 1.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
No longer blocks: 925878
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.