FetchPageDataService should take nsIURI and use loadURI instead of fixupAndLoadURIString
Categories
(Firefox :: Bookmarks & History, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox112 | --- | affected |
People
(Reporter: Gijs, Unassigned)
References
Details
AFAICT there are no non-test consumers, also not for queueing the URLs. I don't know if this should be removed instead or if we still have plans for it, or if I'm missing something. If we do have plans for it or I'm missing something, updating it and the tests that rely on it should be reasonably straightforward right now?
Dave, do you know what the status of this code is?
Comment 1•2 years ago
|
||
I'm not aware of plans to use this right now, maybe Stuart does. Otherwise we can probably remove all this code.
Comment 2•2 years ago
|
||
I'm not aware of anything at the moment, what was the original use-case?
| Reporter | ||
Comment 3•2 years ago
|
||
(In reply to scolville from comment #2)
I'm not aware of anything at the moment, what was the original use-case?
I wasn't involved so I don't know. Mossop?
Comment 4•2 years ago
|
||
(In reply to :Gijs (he/him) from comment #3)
(In reply to scolville from comment #2)
I'm not aware of anything at the moment, what was the original use-case?
I wasn't involved so I don't know. Mossop?
The use case was capturing more rich data about pages to display say in the awesomebar/tabs. So better titles that the DOM page title was the first main use but down the road the goal would have been things like product information, prices, etc. for richer shopping experience and identifying similar pages.
Comment 5•2 years ago
|
||
The severity field is not set for this bug.
:mossop, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 6•1 year ago
|
||
Marco, is the PageDataService something we're likely to use anytime soon, maybe for search or the address bar? If not we should probably remove it.
Comment 7•1 year ago
|
||
(In reply to Dave Townsend [:mossop] from comment #6)
Marco, is the PageDataService something we're likely to use anytime soon, maybe for search or the address bar? If not we should probably remove it.
That's still TBD, unfortunately.
There are plans to fetch and store distilled page information for Search reasons, but it's unclear whether it will be through PageDataService or through a local small language model, and whether that model will be integrated in PageDataService or be on its own.
I suppose the cost here is packaged code that we're not using, and some minor cost to include the module.
If that's something we want to remove, it would not be a problem to reintroduce the code in the future.
Comment 8•1 year ago
|
||
It's a pretty minor cost and the feature itself is disabled right now. Only cost really is that we run tests on it so using CI time, and I just had to review a patch to it.
Comment 9•1 year ago
|
||
Spending dev time on it is probably not a great idea yet, so that alone may be a reason to remove it.
Updated•8 months ago
|
Description
•