-
Notifications
You must be signed in to change notification settings - Fork 895
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Obtains the Publisher/Content Creators portrait image to use for the BAT panel favicon #3464
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -259,7 +259,9 @@ void Publisher::SaveVisitInternal( | |
publisher_info->favicon_url = fav_icon; | ||
} | ||
} else { | ||
publisher_info->favicon_url = ledger::kClearFavicon; | ||
if (publisher_info->favicon_url.empty()) { | ||
publisher_info->favicon_url = ledger::kClearFavicon; | ||
} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. During a page load, we save the pub info a lot. At one point during the page load/parse, we have a valid favicon url, but at a later point, it is empty as it cannot be parsed (at that point). If an empty URL is passed in and we already have a favicon, this change prevents us clearing the existing favicon url. Can anyone see a problem with this, as other paths than Vimeo will use the same logic flow... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we would have a problem with this code as if we save some wrong url that is not stored in chromium favicon storage then we will never clear it There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Bear in mind if we do parse a URL, it will always be saved. Also - if we implement the favicon cache expiration we mentioned, it will eventually self-repair even if the above did happen. WDYT? (I've yet to test this against production BTW - the change is here for discussion only ATM) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Further - this doesn't seem to work anyway 🤔 which is a bit odd. The challenge ATM is that during the page scrape, the content doesn't have anything containing the Users portrait ID, so it ends up removing any prior Favicon. |
||
} | ||
|
||
publisher_info->name = visit_data.name; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should check for !is_verified and always clear if that is the case (discussed with @NejcZdovc)