Find logo: why each image failed is collected and never shown, and the favicon fallback is often cut off #526

New issue

Closed

opened 2026-10-01 10:47:23 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-10-01 10:47:23 +00:00

Owner

Found on 2026-09-29 in a read-only review of postulo at 95348908d, reading find_on_website.

Related to #21.

Checked again on 2026-10-01 against main at 0a5cad587: still present. jobs/logos.py has not changed.

find_on_website keeps each candidate's UnusableLogo message in a list called problems and never reads it, so a person who presses Find logo is told only that nothing could be used, never why. The same function appends /favicon.ico as the last resort and then tries only the first six candidates, so on any page that declares six or more icons the fallback is never tried.

Where: jobs/logos.py:321-335 (find_on_website): candidates.append(urljoin(base, "/favicon.ico")) at 321, problems = [] at 323, for candidate in candidates[:6]: at 324, problems.append(str(error)) at 329, and the final UnusableLogo at 332-335, which does not use problems. The candidates come from _LogoLinks.candidates (jobs/logos.py:247-256): every declared apple-touch-icon, then every icon, then the organisation's JSON-LD logo, then og:image.
What happens: a site whose declared icons all answer 403 to a request without its cookies, or are larger than MAX_BYTES, gives the errand the message "Nothing on example.com could be used as a logo." The reasons download and process produced ("The address answered 403.", "That file is larger than a logo should be.") are thrown away, and nothing is logged. A site that declares seven apple-touch-icon sizes, which is common, has its favicon dropped from the list, although it may be the one image that would have worked.
Why it matters: the person cannot tell a site that blocks fetching from one with no usable icon, so cannot decide whether pasting an address or uploading a file is the next step. The unused list reads as if the reasons were reported, which is how the gap has gone unnoticed.
Fix: add the first reason (or the last) to the final message, for example "Nothing on %(host)s could be used as a logo: %(reason)s", and log the rest at info. Cut the declared candidates to five before appending /favicon.ico, so the fallback is always the sixth try.

Done when

Tests in tests/test_logos.py, beside test_a_site_with_nothing_usable_says_so: a site whose only icon answers 403 yields a message that names the 403; and a page declaring seven icons that all fail still has /favicon.ico fetched. Both fail today.

Found on 2026-09-29 in a read-only review of postulo at 95348908d, reading `find_on_website`. Related to #21. Checked again on 2026-10-01 against `main` at `0a5cad587`: still present. `jobs/logos.py` has not changed. `find_on_website` keeps each candidate's `UnusableLogo` message in a list called `problems` and never reads it, so a person who presses *Find logo* is told only that nothing could be used, never why. The same function appends `/favicon.ico` as the last resort and then tries only the first six candidates, so on any page that declares six or more icons the fallback is never tried. - **Where:** `jobs/logos.py:321-335` (`find_on_website`): `candidates.append(urljoin(base, "/favicon.ico"))` at 321, `problems = []` at 323, `for candidate in candidates[:6]:` at 324, `problems.append(str(error))` at 329, and the final `UnusableLogo` at 332-335, which does not use `problems`. The candidates come from `_LogoLinks.candidates` (`jobs/logos.py:247-256`): every declared `apple-touch-icon`, then every `icon`, then the organisation's JSON-LD logo, then `og:image`. - **What happens:** a site whose declared icons all answer 403 to a request without its cookies, or are larger than `MAX_BYTES`, gives the errand the message "Nothing on example.com could be used as a logo." The reasons `download` and `process` produced ("The address answered 403.", "That file is larger than a logo should be.") are thrown away, and nothing is logged. A site that declares seven `apple-touch-icon` sizes, which is common, has its favicon dropped from the list, although it may be the one image that would have worked. - **Why it matters:** the person cannot tell a site that blocks fetching from one with no usable icon, so cannot decide whether pasting an address or uploading a file is the next step. The unused list reads as if the reasons were reported, which is how the gap has gone unnoticed. - **Fix:** add the first reason (or the last) to the final message, for example "Nothing on %(host)s could be used as a logo: %(reason)s", and log the rest at `info`. Cut the declared candidates to five before appending `/favicon.ico`, so the fallback is always the sixth try. ## Done when - Tests in `tests/test_logos.py`, beside `test_a_site_with_nothing_usable_says_so`: a site whose only icon answers 403 yields a message that names the 403; and a page declaring seven icons that all fail still has `/favicon.ico` fetched. Both fail today.

tiagoagueda added this to the 0.6.0 milestone

2026-10-01 10:47:23 +00:00

tiagoagueda added the

enhancement

tier

labels

2026-10-01 10:47:23 +00:00

tiagoagueda referenced this issue

2026-10-03 01:58:52 +00:00

Find logo and Refresh logo in a dialog on the company's page, not on a page of their own #674

tiagoagueda referenced this issue from a commit

2026-10-05 13:02:00 +00:00