fix: the figures carried a chunk WebKit refuses, which is why a page never loaded
The user's report was precise and I misread it twice: opening trigger.page as a *file* rendered the page with no image, while opening it through the app's `help:` URI spun forever. Both are one cause. The three figures carried a `bKGD` chunk -- and the PNG specification does not permit `bKGD` on an image with an alpha channel, which all three are (colour type 6). ImageMagick both writes and reads it, so my "decodes fully" check proved nothing: I tested with a decoder more permissive than the one that has to load the file. WebKit rejects it, so the image never appears; over `help:` the fetch never completes either, so the page's load event never fires and Yelp's spinner never stops. It came from `import`, which records the root window's background. Every figure now carries only the chunks a decoder is guaranteed to accept (IHDR/IDAT/IEND), and `tools/make-help-shots.sh` normalises its output at the end so a re-shoot cannot reintroduce it -- with the reason written where the next reader will be, since "ImageMagick reads it" is exactly the trap. `tools/check_help.sh` gains the rule, because the four yelp-check subcommands and the structural rules are all blind to a figure no decoder will accept: a `bKGD` on colour type 4 or 6 is a finding, checked directly rather than through a permissive tool. It is a whitelist because a decoder is one. Verified: the rule fires on the committed figures (colour type 6, bKGD present) and passes on the fixed ones; the figures still decode and are still 1280x800 / 938x420; check_help.sh is green on the source and installed sets; make -C build test-help passes.
This commit is contained in:
1 parent
fe499bfe41
commit
6138e6bdce
5 files changed
+60
-9
No files matched your search
Binary file not shown.
|
Before Width: | Height: | Size: 129 KiB After Width: | Height: | Size: 123 KiB |
Reference in new issue
Block a user