- Dillo-dev - lists.mailman3.com

<button> rendering

by corvid＠lavabit.com

As Html_tag_open_button() says, /* * Buttons are rendered on one line, this is (at several levels) a * bit simpler. May be changed in the future. */ For some time I've wondered: How hard would it be to fix that?

Dec. 10, 2012

BUG #1109

by corvid＠lavabit.com

I wrote: > Jorge wrote: > > If you open [1] with dillo, the "Component:" selection list > > gets overdrawn over and over. > > I see what you mean about the overdrawing now. I had been seeing wait times > of like 20 seconds with this page, but I just tried linking with 1.3.0, > and now it's fast but scribbles all over itself. Hmm... Redraws: Problem with 1.3.0, but not with 1.3.1 or newer. Slowness: A very, very, very, very, very extreme case of what can happen if you have -g -pg -O0. The Fl_Tree code is a touch sluggish with 18000 options and ordinary optimisation, but nothing that I'd feel bad about having in 3.0.3.

Dec. 9, 2012

BUG #1109

by corvid＠lavabit.com

Jorge wrote: > If you open [1] with dillo, the "Component:" selection list > gets overdrawn over and over. I see what you mean about the overdrawing now. I had been seeing wait times of like 20 seconds with this page, but I just tried linking with 1.3.0, and now it's fast but scribbles all over itself. Hmm...

Dec. 9, 2012

BUG #1109

by corvid＠lavabit.com

Jorge wrote: > On Sun, Dec 09, 2012 at 06:59:01PM +0000, corvid wrote: > > Jorge wrote: > > > As from the backtraces, it crashed with event 11 (MOVE) inside > > > a FLTK menu. I wonder what makes this particular menu different from > > > the others in the same page. > > > > Do you know which of the option menus it broke in? > > Unfortunately not. > > Sergio reports it having crashed a few times, but he can't force > it to crash, nor succeeded when I asked him to try to find a way to > reproduce the crash. In the backtrace, I saw a "numitems = 146", and the Product menu has 145 items, but that uses the selection list instead of selection option menu because it very plainly says 'multiple="multiple"'. Strange.

Dec. 9, 2012

Unused?: the url tag in the DPI start_send_page command

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > On Sun, Dec 09, 2012 at 04:14:01PM +0000, Jeremy Henty wrote: > > > > Everything that sends the start_send_page DPI command also sends a > > url attribute with it, but I think this attribute is always > > ignored. > > > > Dillo processes the command in capi.c but it does nothing with it > > because the Cache is already set up to receive the following raw > > data. So it doesn't look at any attributes. The only other thing > > that receives a start_send_page is the view source DPI and it > > doesn't look at any of the attributes either (it extracts a url > > from the previous tag in the stream, which it then sends back to > > Dillo to be ignored). > > View source shows the URL as page title. Yes, but it gets that url from the open_url tag that Dillo sends first. The DPI then reads the start_send_page tag but ignores its url attribute. Nothing reads the url attribute from any start_send_page tag. Regards, Jeremy Henty

Dec. 9, 2012

BUG #1109

by jcid＠dillo.org

On Sun, Dec 09, 2012 at 06:59:01PM +0000, corvid wrote: > Jorge wrote: > > If you open [1] with dillo, the "Component:" selection list > > gets overdrawn over and over. > > That list has over 18000 options. > > This was the final thing that prompted me to try changing the Fl_Tree to > Fl_Browser, since gprof showed problems where the code would iterate through > the tree by going into the parent, searching for which child we were, and then > going into the next one. This resulted in something like 300000000 calls to > various Fl_Tree_Item functions with child in the name. I was able to rewrite > some code to do things differently, but some was just internal. > > 1. With a somewhat older dillo with a somewhat older fltk, I wasn't seeing > this slowness, though. When I spent a little time trying to find out what > was the root of this, results seemed inconsistent. I...suppose it's worth > digging into again for the sake of 3.0.3. > > 2. You're supposed to get a better Fl_Tree algorithm if you set > #define FLTK_ABI_VERSION 10301 , but that's not a good option for us. > > > Some more details here [2] (backtraces, etc). > > > > As from the backtraces, it crashed with event 11 (MOVE) inside > > a FLTK menu. I wonder what makes this particular menu different from > > the others in the same page. > > Do you know which of the option menus it broke in? Unfortunately not. Sergio reports it having crashed a few times, but he can't force it to crash, nor succeeded when I asked him to try to find a way to reproduce the crash. -- Cheers Jorge.-

Dec. 9, 2012

BUG #1109

by corvid＠lavabit.com

Jorge wrote: > If you open [1] with dillo, the "Component:" selection list > gets overdrawn over and over. That list has over 18000 options. This was the final thing that prompted me to try changing the Fl_Tree to Fl_Browser, since gprof showed problems where the code would iterate through the tree by going into the parent, searching for which child we were, and then going into the next one. This resulted in something like 300000000 calls to various Fl_Tree_Item functions with child in the name. I was able to rewrite some code to do things differently, but some was just internal. 1. With a somewhat older dillo with a somewhat older fltk, I wasn't seeing this slowness, though. When I spent a little time trying to find out what was the root of this, results seemed inconsistent. I...suppose it's worth digging into again for the sake of 3.0.3. 2. You're supposed to get a better Fl_Tree algorithm if you set #define FLTK_ABI_VERSION 10301 , but that's not a good option for us. > Some more details here [2] (backtraces, etc). > > As from the backtraces, it crashed with event 11 (MOVE) inside > a FLTK menu. I wonder what makes this particular menu different from > the others in the same page. Do you know which of the option menus it broke in? > [1] https://bugzilla.redhat.com/query.cgi?format=advanced > [2] https://bugzilla.redhat.com/show_bug.cgi?id=884778

Dec. 9, 2012

BUG #1109

by jcid＠dillo.org

Hi, I contacted Sergio (submitter of BUG #1109), and here we have something weird. He reports crashes or weird behaviour. If you open [1] with dillo, the "Component:" selection list gets overdrawn over and over. Some more details here [2] (backtraces, etc). As from the backtraces, it crashed with event 11 (MOVE) inside a FLTK menu. I wonder what makes this particular menu different from the others in the same page. [1] https://bugzilla.redhat.com/query.cgi?format=advanced [2] https://bugzilla.redhat.com/show_bug.cgi?id=884778 -- Cheers Jorge.-

Dec. 9, 2012

Unused?: the url tag in the DPI start_send_page command

by jcid＠dillo.org

On Sun, Dec 09, 2012 at 04:14:01PM +0000, Jeremy Henty wrote: > > Everything that sends the start_send_page DPI command also sends a url > attribute with it, but I think this attribute is always ignored. > > Dillo processes the command in capi.c but it does nothing with it > because the Cache is already set up to receive the following raw data. > So it doesn't look at any attributes. The only other thing that > receives a start_send_page is the view source DPI and it doesn't look > at any of the attributes either (it extracts a url from the previous > tag in the stream, which it then sends back to Dillo to be ignored). View source shows the URL as page title. > So what is this attribute for? Future use? Or is it something that > just never got used? In general terms, there were ideas that went unused, and some extensions that were necessary to solve an unforeseen situation; as dpi authentication to avoid a local socket spoofing attack. The dpi framework is the same for several quite different dpi programs (aka plugins). The interface was kept more or less uniform, and each dpi chooses whether to use the info or not. -- Cheers Jorge.-

Dec. 9, 2012

Unused?: the url tag in the DPI start_send_page command

by onepoint＠starurchin.org

Everything that sends the start_send_page DPI command also sends a url attribute with it, but I think this attribute is always ignored. Dillo processes the command in capi.c but it does nothing with it because the Cache is already set up to receive the following raw data. So it doesn't look at any attributes. The only other thing that receives a start_send_page is the view source DPI and it doesn't look at any of the attributes either (it extracts a url from the previous tag in the stream, which it then sends back to Dillo to be ignored). So what is this attribute for? Future use? Or is it something that just never got used? Regards, Jeremy Henty

Dec. 9, 2012