- Dillo-dev - lists.mailman3.com

Re: Rendering issue with view source and large embedded images

by a1ex＠dismail.de

Rodrigo Arias <rodarima(a)gmail.com> wrote: > >How did you manage to install a new version of FLTK? > > Oh, I just saw they updated to 1.3.9 some days ago: > > https://github.com/openbsd/ports/commit/589a761a9af2a91e81a5800b963fa4448ec… > > Maybe I can just update the repos somehow or wait a bit until it > appears. The newer version is now available in snapshots. I just tested it and unfortunately the issues remain the same. -Alex

Oct. 19, 2024

Re: Rendering issue with view source and large embedded images

by a1ex＠dismail.de

Rodrigo Arias <rodarima(a)gmail.com> wrote: > >How did you manage to install a new version of FLTK? > > Oh, I just saw they updated to 1.3.9 some days ago: > > https://github.com/openbsd/ports/commit/589a761a9af2a91e81a5800b963fa4448ec… > > Maybe I can just update the repos somehow or wait a bit until it > appears. Nice catch, it seems that this update has not hit the snapshots yet, so we will have to wait and see. I am somewhat sceptical that this is an FLTK issue. But, to update the system FLTK package, you could just remove it (and the stock Dillo), and then just build/install them from source: # pkg_delete fltk dillo ... -Alex

Oct. 18, 2024

Re: Rendering issue with view source and large embedded images

by Rodrigo Arias

>How did you manage to install a new version of FLTK? Oh, I just saw they updated to 1.3.9 some days ago: https://github.com/openbsd/ports/commit/589a761a9af2a91e81a5800b963fa4448ec… Maybe I can just update the repos somehow or wait a bit until it appears.

Oct. 18, 2024

Re: Rendering issue with view source and large embedded images

by Rodrigo Arias

Hi, On Fri, Oct 18, 2024 at 09:40:49PM +0200, a1ex(a)dismail.de wrote: >Hi Rodrigo, > >Sorry, I forgot to include this, maybe it can aid you in getting a >Dillo build environment set up for OpenBSD: > >Once you have a working system, open an xterm and do: ># pkg_add dillo git automake-1.16.5 autoconf-2.71p0 > >Then get the Dillo source and do: >$ export AUTOMAKE_VERSION="1.16" >$ export AUTOCONF_VERSION="2.71" >$ export CPPFLAGS="-I/usr/local/include -I/usr/X11R6/include" >$ export LDFLAGS="-L/usr/local/lib -L/usr/X11R6/lib" > >You should then be able to run autogen.sh and configure. > >As far as debugging tools, there is a gdb built-in but it's pretty >limited. It's probably better to install 'egdb': ># pkg_add egdb > >Also, the built-in 'ktrace' tool might be useful. Thanks! Managed to reproduce a crash with stock Dillo 3.1.1 by: 1. Opening: https://www.da.vidbuchanan.co.uk/blog/dram-emfi.html 2. Going to view source 3. Scroll to the bottom 4. Go to the previous tab 5. Reload 6. Crash: Nav_open_url: new url='dpi:/vsource/:https://www.da.vidbuchanan.co.uk/blog/dram-emfi.html' Nav_open_url: new url='https://www.da.vidbuchanan.co.uk/blog/dram-emfi.html' Segmentation fault (core dumped) There is a very weird behavior in the source code view with the long line of the image. How did you manage to install a new version of FLTK? Best, Rodrigo.

Oct. 18, 2024

Re: Rendering issue with view source and large embedded images

by a1ex＠dismail.de

Hi Rodrigo, Sorry, I forgot to include this, maybe it can aid you in getting a Dillo build environment set up for OpenBSD: Once you have a working system, open an xterm and do: # pkg_add dillo git automake-1.16.5 autoconf-2.71p0 Then get the Dillo source and do: $ export AUTOMAKE_VERSION="1.16" $ export AUTOCONF_VERSION="2.71" $ export CPPFLAGS="-I/usr/local/include -I/usr/X11R6/include" $ export LDFLAGS="-L/usr/local/lib -L/usr/X11R6/lib" You should then be able to run autogen.sh and configure. As far as debugging tools, there is a gdb built-in but it's pretty limited. It's probably better to install 'egdb': # pkg_add egdb Also, the built-in 'ktrace' tool might be useful. Regards, Alex

Oct. 18, 2024

Re: Navigation by pages

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > I decided to leave on YES for a simple reason: the laptop I was using > Dillo on didn't have a middle button, so the only way to close the > tabs was to press both buttons at the same time to emulate the middle > one (or the X button). So I assumed that it is possible that the same > scenario happens to other people too which only use an old laptop, > and they may think that the only way to close tabs is on the X button > on the right, as we don't have an X over each tab. > > Of course you can always change it to your preferences, but I think > it is a safer default this way to be easily discovered. Sounds fair, thanks for explaining. I guess there is no 'one size fits all' solution, but the setting is easy enough to change. I like the middle button specifically because it is harder to push, making it more difficult to close a tab by accident. > I would also prefer opening new tabs without the mouse wheel button > or the keyboard. So far I can to by clicking and holding the right > button, dragging a couple of pixels to the right to open in a new > tab, then releasing it. I'm thinking it may be nice to make this work > without the need of dragging, so by default it selects open in a new > tab. We can place a threshold to not consider quick press and release > events to cause the selection to be clicked. > > The same may be also doable with the left button, so if you click but > keep it pressed for a configurable threshold it is opened in a new > tab (of the other way around). Interesting! I like this idea and think it would be useful in various situations like limited hardware, or accessibility needs, etc. Hopefully its not too difficult to implement. Regards, Alex

Oct. 18, 2024

Re: Rendering issue with view source and large embedded images

by a1ex＠dismail.de

Hi, Rodrigo Arias <rodarima(a)gmail.com> wrote: > >I suspect that its OpenBSD which is helping to bring this issue out > >more. > > I got a QEMU virtual machine with OpenBSD 7.6 and Xorg, I'll try to > install a development environment there and do some testing. It is > taking me some time. I was able to reproduce the issue in QEMU with a completely stock OpenBSD install: https://alex.envs.net/test/qemu-dillo-test1.png -Alex

Oct. 18, 2024

Re: scroll_step description

by Kevin Koster

Rodrigo Arias wrote: > On Sat, Apr 20, 2024 at 01:54:26PM +1000, Kevin Koster wrote: >>There's a new "scroll_step" option in the example configuration file for >>3.1.0-rc1. The comment "Mouse wheel scroll step in pixels" suggests that >>this only affects the mouse wheel, but it also changes the distance the >>page moves when the arrow keys are pressed and the overlap of >>previous page content that's left when you press Page Up/Down. I think >>that's a little confusing, especially as the value has changed since >>the default behaviour in 3.0.5 (the old value seems to have been about >>25). > > This is now controlled independently with the scroll_page_overlap, which > by default uses the value 50 px. While the scroll_step controls how much > it advances with the arrows, by default 100 pixels. > > See: https://github.com/dillo-browser/dillo/pull/277 Great work! Much better to have separate settings.

Oct. 17, 2024

Re: Navigation by pages

by Rodrigo Arias

Hi, >Works fine for me! Thanks! I have also added two other improvements (last ones I promise). Clicking on the up and down buttons of the scrollbar in page mode jumps to the top and bottom. And scrolling a full page, now takes into account if the horizontal scrollbar is visible or not when computing the overlap, so the number of pixels of overlap you specify are always duplicated in the next page. Now I'm starting to miss the page scrolling mode in other programs... >> Also, do you usually set focus_new_tab to NO?, I'm considering >> switching the default to NO. Same with show_quit_dialog. > >I set 'NO' for both of those, but can understand why the original >decision was made to default to 'YES'. > >I think that Dillo was originally trying to cater to beginners and >people unfamiliar with how a browser works, but times have changed and >maybe adjusting some of these defaults would better serve our actual >userbase. I agree. Okay, so I will flip those then. >In my opinion this should also be the default: >right_click_closes_tab=NO > >It may be a matter of preference, but that is how the other browsers do >it. Most people are probably used to using the middle click for >this, and so having it close the tab with the right click might be >unexpected and undesired. I decided to leave on YES for a simple reason: the laptop I was using Dillo on didn't have a middle button, so the only way to close the tabs was to press both buttons at the same time to emulate the middle one (or the X button). So I assumed that it is possible that the same scenario happens to other people too which only use an old laptop, and they may think that the only way to close tabs is on the X button on the right, as we don't have an X over each tab. Of course you can always change it to your preferences, but I think it is a safer default this way to be easily discovered. In any case I have not done any research to back my claims. On my desktop I also use the right button, because I don't like clicking the mouse wheel (I think in my mouse is really hard to press), but this doesn't justify the defaults. I would also prefer opening new tabs without the mouse wheel button or the keyboard. So far I can to by clicking and holding the right button, dragging a couple of pixels to the right to open in a new tab, then releasing it. I'm thinking it may be nice to make this work without the need of dragging, so by default it selects open in a new tab. We can place a threshold to not consider quick press and release events to cause the selection to be clicked. The same may be also doable with the left button, so if you click but keep it pressed for a configurable threshold it is opened in a new tab (of the other way around). Best, Rodrigo.

Oct. 16, 2024

Re: Rendering issue with view source and large embedded images

by Rodrigo Arias

Hi, >Nothing special. I've tested this on a few different computers, mainly >an i5-4570 and other similar class hardware. > >I suspect that its OpenBSD which is helping to bring this issue out >more. I got a QEMU virtual machine with OpenBSD 7.6 and Xorg, I'll try to install a development environment there and do some testing. It is taking me some time. >Speaking of that, I tried to get valgrind going, but it seems broken on >OpenBSD due to various security mitigations they use. I'm wondering if they have their own tools, otherwise I'm not sure how they catch these types of bugs. Best, Rodrigo.

Oct. 16, 2024

Re: Rendering issue with view source and large embedded images

by a1ex＠dismail.de

Hi, Rodrigo Arias <rodarima(a)gmail.com> wrote: > >So, I'm not sure this is actually a dpi issue, but maybe that just > >exposes it more. > > Ah, interesting. It seems to be time sensitive then. That's probably > why I'm not able to see it. Do you have a particularly fast or slow > machine? Nothing special. I've tested this on a few different computers, mainly an i5-4570 and other similar class hardware. I suspect that its OpenBSD which is helping to bring this issue out more. Speaking of that, I tried to get valgrind going, but it seems broken on OpenBSD due to various security mitigations they use. Regards, Alex

Oct. 14, 2024

Re: Navigation by pages

by a1ex＠dismail.de

Hi, Rodrigo Arias <rodarima(a)gmail.com> wrote: > Clicking on the scrollbar arrows jumps to the top or bottom, and > holding the button pressed will repeat the page scrolling. This only > happens when the page scrolling mode is enabled (x)or Shift is hold. > > Please check the repeat and delay speeds, as I would rather prefer > not to add more options to dillorc today :-) Works fine for me! > Also, do you usually set focus_new_tab to NO?, I'm considering > switching the default to NO. Same with show_quit_dialog. I set 'NO' for both of those, but can understand why the original decision was made to default to 'YES'. I think that Dillo was originally trying to cater to beginners and people unfamiliar with how a browser works, but times have changed and maybe adjusting some of these defaults would better serve our actual userbase. In my opinion this should also be the default: right_click_closes_tab=NO It may be a matter of preference, but that is how the other browsers do it. Most people are probably used to using the middle click for this, and so having it close the tab with the right click might be unexpected and undesired. -Alex

Oct. 14, 2024

Re: Rendering issue with view source and large embedded images

by Rodrigo Arias

Hi, On Sun, Oct 13, 2024 at 09:23:33PM +0200, a1ex(a)dismail.de wrote: >Rodrigo Arias <rodarima(a)gmail.com> wrote: > >> One thing that may be easy to try in the meanwhile is to run the same >> test by from a local HTTP server, so we don't use the file: DPI. If >> the bug persists, then it is not related with the file DPI. You can >> use a lightweight web server like darkhttpd. > >When opening the test page with the file dpi, the issue is very easy to >trigger. > >When using a local webserver as you suggested, it doesn't seem to >happen... > >However, for example when refreshing the site: >https://www.da.vidbuchanan.co.uk/blog/dram-emfi.html >I still see stuff like this: > >** WARNING **: CCC: call on already finished chain. Flags=CCC_Aborted >IO_write, closing with pending data not sent: >"ntZ1uGVvMRmC5GANpBI4569aV... > >And eventual glitching and crash after many refreshes. > >So, I'm not sure this is actually a dpi issue, but maybe that just >exposes it more. Ah, interesting. It seems to be time sensitive then. That's probably why I'm not able to see it. Do you have a particularly fast or slow machine? >To sum it up, I don't know shit, but guessing: >A double free is leading to a buffer overrun on the chain to the data >uri parser. Yes, there is a double free, but the question is: what leads to that condition? When Dillo detects this "CCC: call on already finished chain", it should abort, as this situation should never happen. Best, Rodrigo.

Oct. 14, 2024

Re: Rendering issue with view source and large embedded images

by a1ex＠dismail.de

Rodrigo Arias <rodarima(a)gmail.com> wrote: > One thing that may be easy to try in the meanwhile is to run the same > test by from a local HTTP server, so we don't use the file: DPI. If > the bug persists, then it is not related with the file DPI. You can > use a lightweight web server like darkhttpd. When opening the test page with the file dpi, the issue is very easy to trigger. When using a local webserver as you suggested, it doesn't seem to happen... However, for example when refreshing the site: https://www.da.vidbuchanan.co.uk/blog/dram-emfi.html I still see stuff like this: ** WARNING **: CCC: call on already finished chain. Flags=CCC_Aborted IO_write, closing with pending data not sent: "ntZ1uGVvMRmC5GANpBI4569aV... And eventual glitching and crash after many refreshes. So, I'm not sure this is actually a dpi issue, but maybe that just exposes it more. To sum it up, I don't know shit, but guessing: A double free is leading to a buffer overrun on the chain to the data uri parser. -Alex

Oct. 13, 2024

Re: Rendering issue with view source and large embedded images

by Rodrigo Arias

Hi, >I built and installed a clean Dillo with your file dpi patch. I think I will need to reproduce this to examine the logs and inspect the state of the CCC and the DPI while the problem occurs. I will try getting a OpenBSD installation at some point and debug this (and other problems with FreeBSD too). One thing that may be easy to try in the meanwhile is to run the same test by from a local HTTP server, so we don't use the file: DPI. If the bug persists, then it is not related with the file DPI. You can use a lightweight web server like darkhttpd. >Thats interesting, in my previous testing a few days ago I noticed >some messages about 'a_Tls_connection' in the debugger, which made no >sense since I'm working with a local file: Yes, a_Tls_connection() is always called and returns NULL when is not a TLS connection. Weird logic... Rodrigo.

Oct. 13, 2024

Re: Scrollbar themeing

by Rodrigo Arias

Hi, On Sun, Oct 13, 2024 at 05:56:26PM +0200, a1ex(a)dismail.de wrote: >Hi, > >When using a dark theme, the scrollbar can be very hard to see: > >https://alex.envs.net/test/scroll-theme-stock1.png > >I made some changes and now the scrollbar looks nicer and is more >visible: > >https://alex.envs.net/test/scroll-theme-mod1.png > >If someone wants to try it, here is a patch which also includes some >commented lines which you can use to further customize the appearance >of the scrollbar. I think this is a side effect of altering the colormap only partially. I would imagine that by mapping *all* light colors to dark counterparts, you will get coherent box borders. Here is more info: https://www.fltk.org/doc-1.3/drawing.html https://www.fltk.org/doc-1.3/drawing.html#drawing_colors This is an example of such colormap that may be easy to try using Fl:set_color(): https://github.com/fltk-rs/fltk-theme/blob/main/src/color_themes/dark.rs https://www.fltk.org/doc-1.3/group__fl__attributes.html#gac62f634ba8089a9d0… Best, Rodrigo.

Oct. 13, 2024

Re: Navigation by pages

by Rodrigo Arias

>Nice, this will probably become my default setting now. > >Thanks for this awesome patch! Thanks! Here are a couple of improvements: https://github.com/dillo-browser/dillo/pull/278 Clicking on the scrollbar arrows jumps to the top or bottom, and holding the button pressed will repeat the page scrolling. This only happens when the page scrolling mode is enabled (x)or Shift is hold. Please check the repeat and delay speeds, as I would rather prefer not to add more options to dillorc today :-) Also, do you usually set focus_new_tab to NO?, I'm considering switching the default to NO. Same with show_quit_dialog. Best, Rodrigo.

Oct. 13, 2024

Re: scroll_step description

by Rodrigo Arias

Hi, On Sat, Apr 20, 2024 at 01:54:26PM +1000, Kevin Koster wrote: >There's a new "scroll_step" option in the example configuration file for >3.1.0-rc1. The comment "Mouse wheel scroll step in pixels" suggests that >this only affects the mouse wheel, but it also changes the distance the >page moves when the arrow keys are pressed and the overlap of >previous page content that's left when you press Page Up/Down. I think >that's a little confusing, especially as the value has changed since >the default behaviour in 3.0.5 (the old value seems to have been about >25). This is now controlled independently with the scroll_page_overlap, which by default uses the value 50 px. While the scroll_step controls how much it advances with the arrows, by default 100 pixels. See: https://github.com/dillo-browser/dillo/pull/277 Best, Rodrigo.

Oct. 13, 2024

Scrollbar themeing

by a1ex＠dismail.de

Hi, When using a dark theme, the scrollbar can be very hard to see: https://alex.envs.net/test/scroll-theme-stock1.png I made some changes and now the scrollbar looks nicer and is more visible: https://alex.envs.net/test/scroll-theme-mod1.png If someone wants to try it, here is a patch which also includes some commented lines which you can use to further customize the appearance of the scrollbar. -Alex --- a/dw/fltkviewport.cc Sat Oct 12 22:05:30 2024 +++ b/dw/fltkviewport.cc Sun Oct 13 16:23:06 2024 @@ -59,12 +59,20 @@ FltkViewport::FltkViewport (int X, int Y, int W, int H hscrollbar = new CustScrollbar (x (), y (), 1, 1); hscrollbar->type(FL_HORIZONTAL); + // Horizontal scrollbar theme options: + // hscrollbar->color(FL_BLUE, FL_YELLOW); + // hscrollbar->box(FL_ENGRAVED_BOX); + hscrollbar->slider(FL_PLASTIC_DOWN_BOX); hscrollbar->callback (hscrollbarCallback, this); hscrollbar->hide(); add (hscrollbar); vscrollbar = new Fl_Scrollbar (x (), y(), 1, 1); vscrollbar->type(FL_VERTICAL); + // Vertical scrollbar theme options: + // vscrollbar->color(FL_BLUE, FL_YELLOW); + // vscrollbar->box(FL_ENGRAVED_BOX); + vscrollbar->slider(FL_PLASTIC_DOWN_BOX); vscrollbar->callback (vscrollbarCallback, this); vscrollbar->hide(); add (vscrollbar);

Oct. 13, 2024

Re: Navigation by pages

by a1ex＠dismail.de

Hi, > First, you can now scroll the mouse wheel over the vertical scrollbar > to jump whole pages instead of small steps. Over the page it > continues to behave as normal, unless you hold Shift, which will also > make it navigate full pages. This works really great, thanks! > Secondly, I also added a scrollbar "page mode", which can be enabled > in dillorc with scrollbar_page_mode=YES, which causes clicking with > the left button *anywhere* on the vertical scrollbar (including the > thumb) to scroll one page down. With the right button, one up. > Holding Shift can also enable temporarily this mode (or disable it). Another good feature, very useful if using a laptop or mouse without a proper scrollwheel. > I also added an option to place the vertical scrollbar on the left, > which I'm finding more convenient as it is usually closer to the text. Nice, this will probably become my default setting now. Thanks for this awesome patch! -Alex

Oct. 12, 2024

Re: Navigation by pages

by Rodrigo Arias

Hi, >Now having tried both, I feel that the button is still a bit nicer from >a usability standpoint, because it requires less attention and mouse >movement to go up and down. But, I agree there is not much point in >duplicating this functionality. I added a couple of options to improve the page navigation. First, you can now scroll the mouse wheel over the vertical scrollbar to jump whole pages instead of small steps. Over the page it continues to behave as normal, unless you hold Shift, which will also make it navigate full pages. Secondly, I also added a scrollbar "page mode", which can be enabled in dillorc with scrollbar_page_mode=YES, which causes clicking with the left button *anywhere* on the vertical scrollbar (including the thumb) to scroll one page down. With the right button, one up. Holding Shift can also enable temporarily this mode (or disable it). I also added an option to place the vertical scrollbar on the left, which I'm finding more convenient as it is usually closer to the text. Here is the PR that includes all the above, not merged yet: https://github.com/dillo-browser/dillo/pull/274 Best, Rodrigo.

Oct. 12, 2024

Re: Rendering issue with view source and large embedded images

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > Place a breakpoint here: > > https://github.com/dillo-browser/dillo/blob/master/src/IO/IO.c#L189 > > Likely with "b IO.c:189", then "c" and "bt". > > That backtrace along with the stderr lines: > > >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 > >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 > > Can tell what is the state of the CCC at the moment that error > happens. > > The backtrace you attach happens later, so we already miss the point > where the problem occurs. I built and installed a clean Dillo with your file dpi patch. Here is that backtrace, which is from right before this: "WRITE Failed with -1: Broken pipe" [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 a_IO_ccc : OpSend [2F] Info=0xb5c0c2eba40 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xb5c0c30d000 Flags=0 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 a_Capi_ccc : OpSend [2F] Info=0xb5c0c30de00 Flags=0 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 a_IO_ccc : OpSend [2F] Info=0xb5c0c2eba40 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xb5c0c30d000 Flags=0 a_Capi_ccc : OpSend [2F] Info=0xb5c0c30de00 Flags=0 a_IO_ccc : OpEnd [2F] Info=0xb5c0c2eba40 Flags=0 a_Dpi_ccc : OpEnd [2F] Info=0xb5c0c30d000 Flags=0 a_Capi_ccc : OpEnd [2F] Info=0xb5c0c30de00 Flags=0 HTTP warning: Content-Length (937694) does NOT match message body (921310) for file:/tmp/dillo-doublefree.html a_Capi_ccc : OpEnd [1B] Info=0xb5c0c30d3c0 Flags=0 a_Dpi_ccc : OpEnd [1B] Info=0xb5c0c30d0c0 Flags=0 a_IO_ccc : OpEnd [1B] Info=0xb5c4883b140 Flags=0 Program received signal SIGPIPE, Broken pipe. _thread_sys_write () at /tmp/-:2 2 /tmp/-: No such file or directory. (gdb) bt #0 _thread_sys_write () at /tmp/-:2 #1 0x0ea252bb530f97da in ?? () #2 0x00000b5c41b50c52 in _libc_write_cancel (fd=7, buf=0xb5be6ed0000, nbytes=72966) at /usr/src/lib/libc/sys/w_write.c:27 #3 0x00000b597324b065 in IO_write (io=0xb5c48870ba0) at IO.c:230 #4 IO_callback (io=0xb5c48870ba0) at IO.c:275 #5 0x00000b597324adc9 in IO_fd_write_cb (fd=7, data=<optimized out>) at IO.c:317 #6 0x00000b5c1e858e88 in fl_wait(double) () from /usr/local/lib/libfltk.so.8.0 #7 0x00000b5c1e7e8a6e in Fl::wait(double) () from /usr/local/lib/libfltk.so.8.0 #8 0x00000b5c1e7e8c4d in Fl::run() () from /usr/local/lib/libfltk.so.8.0 #9 0x00000b59731f23b5 in main () (gdb) c Continuing. WRITE Failed with -1: Broken pipe a_IO_ccc : OpAbort [1F] Info=0xb5c4886d440 Flags=0 a_Dpi_ccc : OpAbort [1F] Info=0xb5c4886d180 Flags=0 a_Capi_ccc : OpAbort [1F] Info=0xb5c4883ba00 Flags=0 Here is another: a_Capi_ccc : OpStart [2B] Info=0xb5c0c2eba80 Flags=0 a_Dpi_ccc : OpStart [2B] Info=0xb5c48368640 Flags=0 a_IO_ccc : OpStart [2B] Info=0xb5c4886d400 Flags=0 a_Capi_ccc : OpStart [1B] Info=0xb5c4883b0c0 Flags=0 a_Dpi_ccc : OpStart [1B] Info=0xb5bc9415100 Flags=0 a_IO_ccc : OpStart [1B] Info=0xb5c483686c0 Flags=0 a_IO_ccc : OpSend [1B] Info=0xb5c483686c0 Flags=0 a_Capi_ccc : OpSend [1F] Info=0xb5c4883b0c0 Flags=0 a_Capi_ccc : OpSend [2B] Info=0xb5c0c2eba80 Flags=0 a_Dpi_ccc : OpSend [2B] Info=0xb5c48368640 Flags=0 a_IO_ccc : OpSend [2B] Info=0xb5c4886d400 Flags=0 a_Capi_ccc : OpSend [1F] Info=0xb5c4883b0c0 Flags=0 a_Capi_ccc : OpSend [1B] Info=0xb5c4883b0c0 Flags=0 a_Dpi_ccc : OpSend [1B] Info=0xb5bc9415100 Flags=0 a_IO_ccc : OpSend [1B] Info=0xb5c483686c0 Flags=0 [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 a_IO_ccc : OpSend [2F] Info=0xb5c4886d940 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xb5c4886d9c0 Flags=0 a_Capi_ccc : OpSend [2F] Info=0xb5c0c30d980 Flags=0 [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 a_IO_ccc : OpSend [2F] Info=0xb5c4886d940 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xb5c4886d9c0 Flags=0 a_Capi_ccc : OpSend [2F] Info=0xb5c0c30d980 Flags=0 [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 Breakpoint 1, IO_read (io=0xb5c08fc3640) at IO.c:189 189 MSG("READ Failed with %d: %s\n", (int)St, strerror(errno)); (gdb) [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 bt #0 IO_read (io=0xb5c08fc3640) at IO.c:189 #1 IO_callback (io=0xb5c08fc3640) at IO.c:273 #2 0x00000b597324acc9 in IO_fd_read_cb (fd=7, data=0x51) at IO.c:294 #3 0x00000b5c1e858e88 in fl_wait(double) () from /usr/local/lib/libfltk.so.8.0 #4 0x00000b5c1e7e8a6e in Fl::wait(double) () from /usr/local/lib/libfltk.so.8.0 #5 0x00000b5c1e7e8c4d in Fl::run() () from /usr/local/lib/libfltk.so.8.0 #6 0x00000b59731f23b5 in main () (gdb) [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 (gdb) c Continuing. READ Failed with -1: Connection reset by peer a_IO_ccc : OpAbort [2F] Info=0xb5c4886d180 Flags=0 a_Dpi_ccc : OpAbort [2F] Info=0xb5c0c2eb880 Flags=0 ** WARNING **: Unused CCC Program received signal SIGPIPE, Broken pipe. _thread_sys_write () at /tmp/-:2 2 /tmp/-: No such file or directory. > This line: > > > READ Failed with -1: Connection reset by peer > > Is complaining that either a read() call or a Tls_read() failed. I > will assume it is the read() as there shouldn't be any https traffic > in your local test. It is communicating with the file DPI via a > socket. Thats interesting, in my previous testing a few days ago I noticed some messages about 'a_Tls_connection' in the debugger, which made no sense since I'm working with a local file: (gdb) break IO_write Breakpoint 1 at 0x9c0c8fc2fff: file IO.c, line 223. (gdb) c Continuing. WRITE Failed with -1: Broken pipe a_IO_ccc : OpAbort [1F] Info=0x9c335b28580 Flags=0 a_Dpi_ccc : OpAbort [1F] Info=0x9c335b00c40 Flags=0 a_Capi_ccc : OpAbort [1F] Info=0x9c335b00c00 Flags=0 Breakpoint 1, IO_write (io=0x9c38396eb40) at IO.c:223 223 void *conn = a_Tls_connection(io->FD); Regards, Alex

Oct. 12, 2024

Re: Rendering issue with view source and large embedded images

by Rodrigo Arias

Hi, >I managed to get the newer FLTK working and built Dillo with it, but >unfortunately it doesn't fix the view-source glitch or the image >rendering problem. I assume that could happen if the CCC is broken while transferring the images, then the decoder starts to hallucinate colors. Valgrind may be able to detect where the corruption begins. >I'm not exactly sure how to set the breakpoint for that specific event, >but I managed to get a more detailed backtrace which might be useful >(see attached). Place a breakpoint here: https://github.com/dillo-browser/dillo/blob/master/src/IO/IO.c#L189 Likely with "b IO.c:189", then "c" and "bt". That backtrace along with the stderr lines: >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 Can tell what is the state of the CCC at the moment that error happens. The backtrace you attach happens later, so we already miss the point where the problem occurs. This line: > READ Failed with -1: Connection reset by peer Is complaining that either a read() call or a Tls_read() failed. I will assume it is the read() as there shouldn't be any https traffic in your local test. It is communicating with the file DPI via a socket. However, in your log it seems that it is opening three CCC links: a_IO_ccc : OpStart [1B] Info=0xebe57007340 Flags=0 a_IO_ccc : OpStart [2B] Info=0xebeef295240 Flags=0 a_IO_ccc : OpStart [2B] Info=0xebeef2be980 Flags=0 a_IO_ccc : OpStart [1B] Info=0xebee90ace40 Flags=0 a_IO_ccc : OpStart [2B] Info=0xebe57007e40 Flags=0 a_IO_ccc : OpStart [1B] Info=0xebe57007100 Flags=0 The 1B and 2B is explained in devdoc/CCCwork.txt: Query: | . 1B --> 1B 1B --> 1B --> | -------------. .----. .----. .----. . | I |Capi| |http| | IO | | | '----' '----' '----' . | 1F <-- 1F 1F <-- 1F | V . | [Server] Answer: . 2B --> 2B 2B --> 2B | | .----. .----. .----. . | II |Capi| |Dpi | | IO | | | '----' '----' '----' . | 2F <-- 2F 2F <-- 2F <-- | <------------' ^ . fails here | But in my cases, I'm not able to have multiple CCC started before the previous one aborts, even if I reload all the time. If that is the case, then maybe even Valgrind won't be able to show you where the problem starts. This will probably require some "properly placed printf() calls" debugging. You may use this patch to enable some verbose messages on the file DPI to gather more info: diff --git a/dpi/file.c b/dpi/file.c index ecee90ea..1b67fab7 100644 --- a/dpi/file.c +++ b/dpi/file.c @@ -936,8 +936,8 @@ static void File_serve_client(void *data, int f_write) int st; while (1) { - _MSG("File_serve_client %p, flags=%d state=%d\n", - client, client->flags, client->state); + MSG("File_serve_client %p, flags=%d state=%d\n", + (void *) client, client->flags, client->state); if (client->flags & (FILE_DONE | FILE_ERR)) break; if (client->flags & FILE_READ) { Then: $ make clean $ make $ sudo make install $ dpidc stop >Speaking of weird errors, here is some glitch-art I made with Dillo, >which introduces corruption into the data stream, resulting in >some interesting jpeg artifacts: > >The original image: >https://alex.envs.net/test/dillo-test1.png > >Glitched: >https://alex.envs.net/test/dillo-glitch-comp1.png >https://alex.envs.net/test/dillo-glitch-comp2.png >https://alex.envs.net/test/dillo-glitch-comp3.png Nice ones! Best, Rodrigo.

Oct. 11, 2024

Re: Rendering issue with view source and large embedded images

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Tue, Oct 08, 2024 at 10:55:37PM +0200, a1ex(a)dismail.de wrote: > >Hi, > > > >Rodrigo Arias <rodarima(a)gmail.com> wrote: > > > >> >$ fltk-config --version > >> >1.3.3 > >> > >> I suspect the glich may be related to this old FLTK version. Can > >> you reproduce the bug with the last FLTK 1.3.9 release? You may > >> need to install it from source. > > > >Just tried, but getting some linker errors building Dillo with it. > >Would probably need some patches to make that version work on > >OpenBSD, maybe thats why they are still stuck on an older version of > >FLTK. I managed to get the newer FLTK working and built Dillo with it, but unfortunately it doesn't fix the view-source glitch or the image rendering problem. > >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 > >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 > >READ Failed with -1: Connection reset by peer > > Can you place a breakpoint in GDB here and print the backtrace (bt)? > It may be interesting to see how we arrive at this reset error. I'm not exactly sure how to set the breakpoint for that specific event, but I managed to get a more detailed backtrace which might be useful (see attached). > With a corrupted heap you will see all kind of weird errors. Use > Valgrind to get an idea of where things start to go wrong. Thanks, I will try to give Valgrind a shot soon. Speaking of weird errors, here is some glitch-art I made with Dillo, which introduces corruption into the data stream, resulting in some interesting jpeg artifacts: The original image: https://alex.envs.net/test/dillo-test1.png Glitched: https://alex.envs.net/test/dillo-glitch-comp1.png https://alex.envs.net/test/dillo-glitch-comp2.png https://alex.envs.net/test/dillo-glitch-comp3.png Regards, Alex

Oct. 9, 2024

Re: Rendering issue with view source and large embedded images

by Rodrigo Arias

Hi, On Tue, Oct 08, 2024 at 10:55:37PM +0200, a1ex(a)dismail.de wrote: >Hi, > >Rodrigo Arias <rodarima(a)gmail.com> wrote: > >> >$ fltk-config --version >> >1.3.3 >> >> I suspect the glich may be related to this old FLTK version. Can you >> reproduce the bug with the last FLTK 1.3.9 release? You may need to >> install it from source. > >Just tried, but getting some linker errors building Dillo with it. >Would probably need some patches to make that version work on OpenBSD, >maybe thats why they are still stuck on an older version of FLTK. > >ld: error: undefined symbol: Fl_Display_Device::display_device() >>>> referenced by fltkviewbase.cc >>>> libDw_fltk_a-fltkviewbase.o:(dw::fltk::FltkViewBase::draw(dw::core::Rectangle >>>> const*, dw::fltk::FltkViewBase::DrawType)) in archive >>>> ../dw/libDw-fltk.a > >... Is it possible you have two FLTK versions and it is picking one for the headers and the other at link time? If so, the easiest way is to remove the old version temporarily. I ran into similar problems when I was testing FLTK 1.4: https://github.com/dillo-browser/dillo/issues/258 >> >I now noticed that this page also makes Dillo segfault when I reload >> >it several times: >> >> I think this is a different bug. Still, I cannot reproduce either. >> >> You can try setting VERBOSE to 1 in src/chain.c and rebuilding Dillo. >> That will give you some details of the CCC operations. It seems it is >> trying to abort the client 1 when it was already gone. > >Here is the output of a crash with that set: > >Nav_open_url: new url='file:/tmp/dillo-doublefree.html' >a_Capi_ccc : OpStart [2B] Info=0xebee90cbd00 Flags=0 >a_Dpi_ccc : OpStart [2B] Info=0xebed4db4980 Flags=0 >a_IO_ccc : OpStart [2B] Info=0xebeef295240 Flags=0 >a_Capi_ccc : OpStart [1B] Info=0xebee90ac240 Flags=0 >a_Dpi_ccc : OpStart [1B] Info=0xebee90d20c0 Flags=0 >a_IO_ccc : OpStart [1B] Info=0xebe57007340 Flags=0 >a_IO_ccc : OpSend [1B] Info=0xebe57007340 Flags=0 >a_Capi_ccc : OpSend [1F] Info=0xebee90ac240 Flags=0 >a_Capi_ccc : OpSend [2B] Info=0xebee90cbd00 Flags=0 >a_Dpi_ccc : OpSend [2B] Info=0xebed4db4980 Flags=0 >a_IO_ccc : OpSend [2B] Info=0xebeef295240 Flags=0 >a_Capi_ccc : OpSend [1F] Info=0xebee90ac240 Flags=0 >a_Capi_ccc : OpSend [1B] Info=0xebee90ac240 Flags=0 >a_Dpi_ccc : OpSend [1B] Info=0xebee90d20c0 Flags=0 >a_IO_ccc : OpSend [1B] Info=0xebe57007340 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 >a_Nav_expect_done: reload! >a_Capi_ccc : OpStart [2B] Info=0xebe57007d40 Flags=0 >a_Dpi_ccc : OpStart [2B] Info=0xebe57007b00 Flags=0 >a_IO_ccc : OpStart [2B] Info=0xebeef2be980 Flags=0 >a_Capi_ccc : OpStart [1B] Info=0xebee90ac440 Flags=0 >a_Dpi_ccc : OpStart [1B] Info=0xebee90ac1c0 Flags=0 >a_IO_ccc : OpStart [1B] Info=0xebee90ace40 Flags=0 >a_IO_ccc : OpSend [1B] Info=0xebee90ace40 Flags=0 >a_Capi_ccc : OpSend [1F] Info=0xebee90ac440 Flags=0 >a_Capi_ccc : OpSend [2B] Info=0xebe57007d40 Flags=0 >a_Dpi_ccc : OpSend [2B] Info=0xebe57007b00 Flags=0 >a_IO_ccc : OpSend [2B] Info=0xebeef2be980 Flags=0 >a_Capi_ccc : OpSend [1F] Info=0xebee90ac440 Flags=0 >a_Capi_ccc : OpSend [1B] Info=0xebee90ac440 Flags=0 >a_Dpi_ccc : OpSend [1B] Info=0xebee90ac1c0 Flags=0 >a_IO_ccc : OpSend [1B] Info=0xebee90ace40 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 >a_Capi_ccc : OpStart [2B] Info=0xebeef295c00 Flags=0 >a_Dpi_ccc : OpStart [2B] Info=0xebe57007380 Flags=0 >a_IO_ccc : OpStart [2B] Info=0xebe57007e40 Flags=0 >a_Capi_ccc : OpStart [1B] Info=0xebe570072c0 Flags=0 >a_Dpi_ccc : OpStart [1B] Info=0xebeef295080 Flags=0 >a_IO_ccc : OpStart [1B] Info=0xebe57007100 Flags=0 >a_IO_ccc : OpSend [1B] Info=0xebe57007100 Flags=0 >a_Capi_ccc : OpSend [1F] Info=0xebe570072c0 Flags=0 >a_Capi_ccc : OpSend [2B] Info=0xebeef295c00 Flags=0 >a_Dpi_ccc : OpSend [2B] Info=0xebe57007380 Flags=0 >a_IO_ccc : OpSend [2B] Info=0xebe57007e40 Flags=0 >a_Capi_ccc : OpSend [1F] Info=0xebe570072c0 Flags=0 >a_Capi_ccc : OpSend [1B] Info=0xebe570072c0 Flags=0 >a_Dpi_ccc : OpSend [1B] Info=0xebeef295080 Flags=0 >a_IO_ccc : OpSend [1B] Info=0xebe57007100 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 >READ Failed with -1: Connection reset by peer Can you place a breakpoint in GDB here and print the backtrace (bt)? It may be interesting to see how we arrive at this reset error. >a_IO_ccc : OpAbort [2F] Info=0xebeef2be980 Flags=0 >a_Dpi_ccc : OpAbort [2F] Info=0xebe57007b00 Flags=0 >** WARNING **: Unused CCC >READ Failed with -1: Connection reset by peer >a_IO_ccc : OpAbort [2F] Info=0xebe57007e40 Flags=0 >a_Dpi_ccc : OpAbort [2F] Info=0xebe57007380 Flags=0 >** WARNING **: Unused CCC >a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 >a_IO_ccc : OpEnd [2F] Info=0xebeef295240 Flags=0 >a_Dpi_ccc : OpEnd [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpEnd [2F] Info=0xebee90cbd00 Flags=0 >HTTP warning: Content-Length (937694) does NOT match message body >(921310) for file:/tmp/dillo-doublefree.html a_Capi_ccc : OpEnd [1B] >Info=0xebee90ac240 Flags=0 a_Dpi_ccc : OpEnd [1B] >Info=0xebee90d20c0 Flags=0 a_IO_ccc : OpEnd [1B] >Info=0xebe57007340 Flags=0 Nav_open_url: new >url='file:/tmp/dillo-doublefree.html' a_Capi_ccc : OpAbort [1B] >Info=0xebee90ac440 Flags=0 a_Dpi_ccc : OpAbort [1B] >Info=0xebee90ac1c0 Flags=0 a_IO_ccc : OpAbort [1B] >Info=0xebee90ace40 Flags=0 IO_write, closing with pending data not >sent: >"vUdPWpfEOj6lBo+kSy2FykcFntmZoyBGTK+AfTqPzrmKKAOrtNB1Z/B92i6bds8t1BJGoibLLsk5HqOR+dMhtdQv/ >... >a_Capi_ccc : OpAbort [2B] Info=0xebe57007d40 Flags=0 a_Dpi_ccc : >OpAbort [2B] Info=0xebe57007b00 Flags=0 a_IO_ccc : OpAbort [2B] >Info=0xebeef2be980 Flags=-282335104 dillo(19444) in free(): bogus >pointer (double free?) 0xffffffff00000003 Abort trap (core dumped) This is too late, here the heap is already fucked (see the flags). Try running with Valgrind's Memcheck tool and see where the first memory error happens: https://valgrind.org/docs/manual/quick-start.html You may need to rebuild Dillo with ../configure CFLAGS='-Og -g' CXXFLAGS='-Og -g' to see the backtrace properly. > >--- > >Also, when trying to view the source of the test page, I get this crash: > >Nav_open_url: new url='dpi:/vsource/:file:/tmp/dillo-doublefree.html' >a_Capi_ccc : OpStart [2B] Info=0xfabc093a700 Flags=0 >a_Dpi_ccc : OpStart [2B] Info=0xfac19738080 Flags=0 >a_IO_ccc : OpStart [2B] Info=0xfabc093a740 Flags=0 >a_Capi_ccc : OpStart [1B] Info=0xfac1973f380 Flags=0 >a_Dpi_ccc : OpStart [1B] Info=0xfac1973ff40 Flags=0 >a_IO_ccc : OpStart [1B] Info=0xfabc093a780 Flags=0 >a_IO_ccc : OpSend [1B] Info=0xfabc093a780 Flags=0 >a_Capi_ccc : OpSend [1F] Info=0xfac1973f380 Flags=0 >a_Capi_ccc : OpSend [2B] Info=0xfabc093a700 Flags=0 >a_Dpi_ccc : OpSend [2B] Info=0xfac19738080 Flags=0 >a_IO_ccc : OpSend [2B] Info=0xfabc093a740 Flags=0 >a_Capi_ccc : OpSend [1F] Info=0xfac1973f380 Flags=0 >a_Capi_ccc : OpSend [1B] Info=0xfac1973f380 Flags=0 >a_Dpi_ccc : OpSend [1B] Info=0xfac1973ff40 Flags=0 >a_IO_ccc : OpSend [1B] Info=0xfabc093a780 Flags=0 >a_Capi_ccc : OpSend [1B] Info=0xfac1973f380 Flags=0 >a_Dpi_ccc : OpSend [1B] Info=0xfac1973ff40 Flags=0 >a_IO_ccc : OpSend [1B] Info=0xfabc093a780 Flags=0 >a_Capi_ccc : OpSend [1B] Info=0xfac1973f380 Flags=0 >a_Dpi_ccc : OpSend [1B] Info=0xfac1973ff40 Flags=0 >a_IO_ccc : OpSend [1B] Info=0xfabc093a780 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xfabc093a740 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xfac19738080 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xfabc093a700 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xfabc093a700 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xfabc093a740 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xfac19738080 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xfabc093a700 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xfabc093a740 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xfac19738080 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xfabc093a700 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xfabc093a740 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xfac19738080 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xfabc093a700 Flags=0 >XRequest.139: BadLength (poly request too large or internal Xlib length >error) 0x2800006 [xcb] Unknown sequence number while processing queue >[xcb] You called XInitThreads, this is not your fault >[xcb] Aborting, sorry about that. >assertion "!xcb_xlib_threads_sequence_lost" failed: file >"/usr/xenocara/lib/libX11/src/xcb_io.c", line 281, function >"poll_for_event" [dpip]: [Dpip_dsh_write] Broken pipe [dpip]: >[Dpip_dsh_write] Broken pipe [dpip]: [Dpip_dsh_write] Broken pipe >Abort trap (core dumped) With a corrupted heap you will see all kind of weird errors. Use Valgrind to get an idea of where things start to go wrong. Best, Rodrigo.

Oct. 8, 2024

Re: Rendering issue with view source and large embedded images

by a1ex＠dismail.de

Hi, Rodrigo Arias <rodarima(a)gmail.com> wrote: > >$ fltk-config --version > >1.3.3 > > I suspect the glich may be related to this old FLTK version. Can you > reproduce the bug with the last FLTK 1.3.9 release? You may need to > install it from source. Just tried, but getting some linker errors building Dillo with it. Would probably need some patches to make that version work on OpenBSD, maybe thats why they are still stuck on an older version of FLTK. ld: error: undefined symbol: Fl_Display_Device::display_device() >>> referenced by fltkviewbase.cc >>> libDw_fltk_a-fltkviewbase.o:(dw::fltk::FltkViewBase::draw(dw::core::Rectangle >>> const*, dw::fltk::FltkViewBase::DrawType)) in archive >>> ../dw/libDw-fltk.a ... > >I now noticed that this page also makes Dillo segfault when I reload > >it several times: > > I think this is a different bug. Still, I cannot reproduce either. > > You can try setting VERBOSE to 1 in src/chain.c and rebuilding Dillo. > That will give you some details of the CCC operations. It seems it is > trying to abort the client 1 when it was already gone. Here is the output of a crash with that set: Nav_open_url: new url='file:/tmp/dillo-doublefree.html' a_Capi_ccc : OpStart [2B] Info=0xebee90cbd00 Flags=0 a_Dpi_ccc : OpStart [2B] Info=0xebed4db4980 Flags=0 a_IO_ccc : OpStart [2B] Info=0xebeef295240 Flags=0 a_Capi_ccc : OpStart [1B] Info=0xebee90ac240 Flags=0 a_Dpi_ccc : OpStart [1B] Info=0xebee90d20c0 Flags=0 a_IO_ccc : OpStart [1B] Info=0xebe57007340 Flags=0 a_IO_ccc : OpSend [1B] Info=0xebe57007340 Flags=0 a_Capi_ccc : OpSend [1F] Info=0xebee90ac240 Flags=0 a_Capi_ccc : OpSend [2B] Info=0xebee90cbd00 Flags=0 a_Dpi_ccc : OpSend [2B] Info=0xebed4db4980 Flags=0 a_IO_ccc : OpSend [2B] Info=0xebeef295240 Flags=0 a_Capi_ccc : OpSend [1F] Info=0xebee90ac240 Flags=0 a_Capi_ccc : OpSend [1B] Info=0xebee90ac240 Flags=0 a_Dpi_ccc : OpSend [1B] Info=0xebee90d20c0 Flags=0 a_IO_ccc : OpSend [1B] Info=0xebe57007340 Flags=0 a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 a_Nav_expect_done: reload! a_Capi_ccc : OpStart [2B] Info=0xebe57007d40 Flags=0 a_Dpi_ccc : OpStart [2B] Info=0xebe57007b00 Flags=0 a_IO_ccc : OpStart [2B] Info=0xebeef2be980 Flags=0 a_Capi_ccc : OpStart [1B] Info=0xebee90ac440 Flags=0 a_Dpi_ccc : OpStart [1B] Info=0xebee90ac1c0 Flags=0 a_IO_ccc : OpStart [1B] Info=0xebee90ace40 Flags=0 a_IO_ccc : OpSend [1B] Info=0xebee90ace40 Flags=0 a_Capi_ccc : OpSend [1F] Info=0xebee90ac440 Flags=0 a_Capi_ccc : OpSend [2B] Info=0xebe57007d40 Flags=0 a_Dpi_ccc : OpSend [2B] Info=0xebe57007b00 Flags=0 a_IO_ccc : OpSend [2B] Info=0xebeef2be980 Flags=0 a_Capi_ccc : OpSend [1F] Info=0xebee90ac440 Flags=0 a_Capi_ccc : OpSend [1B] Info=0xebee90ac440 Flags=0 a_Dpi_ccc : OpSend [1B] Info=0xebee90ac1c0 Flags=0 a_IO_ccc : OpSend [1B] Info=0xebee90ace40 Flags=0 a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 a_Capi_ccc : OpStart [2B] Info=0xebeef295c00 Flags=0 a_Dpi_ccc : OpStart [2B] Info=0xebe57007380 Flags=0 a_IO_ccc : OpStart [2B] Info=0xebe57007e40 Flags=0 a_Capi_ccc : OpStart [1B] Info=0xebe570072c0 Flags=0 a_Dpi_ccc : OpStart [1B] Info=0xebeef295080 Flags=0 a_IO_ccc : OpStart [1B] Info=0xebe57007100 Flags=0 a_IO_ccc : OpSend [1B] Info=0xebe57007100 Flags=0 a_Capi_ccc : OpSend [1F] Info=0xebe570072c0 Flags=0 a_Capi_ccc : OpSend [2B] Info=0xebeef295c00 Flags=0 a_Dpi_ccc : OpSend [2B] Info=0xebe57007380 Flags=0 a_IO_ccc : OpSend [2B] Info=0xebe57007e40 Flags=0 a_Capi_ccc : OpSend [1F] Info=0xebe570072c0 Flags=0 a_Capi_ccc : OpSend [1B] Info=0xebe570072c0 Flags=0 a_Dpi_ccc : OpSend [1B] Info=0xebeef295080 Flags=0 a_IO_ccc : OpSend [1B] Info=0xebe57007100 Flags=0 a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 READ Failed with -1: Connection reset by peer a_IO_ccc : OpAbort [2F] Info=0xebeef2be980 Flags=0 a_Dpi_ccc : OpAbort [2F] Info=0xebe57007b00 Flags=0 ** WARNING **: Unused CCC READ Failed with -1: Connection reset by peer a_IO_ccc : OpAbort [2F] Info=0xebe57007e40 Flags=0 a_Dpi_ccc : OpAbort [2F] Info=0xebe57007380 Flags=0 ** WARNING **: Unused CCC a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 a_IO_ccc : OpEnd [2F] Info=0xebeef295240 Flags=0 a_Dpi_ccc : OpEnd [2F] Info=0xebed4db4980 Flags=0 a_Capi_ccc : OpEnd [2F] Info=0xebee90cbd00 Flags=0 HTTP warning: Content-Length (937694) does NOT match message body (921310) for file:/tmp/dillo-doublefree.html a_Capi_ccc : OpEnd [1B] Info=0xebee90ac240 Flags=0 a_Dpi_ccc : OpEnd [1B] Info=0xebee90d20c0 Flags=0 a_IO_ccc : OpEnd [1B] Info=0xebe57007340 Flags=0 Nav_open_url: new url='file:/tmp/dillo-doublefree.html' a_Capi_ccc : OpAbort [1B] Info=0xebee90ac440 Flags=0 a_Dpi_ccc : OpAbort [1B] Info=0xebee90ac1c0 Flags=0 a_IO_ccc : OpAbort [1B] Info=0xebee90ace40 Flags=0 IO_write, closing with pending data not sent: "vUdPWpfEOj6lBo+kSy2FykcFntmZoyBGTK+AfTqPzrmKKAOrtNB1Z/B92i6bds8t1BJGoibLLsk5HqOR+dMhtdQv/ ... a_Capi_ccc : OpAbort [2B] Info=0xebe57007d40 Flags=0 a_Dpi_ccc : OpAbort [2B] Info=0xebe57007b00 Flags=0 a_IO_ccc : OpAbort [2B] Info=0xebeef2be980 Flags=-282335104 dillo(19444) in free(): bogus pointer (double free?) 0xffffffff00000003 Abort trap (core dumped) --- Also, when trying to view the source of the test page, I get this crash: Nav_open_url: new url='dpi:/vsource/:file:/tmp/dillo-doublefree.html' a_Capi_ccc : OpStart [2B] Info=0xfabc093a700 Flags=0 a_Dpi_ccc : OpStart [2B] Info=0xfac19738080 Flags=0 a_IO_ccc : OpStart [2B] Info=0xfabc093a740 Flags=0 a_Capi_ccc : OpStart [1B] Info=0xfac1973f380 Flags=0 a_Dpi_ccc : OpStart [1B] Info=0xfac1973ff40 Flags=0 a_IO_ccc : OpStart [1B] Info=0xfabc093a780 Flags=0 a_IO_ccc : OpSend [1B] Info=0xfabc093a780 Flags=0 a_Capi_ccc : OpSend [1F] Info=0xfac1973f380 Flags=0 a_Capi_ccc : OpSend [2B] Info=0xfabc093a700 Flags=0 a_Dpi_ccc : OpSend [2B] Info=0xfac19738080 Flags=0 a_IO_ccc : OpSend [2B] Info=0xfabc093a740 Flags=0 a_Capi_ccc : OpSend [1F] Info=0xfac1973f380 Flags=0 a_Capi_ccc : OpSend [1B] Info=0xfac1973f380 Flags=0 a_Dpi_ccc : OpSend [1B] Info=0xfac1973ff40 Flags=0 a_IO_ccc : OpSend [1B] Info=0xfabc093a780 Flags=0 a_Capi_ccc : OpSend [1B] Info=0xfac1973f380 Flags=0 a_Dpi_ccc : OpSend [1B] Info=0xfac1973ff40 Flags=0 a_IO_ccc : OpSend [1B] Info=0xfabc093a780 Flags=0 a_Capi_ccc : OpSend [1B] Info=0xfac1973f380 Flags=0 a_Dpi_ccc : OpSend [1B] Info=0xfac1973ff40 Flags=0 a_IO_ccc : OpSend [1B] Info=0xfabc093a780 Flags=0 a_IO_ccc : OpSend [2F] Info=0xfabc093a740 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xfac19738080 Flags=0 a_Capi_ccc : OpSend [2F] Info=0xfabc093a700 Flags=0 a_Capi_ccc : OpSend [2F] Info=0xfabc093a700 Flags=0 a_IO_ccc : OpSend [2F] Info=0xfabc093a740 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xfac19738080 Flags=0 a_Capi_ccc : OpSend [2F] Info=0xfabc093a700 Flags=0 a_IO_ccc : OpSend [2F] Info=0xfabc093a740 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xfac19738080 Flags=0 a_Capi_ccc : OpSend [2F] Info=0xfabc093a700 Flags=0 a_IO_ccc : OpSend [2F] Info=0xfabc093a740 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xfac19738080 Flags=0 a_Capi_ccc : OpSend [2F] Info=0xfabc093a700 Flags=0 XRequest.139: BadLength (poly request too large or internal Xlib length error) 0x2800006 [xcb] Unknown sequence number while processing queue [xcb] You called XInitThreads, this is not your fault [xcb] Aborting, sorry about that. assertion "!xcb_xlib_threads_sequence_lost" failed: file "/usr/xenocara/lib/libX11/src/xcb_io.c", line 281, function "poll_for_event" [dpip]: [Dpip_dsh_write] Broken pipe [dpip]: [Dpip_dsh_write] Broken pipe [dpip]: [Dpip_dsh_write] Broken pipe Abort trap (core dumped) -Alex

Oct. 8, 2024

Re: Rendering issue with view source and large embedded images

by Rodrigo Arias

Hi, >Yeah, it seems to happen every time the same. > >$ fltk-config --version >1.3.3 I suspect the glich may be related to this old FLTK version. Can you reproduce the bug with the last FLTK 1.3.9 release? You may need to install it from source. >I saved the above page to a local file, and am using that for testing. > >I now noticed that this page also makes Dillo segfault when I reload it >several times: I think this is a different bug. Still, I cannot reproduce either. You can try setting VERBOSE to 1 in src/chain.c and rebuilding Dillo. That will give you some details of the CCC operations. It seems it is trying to abort the client 1 when it was already gone. >** WARNING **: CCC: call on already finished chain. Flags=CCC_Ended This is not good^ >CCC_Aborted a_Nav_expect_done: reload! >READ Failed with -1: Connection reset by peer >** WARNING **: Unused CCC >... Best, Rodrigo.

Oct. 8, 2024

Re: Rendering issue with view source and large embedded images

by a1ex＠dismail.de

> I now noticed that this page also makes Dillo segfault when I reload > it several times: Sorry maybe I should be more clear. This is when I reload the actual page, not the vsource.

Oct. 8, 2024

Re: Rendering issue with view source and large embedded images

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > >This is an example of a page which uses large embedded jpegs: > >https://www.da.vidbuchanan.co.uk/blog/dram-emfi.html > >When you view the source in Dillo, the issue should be evident. > > I cannot reproduce this (attached). Does it always happens to you? > Which FLTK version are you on? Yeah, it seems to happen every time the same. $ fltk-config --version 1.3.3 I saved the above page to a local file, and am using that for testing. I now noticed that this page also makes Dillo segfault when I reload it several times: ** WARNING **: CCC: call on already finished chain. Flags=CCC_Ended CCC_Aborted a_Nav_expect_done: reload! READ Failed with -1: Connection reset by peer ** WARNING **: Unused CCC WRITE Failed with -1: Connection reset by peer ** WARNING **: Maximum number of classes per element exceeded. ** WARNING **: Maximum number of classes per element exceeded. ** WARNING **: Maximum number of classes per element exceeded. ** WARNING **: Maximum number of classes per element exceeded. ** WARNING **: Maximum number of classes per element exceeded. HTTP warning: Content-Length (657000) does NOT match message body (640616) for file:/tmp/dillo-vsource-overflow.html WRITE Failed with -1: Broken pipe Nav_open_url: new url='file:/tmp/dillo-vsource-overflow.html' dillo(27095) in free(): double free 0x4f5cf02b980 Abort trap (core dumped) EXIT: 134 backtrace: #0 thrkill () at /tmp/-:2 No locals. #1 0x3d7553619f488131 in ?? () No symbol table info available. #2 0x000003f2234105ab in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51 sa = {__sigaction_u = {__sa_handler = 0x3000000010, __sa_sigaction = 0x3000000010}, sa_mask = 1035724304, sa_flags = 30747} mask = 4294967263 #3 0x000003f2233df3e4 in wrterror (d=0x3f23a5428f8, msg=0x3f223341697 "double free %p") at /usr/src/lib/libc/stdlib/malloc.c:378 ap = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = 0x781b3dbbe710, reg_save_area = 0x781b3dbbe610}} saved_errno = 9 #4 0x000003f2233e0f09 in ofree (argpool=<optimized out>, p=<optimized out>, clear=<optimized out>, check=<optimized out>, argsz=<optimized out>out>) at /usr/src/lib/libc/stdlib/malloc.c:1690 pool = 0x3f23a5428f8 saved_function = 0xb86fc82ea4cf34f8 <error: Cannot access memory at address 0xb86fc82ea4cf34f8> r = <optimized out> sz = <optimized out> #5 0x000003f2233e0633 in _libc_free (ptr=0x3f192293480) at /usr/src/lib/libc/stdlib/malloc.c:1747 saved_errno = 9 d = 0x3f23a5428f8 #6 0x000003ef75793a5b in a_Chain_bcb (Op=0, Info=<optimized out>, Data1=0x781b3dbbe460, Data2=0x0) at chain.c:139 ret = <error reading variable ret (Cannot access memory at address 0x0)> #7 0x000003ef757d967b in a_Dpi_ccc (Op=5, Branch=2, Dir=2, Info=0x3f1a76eef40, Data1=<optimized out>, Data2=0x0) at dpi.c:745 SockFD = <error reading variable SockFD (Cannot access memory at address 0xffffffffffffffff)> conn = <optimized out> st = <optimized out> #8 0x000003ef75793a5b in a_Chain_bcb (Op=0, Info=<optimized out>, Data1=0x781b3dbbe460, Data2=0x0) at chain.c:139 ret = <error reading variable ret (Cannot access memory at address 0x0)> #9 0x000003ef7579acb3 in a_Capi_ccc (Op=<optimized out>, Branch=<optimized out>, Dir=<optimized out>, Info=<optimized out>, Data1=<optimized out>, Data2=<optimized out>) at capi.c:754 conn = 0x3f17c4a0240 dbuf = <optimized out> finished = <optimized out> #10 0x000003ef7579bea0 in a_Capi_stop_client (Key=6, force=4) at capi.c:630 Client = 0x0 #11 0x000003ef7578a91b in a_Bw_stop_clients (bw=0x3f1f1195280, flags=<optimized out>) at bw.c:197 data = 0x0 #12 0x000003ef757873cc in a_UIcmd_close_bw () No symbol table info available. #13 0x000003ef75787678 in a_UIcmd_close_all_bw () No symbol table info available. #14 0x000003f18adea990 in Fl::wait(double) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #15 0x000003f18adeac4d in Fl::run() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #16 0x000003ef75782365 in main () No symbol table info available. And here is a different one: [New process 402078] Core was generated by `dillo'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00000fcc9d2228e8 in IO_close_fd (io=0x43203a6f6c6c6944, CloseCode=<optimized out>) at IO.c:134 134 if ((CloseCode == IO_StopRdWr) && io->FD != -1) { (gdb) bt full #0 0x00000fcc9d2228e8 in IO_close_fd (io=0x43203a6f6c6c6944, CloseCode=<optimized out>) at IO.c:134 events = <error reading variable events (Cannot access memory at address 0x0)> #1 a_IO_ccc (Op=5, Branch=<optimized out>, Dir=2, Info=0xfcef07b3a80, Data1=<optimized out>, Data2=0x0) at IO.c:440 io = 0x43203a6f6c6c6944 dbuf = <optimized out> newline = <optimized out> msglen = <optimized out> #2 0x00000fcc9d1dba5b in a_Chain_bcb (Op=-1659262356, Info=<optimized out>, Data1=0xfcef07b3a80, Data2=0x0) at chain.c:139 ret = <error reading variable ret (Cannot access memory at address 0x0)> #3 0x00000fcc9d22167b in a_Dpi_ccc (Op=5, Branch=2, Dir=2, Info=0xfcef07b3480, Data1=<optimized out>, Data2=0x0) at dpi.c:745 SockFD = <error reading variable SockFD (Cannot access memory at address 0xffffffffffffffff)> conn = <optimized out> st = <optimized out> #4 0x00000fcc9d1dba5b in a_Chain_bcb (Op=-1659262356, Info=<optimized out>, Data1=0xfcef07b3a80, Data2=0x0) at chain.c:139 ret = <error reading variable ret (Cannot access memory at address 0x0)> #5 0x00000fcc9d1e2cb3 in a_Capi_ccc (Op=<optimized out>, Branch=<optimized out>, Dir=<optimized out>, Info=<optimized out>, Data1=<optimized out>, Data2=<optimized out>) at capi.c:754 conn = 0xfcef07bc180 dbuf = <optimized out> finished = <optimized out> #6 0x00000fcc9d1e3ea0 in a_Capi_stop_client (Key=2, force=4) at capi.c:630 Client = 0x1 #7 0x00000fcc9d1d291b in a_Bw_stop_clients (bw=0xfcf6f89ef80, flags=<optimized out>) at bw.c:197 data = 0x1 #8 0x00000fcc9d1cf3cc in a_UIcmd_close_bw () No symbol table info available. #9 0x00000fcc9d1d072f in win_cb(Fl_Widget*, void*) () No symbol table info available. #10 0x00000fcebc80351e in Fl_Widget::do_callback(Fl_Widget*, void*) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #11 0x00000fcebc79a23b in Fl::handle_(int, Fl_Window*) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #12 0x00000fcebc80c83b in fl_handle(_XEvent const&) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #13 0x00000fcebc808f40 in do_queued_events() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #14 0x00000fcebc808e88 in fl_wait(double) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #15 0x00000fcebc798a6e in Fl::wait(double) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #16 0x00000fcebc798c4d in Fl::run() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #17 0x00000fcc9d1ca365 in main () No symbol table info available. > Should not be related, but I notice that you are using the old DPI > for vsource, as I changed the style a while back. Have you done `make > install` and set the dpi_dir in ~/.dillo/dpidrc properly? I suspect > it may be picking up another install. Yeah, thats true I was using an older vsource dpi. But, I did a new clean install of everything and still see the issue. Maybe its OpenBSD related, or something else weird with my setup. I'm open to suggestions :) Regards, Alex

Oct. 8, 2024

Re: Rendering issue with view source and large embedded images

by Rodrigo Arias

Hi Alex, On Tue, Oct 08, 2024 at 12:01:38AM +0200, a1ex(a)dismail.de wrote: >Hi, > >There is a small rendering glitch when trying to view the source of a >page which has larger embedded data uri images. See attached screenshot. > >This is an example of a page which uses large embedded jpegs: >https://www.da.vidbuchanan.co.uk/blog/dram-emfi.html >When you view the source in Dillo, the issue should be evident. I cannot reproduce this (attached). Does it always happens to you? Which FLTK version are you on? Should not be related, but I notice that you are using the old DPI for vsource, as I changed the style a while back. Have you done `make install` and set the dpi_dir in ~/.dillo/dpidrc properly? I suspect it may be picking up another install. >Since the encoded image is just one super-long line in the html, the >vsource dpi probably isn't designed to handle that. > >I don't think its typical that a site will embed large images into the >page like this, but maybe its still worth considering. I see the case for the data: images patch now. Anyway, nice blog post. Best, Rodrigo.

Oct. 8, 2024

Rendering issue with view source and large embedded images

by a1ex＠dismail.de

Hi, There is a small rendering glitch when trying to view the source of a page which has larger embedded data uri images. See attached screenshot. This is an example of a page which uses large embedded jpegs: https://www.da.vidbuchanan.co.uk/blog/dram-emfi.html When you view the source in Dillo, the issue should be evident. Since the encoded image is just one super-long line in the html, the vsource dpi probably isn't designed to handle that. I don't think its typical that a site will embed large images into the page like this, but maybe its still worth considering. Regards, Alex

Oct. 7, 2024

Re: Navigation by pages

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > You can do this by clicking on the scroll bar, above and below the > "thumb". > > https://dillo-browser.github.io/user_help.html#scrolling > > Does that work for you? Thanks, somehow I have been ignorant of that feature for all these years. :) Now having tried both, I feel that the button is still a bit nicer from a usability standpoint, because it requires less attention and mouse movement to go up and down. But, I agree there is not much point in duplicating this functionality. Regards, Alex

Oct. 6, 2024

Re: Navigation by pages

by Rodrigo Arias

Hi Alex, On Sun, Oct 06, 2024 at 01:40:17PM +0200, a1ex(a)dismail.de wrote: >Hi Rodrigo, > >I saw your recent issue on GH: >https://github.com/dillo-browser/dillo/issues/268 > >This is something I have thought about for quite a while. Basically, >scrolling sucks, and it would be nice to be able to move up and down >the page more cleanly. Obviously we can use PgUP/PgDN keys and >spacebar, but I always wanted a way to do this with mouse-only. You can do this by clicking on the scroll bar, above and below the "thumb". https://dillo-browser.github.io/user_help.html#scrolling Does that work for you? >So, while I don't have a quick solution to the layout / pagination >issues you mentioned, I created a simple toolbar icon which allows page >navigation with the mouse. I think it really makes it easier when >reading a long page. Thanks for the patch. I think I would rather avoid more buttons on the toolbar if we can do it some other way. Best, Rodrigo.

Oct. 6, 2024

Navigation by pages

by a1ex＠dismail.de

Hi Rodrigo, I saw your recent issue on GH: https://github.com/dillo-browser/dillo/issues/268 This is something I have thought about for quite a while. Basically, scrolling sucks, and it would be nice to be able to move up and down the page more cleanly. Obviously we can use PgUP/PgDN keys and spacebar, but I always wanted a way to do this with mouse-only. In the past I had scripted a small window which sits on-top of Dillo in the corner, which had 2 buttons: up and down. This works, but is a bit clunky. So, while I don't have a quick solution to the layout / pagination issues you mentioned, I created a simple toolbar icon which allows page navigation with the mouse. I think it really makes it easier when reading a long page. Patch and screenshot attached. Regards, Alex

Oct. 6, 2024

Re: Issue 187: "Configure should stop when no compiler is found"

by Rodrigo Arias

On Sat, Oct 05, 2024 at 08:05:52PM +0200, a1ex(a)dismail.de wrote: >Very nice. Works fine here :) Thanks for testing! Merged. Rodrigo.

Oct. 6, 2024

Re: Issue 187: "Configure should stop when no compiler is found"

by a1ex＠dismail.de

Rodrigo Arias <rodarima(a)gmail.com> wrote: > I think something like this may be more strict, as we test that it > can compile a simple C++ program: > > diff --git a/configure.ac b/configure.ac > index 5c308cb7..7d156b81 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -129,6 +129,19 @@ AC_PROG_CXX > AC_PROG_RANLIB > AC_PROG_CPP > > +AC_MSG_CHECKING(if C++ compiler '$CXX' works) > +AC_LANG_PUSH([C++]) > +AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[ > + #ifndef __cplusplus > + #error "No C++ support, AC_PROG_CXX failed" > + #endif > + ]])], > + [AC_MSG_RESULT([yes])], > + [AC_MSG_RESULT(no) > + AC_MSG_FAILURE([C++ compiler doesn't work])] > +) > +AC_LANG_POP([C++]) > + > dnl ---------------------------- > dnl Check our char and int types > dnl ---------------------------- Very nice. Works fine here :)

Oct. 5, 2024

Re: CSS extra units

by Rodrigo Arias

On Sat, Oct 05, 2024 at 06:25:20PM +0200, a1ex(a)dismail.de wrote: >After a/b testing this with a fair amount of sites, I think it's a good >PR. Maybe 10-20% of sites tested showed some improvement, and I also >didn't see any especially noteworthy regressions. Thanks for testing! I will merge it soon. Best, Rodrigo

Oct. 5, 2024

Re: Issue 187: "Configure should stop when no compiler is found"

by Rodrigo Arias

Hi Alex, Thanks for the suggestions. On Sat, Oct 05, 2024 at 01:28:57PM +0200, a1ex(a)dismail.de wrote: >Hi Rodrigo, > >Regarding this issue[1], I have found couple of ways to address this: > >The easiest way is to do AC_PROG_CXX before AC_PROG_CC: > >--- a/configure.ac Sat Oct 5 13:15:28 2024 >+++ b/configure.ac Sat Oct 5 13:15:48 2024 >@@ -124,8 +124,8 @@ if test "x$enable_ssl" != "x"; then > AC_MSG_ERROR([The flag --enable-ssl is deprecated, use --enable-tls]) > fi > >-AC_PROG_CC > AC_PROG_CXX >+AC_PROG_CC > AC_PROG_RANLIB > AC_PROG_CPP > >Which now errors out when no working compiler is found: >'configure: error: C++ compiler cannot create executables' I think it relies on a detail of the implementation, so I don't think we can trust it to always work. I cannot believe that in 2024 it is still not considered a bug... >Alternately, we can add a check to verify if the complier actually >exists, and if not, exit. Something like this: > >dnl ------------------------------------------------------------ >dnl AC_PROG_CXX will set CXX=g++ even if it finds no useable C++ >dnl compiler, so we have to check whether the program named by >dnl CXX exists. >dnl ------------------------------------------------------------ >dnl >AC_PROG_CXX >AC_PATH_PROG(REAL_CXX, $CXX) >HAVE_CXX=no >if test -n "$REAL_CXX"; then > HAVE_CXX=yes >fi >if HAVE_CXX="no"; then > echo "Error: No working C++ compiler found!" > exit 1 > fi This is probably better, but even if the C++ compiler is in the path, it doesn't mean it actually works. I think something like this may be more strict, as we test that it can compile a simple C++ program: diff --git a/configure.ac b/configure.ac index 5c308cb7..7d156b81 100644 --- a/configure.ac +++ b/configure.ac @@ -129,6 +129,19 @@ AC_PROG_CXX AC_PROG_RANLIB AC_PROG_CPP +AC_MSG_CHECKING(if C++ compiler '$CXX' works) +AC_LANG_PUSH([C++]) +AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[ + #ifndef __cplusplus + #error "No C++ support, AC_PROG_CXX failed" + #endif + ]])], + [AC_MSG_RESULT([yes])], + [AC_MSG_RESULT(no) + AC_MSG_FAILURE([C++ compiler doesn't work])] +) +AC_LANG_POP([C++]) + dnl ---------------------------- dnl Check our char and int types dnl ---------------------------- Outputs this when configured with the non-existent iguana C++ compiler: $ ../configure CXX=iguana ... checking whether the compiler supports GNU C++... no checking whether iguana accepts -g... no checking for iguana option to enable C++11 features... unsupported checking for iguana option to enable C++98 features... unsupported checking dependency style of iguana... none checking for ranlib... ranlib checking how to run the C preprocessor... gcc -E checking if C++ compiler 'iguana' works... no configure: error: in '/home/ram/dev/dillo/git/build': configure: error: C++ compiler doesn't work See 'config.log' for more details Best, Rodrigo.

Oct. 5, 2024

Re: CSS extra units

by a1ex＠dismail.de

Hi, Rodrigo Arias <rodarima(a)gmail.com> wrote: > This PR adds support for extra CSS units (ch, rem, vw, vh, vmin and > vmax) from the mobilized fork: > > https://github.com/dillo-browser/dillo/pull/264 > > I tested it with a few sites, and overall it improves the rending > layout, but it would be nice if you can test it with more sites > before it gets merged. After a/b testing this with a fair amount of sites, I think it's a good PR. Maybe 10-20% of sites tested showed some improvement, and I also didn't see any especially noteworthy regressions. Regards, Alex

Oct. 5, 2024

Issue 187: "Configure should stop when no compiler is found"

by a1ex＠dismail.de

Hi Rodrigo, Regarding this issue[1], I have found couple of ways to address this: The easiest way is to do AC_PROG_CXX before AC_PROG_CC: --- a/configure.ac Sat Oct 5 13:15:28 2024 +++ b/configure.ac Sat Oct 5 13:15:48 2024 @@ -124,8 +124,8 @@ if test "x$enable_ssl" != "x"; then AC_MSG_ERROR([The flag --enable-ssl is deprecated, use --enable-tls]) fi -AC_PROG_CC AC_PROG_CXX +AC_PROG_CC AC_PROG_RANLIB AC_PROG_CPP Which now errors out when no working compiler is found: 'configure: error: C++ compiler cannot create executables' Alternately, we can add a check to verify if the complier actually exists, and if not, exit. Something like this: dnl ------------------------------------------------------------ dnl AC_PROG_CXX will set CXX=g++ even if it finds no useable C++ dnl compiler, so we have to check whether the program named by dnl CXX exists. dnl ------------------------------------------------------------ dnl AC_PROG_CXX AC_PATH_PROG(REAL_CXX, $CXX) HAVE_CXX=no if test -n "$REAL_CXX"; then HAVE_CXX=yes fi if HAVE_CXX="no"; then echo "Error: No working C++ compiler found!" exit 1 fi If either of these solutions work for you, I can create a pull request. [1] https://github.com/dillo-browser/dillo/issues/187 Regards, Alex

Oct. 5, 2024

CSS extra units

by Rodrigo Arias

Hi, This PR adds support for extra CSS units (ch, rem, vw, vh, vmin and vmax) from the mobilized fork: https://github.com/dillo-browser/dillo/pull/264 I tested it with a few sites, and overall it improves the rending layout, but it would be nice if you can test it with more sites before it gets merged. Best, Rodrigo.

Oct. 3, 2024

Re: POSIX build

by Rodrigo Arias

On Thu, Oct 03, 2024 at 01:08:46PM +0200, a1ex(a)dismail.de wrote: >Done: >https://github.com/dillo-browser/dillo/pull/265 Thanks!, merged in: To github.com:dillo-browser/dillo.git e7fee996..9880c1ba master -> master Best, Rodrigo.

Oct. 3, 2024

Re: POSIX build

by a1ex＠dismail.de

Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi Alex, > > On Wed, Oct 02, 2024 at 11:44:53AM +0200, a1ex(a)dismail.de wrote: > >Hi, > > > >Regarding the recent github discussion about build systems and POSIX: > > > >Just in case nobody else gets around to it, the attached patch > >changes the build to be POSIX compliant by using 'command -v' > >instead of 'which'. > > Thanks, can you open a PR on GitHub and CC @Kangie? Done: https://github.com/dillo-browser/dillo/pull/265

Oct. 3, 2024

Re: POSIX build

by Rodrigo Arias

Hi Alex, On Wed, Oct 02, 2024 at 11:44:53AM +0200, a1ex(a)dismail.de wrote: >Hi, > >Regarding the recent github discussion about build systems and POSIX: > >Just in case nobody else gets around to it, the attached patch changes >the build to be POSIX compliant by using 'command -v' instead of >'which'. Thanks, can you open a PR on GitHub and CC @Kangie? Best, Rodrigo.

Oct. 2, 2024

POSIX build

by a1ex＠dismail.de

Hi, Regarding the recent github discussion about build systems and POSIX: Just in case nobody else gets around to it, the attached patch changes the build to be POSIX compliant by using 'command -v' instead of 'which'. -Alex

Oct. 2, 2024

Re: Directory of Dillo-friendly services

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > >Here is a small site with a directory of Dillo-friendly services: > > > >https://alex.envs.net/dillectory/ > > > >I'd like to develop this further and maintain it, so if anyone has > >feedback or additions, please let me know! > > Sorry for the late reply. This is a very nice resource, thanks! I > didn't knew half of those services. > > Notice some links are broken as they have the http[s]:// prefix twice. Thanks, fixed! > > Provide Dillo-compatible alternatives to common services > > I don't like too much the idea of promoting silos like Medium or > Twitter, but that is my personal opinion and I not sure to which > extend that should influence Dillo. Yeah, that's somewhat of a dillema. I personally don't use those sites and don't really want to promote them either, but they are very popular and many people consider them essential. My original idea with the Dillectory was to target newer Dillo users, to show them that they can still use the services they are accustomed to. I guess a larger question is 'who is the average new Dillo user, and what are they trying to achieve by using Dillo'? Perhaps my assumptions are a little off-base. In any case, I'm certainly open to removing sites from the list if they are overly controversial or political. > I think for a section of "some sites to try Dillo", I would rather > prefer to promote static sites that are simple and handwritten by > humans which render good in Dillo and show what it is capable of > (tables, image, floating elements, basic CSS, ...). Which after all, > is what the web was originally made for. Agreed. While the sites on my directory all 'work' in Dillo, they rarely look great. Having a list which really showcases the abilities of Dillo would be nice. I can try to help track down some sites which look especially good if you like. > Of course you cannot always avoid those places, so it is nice to have > these directories handy. Your Dillectory fills nicely this need, so I > think it would be nice to place it in an "additional resources" > section. That would be awesome, thanks! The idea of running a 'rogue' directory which is not wanted by the Dillo project was a worry of mine, and so I will do whatever possible to make sure that the content serves a mutual interest. Regards, Alex

Oct. 2, 2024

Re: 'load_images' pref ineffective on embedded images

by Rodrigo Arias

On Tue, Sep 17, 2024 at 09:54:18AM +0200, a1ex(a)dismail.de wrote: > >> Hi, >> >> The pref 'load_images=NO' only disables loading images from a remote >> img src, and not from an embedded[1] data:image src. >> >> If this behavior is intentional, would it be reasonable to implement >> an option to disable all images? >> >> It might be the case that the user does not want to see any images, no >> matter the img src. > >If anyone cares about this issue, here is a simple fix to make sure >that embedded images do not display when 'load_images' is disabled: > >--- a/src/html.cc Tue Sep 17 09:41:51 2024 >+++ b/src/html.cc Tue Sep 17 09:42:44 2024 >@@ -2165,7 +2165,6 @@ DilloImage *a_Html_image_new(DilloHtml *html, const ch > html->images->set(html->images->size() - 1, hi); > > load_now = prefs.load_images || >- !dStrAsciiCasecmp(URL_SCHEME(url), "data") || > (a_Capi_get_flags_with_redirection(url) & CAPI_IsCached); > > if (load_now && Html_load_image(html->bw, url, html->page_url, image)) { > >Maybe it would be better to have a separate option to turn this off/on, >but I won't bother with that unless there is interest in it. I don't have an strong opinion on this, as sometimes it is handy to render bullets or other small "symbols". But other times they embed a large image. In any case, the image data is already downloaded anyway. Best, Rodrigo.

Oct. 1, 2024

Re: Directory of Dillo-friendly services

by Rodrigo Arias

Hi Alex, On Thu, Sep 19, 2024 at 08:01:02PM +0200, a1ex(a)dismail.de wrote: >Hi, > >Here is a small site with a directory of Dillo-friendly services: > >https://alex.envs.net/dillectory/ > >I'd like to develop this further and maintain it, so if anyone has >feedback or additions, please let me know! Sorry for the late reply. This is a very nice resource, thanks! I didn't knew half of those services. Notice some links are broken as they have the http[s]:// prefix twice. > Provide Dillo-compatible alternatives to common services I don't like too much the idea of promoting silos like Medium or Twitter, but that is my personal opinion and I not sure to which extend that should influence Dillo. I think for a section of "some sites to try Dillo", I would rather prefer to promote static sites that are simple and handwritten by humans which render good in Dillo and show what it is capable of (tables, image, floating elements, basic CSS, ...). Which after all, is what the web was originally made for. Probably I'll need to carefully cherry pick those, as there are a lot of blogs that render poorly, even if the content is nice. The idea is not only to show that Dillo can render HTML documents nicely, but also to suggest that it is possible to have a Web without the current garbage. Of course you cannot always avoid those places, so it is nice to have these directories handy. Your Dillectory fills nicely this need, so I think it would be nice to place it in an "additional resources" section. Best, Rodrigo.

Oct. 1, 2024

Directory of Dillo-friendly services

by a1ex＠dismail.de

Hi, Here is a small site with a directory of Dillo-friendly services: https://alex.envs.net/dillectory/ I'd like to develop this further and maintain it, so if anyone has feedback or additions, please let me know! Regards, Alex

Sept. 19, 2024

Re: 'load_images' pref ineffective on embedded images

by a1ex＠dismail.de

> Hi, > > The pref 'load_images=NO' only disables loading images from a remote > img src, and not from an embedded[1] data:image src. > > If this behavior is intentional, would it be reasonable to implement > an option to disable all images? > > It might be the case that the user does not want to see any images, no > matter the img src. If anyone cares about this issue, here is a simple fix to make sure that embedded images do not display when 'load_images' is disabled: --- a/src/html.cc Tue Sep 17 09:41:51 2024 +++ b/src/html.cc Tue Sep 17 09:42:44 2024 @@ -2165,7 +2165,6 @@ DilloImage *a_Html_image_new(DilloHtml *html, const ch html->images->set(html->images->size() - 1, hi); load_now = prefs.load_images || - !dStrAsciiCasecmp(URL_SCHEME(url), "data") || (a_Capi_get_flags_with_redirection(url) & CAPI_IsCached); if (load_now && Html_load_image(html->bw, url, html->page_url, image)) { Maybe it would be better to have a separate option to turn this off/on, but I won't bother with that unless there is interest in it. -Alex

Sept. 17, 2024