Users are conditioned to wrap embedded images in bbcode, img then make it a clickable url in the case of postimg.cc However when we click this thumbnail it remains a small thumbnail in the lightbox.
Expected Behavior: When we click the thumbnail moho should process the bbcode and use the full screen image displayed in the wrapped url in the lightbox.
Users are conditioned to wrap embedded images in bbcode, img then make it a clickable url in the case of postimg.cc However when we click this thumbnail it remains a small thumbnail in the lightbox.
Expected Behavior: When we click the thumbnail moho should process the bbcode and use the full screen image displayed in the wrapped url in the lightbox.
Salastil
added the bug label 2026-09-11 15:58:36 -04:00
[url=X][img]Y[/img][/url] is now read as what it means - show Y, open X - and the viewer gets X.
Where X is a link straight to a bigger file, it is used as it stands. Where X is a page, which is what postimg.cc gives you, the page is asked once what it is showing, at the moment somebody opens the picture. Every image host answers in the same place: the OpenGraph tag it publishes so a pasted link unfurls in a chat window. Checked against a real postimg page, which returns exactly the full-size file the thumbnail stands for, so no per-host knowledge is needed.
The request is made by the main process - a window here is a file:// document and cannot read a cross-origin reply - and only on a click, never as a message arrives.
Two things turned up while pairing them, both fixed here: the wrapped link was being drawn as a second embed of the same picture, and stripping it out of the text left an empty anchor behind.
One limit worth stating: a page that is not about a single picture answers with whatever it uses for a preview, so this is as right as the page it asked.
Finished in [`6af6ac3`](https://git.salastil.com/Salastil/moho/commit/6af6ac3).
`[url=X][img]Y[/img][/url]` is now read as what it means - show Y, open X - and the viewer gets X.
Where X is a link straight to a bigger file, it is used as it stands. Where X is a *page*, which is what postimg.cc gives you, the page is asked once what it is showing, at the moment somebody opens the picture. Every image host answers in the same place: the OpenGraph tag it publishes so a pasted link unfurls in a chat window. Checked against a real postimg page, which returns exactly the full-size file the thumbnail stands for, so no per-host knowledge is needed.
The request is made by the main process - a window here is a `file://` document and cannot read a cross-origin reply - and only on a click, never as a message arrives.
Two things turned up while pairing them, both fixed here: the wrapped link was being drawn as a *second* embed of the same picture, and stripping it out of the text left an empty anchor behind.
One limit worth stating: a page that is not about a single picture answers with whatever it uses for a preview, so this is as right as the page it asked.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Users are conditioned to wrap embedded images in bbcode, img then make it a clickable url in the case of postimg.cc However when we click this thumbnail it remains a small thumbnail in the lightbox.
Expected Behavior: When we click the thumbnail moho should process the bbcode and use the full screen image displayed in the wrapped url in the lightbox.
Finished in
6af6ac3.[url=X][img]Y[/img][/url]is now read as what it means - show Y, open X - and the viewer gets X.Where X is a link straight to a bigger file, it is used as it stands. Where X is a page, which is what postimg.cc gives you, the page is asked once what it is showing, at the moment somebody opens the picture. Every image host answers in the same place: the OpenGraph tag it publishes so a pasted link unfurls in a chat window. Checked against a real postimg page, which returns exactly the full-size file the thumbnail stands for, so no per-host knowledge is needed.
The request is made by the main process - a window here is a
file://document and cannot read a cross-origin reply - and only on a click, never as a message arrives.Two things turned up while pairing them, both fixed here: the wrapped link was being drawn as a second embed of the same picture, and stripping it out of the text left an empty anchor behind.
One limit worth stating: a page that is not about a single picture answers with whatever it uses for a preview, so this is as right as the page it asked.