Open
Bug 487813
Opened 16 years ago
Updated 2 years ago
Better calculate frecencies for multi-redirected pages
Categories
(Toolkit :: Places, defect, P3)
Toolkit
Places
Tracking
()
NEW
People
(Reporter: Mardak, Unassigned)
References
(Depends on 1 open bug)
Details
Bug 418738 kinda had a fix for the one-off redirect such as for google results that redirect through google before going to the actual page.
But in general, there could be two or more directs, so right now these are missed because we don't have an easy way to get at the beginning/end of a redirect chain. And this causes invalid frecencies to be recalculated as invalid.
How we give out frecencies is a separate issue though. For the intermediate pages, perhaps they should have lower frecencies but give bigger bonuses for the start and end page? The start page is what the user typed in so they're potentially familiar with it.. but the end page is what the user really wants to get to.
Personally, I manually delete these intermediate pages so I can just jump straight to the end page.. But this isn't as useful for random links I click on and don't type in.
Bug 476298 tries to recalculate all invalid frecencies, but because of this bug, a bunch of pages might still end up as invalid.
Comment 1•8 years ago
|
||
For now in bug 737836 I'm suggesting to change the redirect bonuses from 0 to a positive value. It makes sense cause transitions are how we reached the page and we want to lower score of redirects, not of their targets.
That should partially solve this (unblocking some frecencies from eternal -1 value), but we won't properly apply the source transition type to the final target, cause the query can't get it.
We could maybe create a short-lived memory hash that keeps redirects chains in memory for 5 minutes, and use it to recover the first redirect transition type.
Updated•8 years ago
|
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•