- Dillo-dev - lists.mailman3.com

segfault -- callback + closed window?

by corvid＠lavabit.com

Johannes wrote: > On Mon, Sep 29, 2008 at 07:38:20PM +0000, corvid wrote: > > I hit ',' a few times, going back past a page with a > > big progressive jpeg webcomic, and hit ^Q to close the window > > while dillo was thinking its way past that image. > > > > Got: > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 16384 (LWP 2782)] > > 0x080fc708 in fltk::Widget::redraw (this=0x81cb680, flags=8 '\b') > > at Widget.cxx:575 > > 575 widget->damage_ |= DAMAGE_CHILD; > > (gdb) bt > > #0 0x080fc708 in fltk::Widget::redraw (this=0x81cb680, flags=8 '\b') > > at Widget.cxx:575 > > #1 0x0804f679 in UI::button_set_sens (this=0x82ce9d8, btn=UI_STOP, sens=0) > > at ui.cc:1109 > > #2 0x08054c59 in a_UIcmd_set_buttons_sens_cb (vbw=0x81ad858) at uicmd.cc:835 > > #3 0x080e47f9 in fltk::wait () at TabGroup.cxx:116 > > #4 0x080e489d in fltk::run () at TabGroup.cxx:116 > > #5 0x0804efab in main (argc=1, argv=0xbffffb44) at dillo.cc:127 > > > > > > Maybe that's just a part of life with callbacks... > > > > I no longer see this crash when removing the buttons_sens workaround > in uicmd.cc as in attached patch. No more crash for me either. Thanks!

Sept. 30, 2008

an experiment regarding cross site request forgery

by joerg.sonnenberger＠web.de

On Tue, Sep 30, 2008 at 02:51:58PM +0000, corvid wrote: > Joerg wrote: > > On Tue, Sep 30, 2008 at 12:56:05PM +0000, corvid wrote: > > > So my latest little experiment: out of the image urls your browser > > > sees that have queries (the '?a=b&c=d&e=f'), how many are > > > > There's nothing wrong with that. Such an image URL is a simple GET > > request. Any web application doing a modification is broken by design > > and there are good reasons for allowing such URLs. The problem is > > allowing POST actions to a different site than the one issuing it. > > Isn't that part of the problem -- that broken sites are using GET for > things they shouldn't? CSRF is about both. Broken sites are broken sites -- not much to do about them. What I do worry about are properly written web applications, e.g. those that correctly use GET/POST, but don't have explicit protection about CSRF. The latter is kind of intrusive if the framework used doesn't allow that. > PS How about not sending cookies with queries for images? Breaks if you are using session controll to decide what images can be accessed. Joerg

Sept. 30, 2008

segfault -- callback + closed window?

by Johannes.Hofmann＠gmx.de

On Tue, Sep 30, 2008 at 12:41:21PM -0400, Jorge Arellano Cid wrote: > On Tue, Sep 30, 2008 at 12:03:57PM -0400, Jorge Arellano Cid wrote: > > On Tue, Sep 30, 2008 at 05:22:08PM +0200, Johannes Hofmann wrote: > > > Hi, > > > > > > On Mon, Sep 29, 2008 at 07:38:20PM +0000, corvid wrote: > > > > I hit ',' a few times, going back past a page with a > > > > big progressive jpeg webcomic, and hit ^Q to close the window > > > > while dillo was thinking its way past that image. > > > > > > > > Got: > > > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > > [Switching to Thread 16384 (LWP 2782)] > > > > 0x080fc708 in fltk::Widget::redraw (this=0x81cb680, flags=8 '\b') > > > > at Widget.cxx:575 > > > > 575 widget->damage_ |= DAMAGE_CHILD; > > > > (gdb) bt > > > > #0 0x080fc708 in fltk::Widget::redraw (this=0x81cb680, flags=8 '\b') > > > > at Widget.cxx:575 > > > > #1 0x0804f679 in UI::button_set_sens (this=0x82ce9d8, btn=UI_STOP, sens=0) > > > > at ui.cc:1109 > > > > #2 0x08054c59 in a_UIcmd_set_buttons_sens_cb (vbw=0x81ad858) at uicmd.cc:835 > > > > #3 0x080e47f9 in fltk::wait () at TabGroup.cxx:116 > > > > #4 0x080e489d in fltk::run () at TabGroup.cxx:116 > > > > #5 0x0804efab in main (argc=1, argv=0xbffffb44) at dillo.cc:127 > > > > > > > > > > > > Maybe that's just a part of life with callbacks... > > > > > > > > > > I no longer see this crash when removing the buttons_sens workaround > > > in uicmd.cc as in attached patch. > > > Does someone remember why it was introduced? > > > > It comes from dillo1. > > > > Committed. > > > > BTW, this is exactly what I meant with a UI getting the wrong bw. > > I think this should be fixed before the release. > > Update: I have a patch that works in my tree. It gets rid of > bw as the window's user_data(). > Just allow me some time to test/polish. > Cool. Just wanted to start it myself. Cheers, Johannes

Sept. 30, 2008

segfault -- callback + closed window?

by jcid＠dillo.org

On Tue, Sep 30, 2008 at 12:03:57PM -0400, Jorge Arellano Cid wrote: > On Tue, Sep 30, 2008 at 05:22:08PM +0200, Johannes Hofmann wrote: > > Hi, > > > > On Mon, Sep 29, 2008 at 07:38:20PM +0000, corvid wrote: > > > I hit ',' a few times, going back past a page with a > > > big progressive jpeg webcomic, and hit ^Q to close the window > > > while dillo was thinking its way past that image. > > > > > > Got: > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > [Switching to Thread 16384 (LWP 2782)] > > > 0x080fc708 in fltk::Widget::redraw (this=0x81cb680, flags=8 '\b') > > > at Widget.cxx:575 > > > 575 widget->damage_ |= DAMAGE_CHILD; > > > (gdb) bt > > > #0 0x080fc708 in fltk::Widget::redraw (this=0x81cb680, flags=8 '\b') > > > at Widget.cxx:575 > > > #1 0x0804f679 in UI::button_set_sens (this=0x82ce9d8, btn=UI_STOP, sens=0) > > > at ui.cc:1109 > > > #2 0x08054c59 in a_UIcmd_set_buttons_sens_cb (vbw=0x81ad858) at uicmd.cc:835 > > > #3 0x080e47f9 in fltk::wait () at TabGroup.cxx:116 > > > #4 0x080e489d in fltk::run () at TabGroup.cxx:116 > > > #5 0x0804efab in main (argc=1, argv=0xbffffb44) at dillo.cc:127 > > > > > > > > > Maybe that's just a part of life with callbacks... > > > > > > > I no longer see this crash when removing the buttons_sens workaround > > in uicmd.cc as in attached patch. > > Does someone remember why it was introduced? > > It comes from dillo1. > > Committed. > > BTW, this is exactly what I meant with a UI getting the wrong bw. > I think this should be fixed before the release. Update: I have a patch that works in my tree. It gets rid of bw as the window's user_data(). Just allow me some time to test/polish. -- Cheers Jorge.-

Sept. 30, 2008

segfault -- callback + closed window?

by jcid＠dillo.org

On Tue, Sep 30, 2008 at 05:22:08PM +0200, Johannes Hofmann wrote: > Hi, > > On Mon, Sep 29, 2008 at 07:38:20PM +0000, corvid wrote: > > I hit ',' a few times, going back past a page with a > > big progressive jpeg webcomic, and hit ^Q to close the window > > while dillo was thinking its way past that image. > > > > Got: > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 16384 (LWP 2782)] > > 0x080fc708 in fltk::Widget::redraw (this=0x81cb680, flags=8 '\b') > > at Widget.cxx:575 > > 575 widget->damage_ |= DAMAGE_CHILD; > > (gdb) bt > > #0 0x080fc708 in fltk::Widget::redraw (this=0x81cb680, flags=8 '\b') > > at Widget.cxx:575 > > #1 0x0804f679 in UI::button_set_sens (this=0x82ce9d8, btn=UI_STOP, sens=0) > > at ui.cc:1109 > > #2 0x08054c59 in a_UIcmd_set_buttons_sens_cb (vbw=0x81ad858) at uicmd.cc:835 > > #3 0x080e47f9 in fltk::wait () at TabGroup.cxx:116 > > #4 0x080e489d in fltk::run () at TabGroup.cxx:116 > > #5 0x0804efab in main (argc=1, argv=0xbffffb44) at dillo.cc:127 > > > > > > Maybe that's just a part of life with callbacks... > > > > I no longer see this crash when removing the buttons_sens workaround > in uicmd.cc as in attached patch. > Does someone remember why it was introduced? It comes from dillo1. Committed. BTW, this is exactly what I meant with a UI getting the wrong bw. I think this should be fixed before the release. -- Cheers Jorge.-

Sept. 30, 2008

segfault -- callback + closed window?

by Johannes.Hofmann＠gmx.de

Hi, On Mon, Sep 29, 2008 at 07:38:20PM +0000, corvid wrote: > I hit ',' a few times, going back past a page with a > big progressive jpeg webcomic, and hit ^Q to close the window > while dillo was thinking its way past that image. > > Got: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 16384 (LWP 2782)] > 0x080fc708 in fltk::Widget::redraw (this=0x81cb680, flags=8 '\b') > at Widget.cxx:575 > 575 widget->damage_ |= DAMAGE_CHILD; > (gdb) bt > #0 0x080fc708 in fltk::Widget::redraw (this=0x81cb680, flags=8 '\b') > at Widget.cxx:575 > #1 0x0804f679 in UI::button_set_sens (this=0x82ce9d8, btn=UI_STOP, sens=0) > at ui.cc:1109 > #2 0x08054c59 in a_UIcmd_set_buttons_sens_cb (vbw=0x81ad858) at uicmd.cc:835 > #3 0x080e47f9 in fltk::wait () at TabGroup.cxx:116 > #4 0x080e489d in fltk::run () at TabGroup.cxx:116 > #5 0x0804efab in main (argc=1, argv=0xbffffb44) at dillo.cc:127 > > > Maybe that's just a part of life with callbacks... > I no longer see this crash when removing the buttons_sens workaround in uicmd.cc as in attached patch. Does someone remember why it was introduced? Cheers, Johannes

Sept. 30, 2008

what crashes remain?

by corvid＠lavabit.com

Jorge wrote: > On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > > It's still possible to crash dillo if you click on a remote link and > > quickly click on some images to load them. Doesn't crash every time, > > but typically within four tries or so. I had assumed it was the same > > thing as whatever was wrong with the menu crash, so I'd ignored it. > > > > If I stick > > a_Bw_stop_clients(bw, BW_Img); > > in the DilloHtml destructor, I can no longer get it to crash, but > > I randomly got a "Cache_process_queue Caught busy!!!" while browsing > > earlier today, so there's something wrong with just doing that. > > (Assuming it's related; I'm not in the habit of getting that MSG.) > > That message means big trouble: the event loop stepped over itself... > > I've tried several different ways but can't get to crash it. > > Does the attached patch help? Now I've started to see a few times -- seemingly at random -- where I can't load an image unless I page back and forward again. I'll have to stick some MSGs in my tree and see why it's unhappy.

Sept. 30, 2008

source window's reluctance to show end of file

by jcid＠dillo.org

On Mon, Sep 22, 2008 at 09:06:03PM +0000, corvid wrote: > Jorge wrote: > > On Mon, Sep 22, 2008 at 04:00:59PM +0000, corvid wrote: > > > I've been assuming all along that everyone sees this problem, > > > but then I don't think anyone has ever mentioned it, so I > > > wonder whether it only shows up on my slow machine. > > > > > > Thus far it's always been easier for me to resize the > > > window -- thereby causing whatever refiguring is > > > necessary -- than to dig through TextDisplay to find > > > out what goes wrong when line numbers are turned on. > > > > Yes, I've noticed this and use the same trick to get to the page > > bottom! ;) > > > > Most probably a bug in fltk::TextDisplay. > > > > It also makes me think of making "View source" display from within > > dillo as modified plain text (line numbers + text lines) to get > > "find text" for free as we discussed some time ago. > > > > Unfortunately now the priority is with Tabs and the near release. > > Playing around without too much of an idea of what > I'm doing, I find that sticking a td->relayout(LAYOUT_WH); > after the line number calculations seems to make the > problem go away, so if (as seems overwhelmingly likely) > we don't have a nice solution by release, we could do > something like that as a workaround. It didn't work here. Committed another workaround. Please test. -- Cheers Jorge.-

Sept. 30, 2008

an experiment regarding cross site request forgery

by corvid＠lavabit.com

Joerg wrote: > On Tue, Sep 30, 2008 at 12:56:05PM +0000, corvid wrote: > > So my latest little experiment: out of the image urls your browser > > sees that have queries (the '?a=b&c=d&e=f'), how many are > > There's nothing wrong with that. Such an image URL is a simple GET > request. Any web application doing a modification is broken by design > and there are good reasons for allowing such URLs. The problem is > allowing POST actions to a different site than the one issuing it. Isn't that part of the problem -- that broken sites are using GET for things they shouldn't? PS How about not sending cookies with queries for images? > > If you want to prevent CSRF, consider adding a warning for that (e.g. > form action and current URL are not under the same second level domain). > > Joerg

Sept. 30, 2008

an experiment regarding cross site request forgery

by Johannes.Hofmann＠gmx.de

Hi, On Tue, Sep 30, 2008 at 12:56:05PM +0000, corvid wrote: > Cross site request forgery is the one where the bad person sticks > an image tag or some javascript or whatever on a page, > and your privileges are used to do something. Sounds interesting. Just read the corresponding wikipedia entry. > > So my latest little experiment: out of the image urls your browser > sees that have queries (the '?a=b&c=d&e=f'), how many are > - just advertisement trash anyway > - things you want where the request would work just as well with the query > removed (e.g. forum software that likes to stick session ids on everything) > - things that wouldn't still work but don't really matter (e.g. user icons) > - things you need > > Here's a little bit of code that tries rejecting them. > (If dillo had an option for such a thing someday, I imagine it would have a > form more like "don't automatically load, and make it easier to know what the > URL is before you load it manually") To me the cross site request forgery issue looks more like an issue of the cookie system. Perhaps we should be more careful when to send out a cookie. What about not sending cookies with image requests, if the host of the image url is different from the one in the main page? What do other browser do about this? Cheers, Johannes

Sept. 30, 2008

an experiment regarding cross site request forgery

by joerg.sonnenberger＠web.de

On Tue, Sep 30, 2008 at 12:56:05PM +0000, corvid wrote: > So my latest little experiment: out of the image urls your browser > sees that have queries (the '?a=b&c=d&e=f'), how many are There's nothing wrong with that. Such an image URL is a simple GET request. Any web application doing a modification is broken by design and there are good reasons for allowing such URLs. The problem is allowing POST actions to a different site than the one issuing it. If you want to prevent CSRF, consider adding a warning for that (e.g. form action and current URL are not under the same second level domain). Joerg

Sept. 30, 2008

Window close dialog

by jcid＠dillo.org

On Mon, Sep 29, 2008 at 08:46:10PM +0200, Johannes Hofmann wrote: > On Mon, Sep 29, 2008 at 11:12:39AM -0400, Jorge Arellano Cid wrote: > > On Mon, Sep 29, 2008 at 04:03:55PM +0200, Johannes Hofmann wrote: > > > Hi, > > > > > > On Mon, Sep 29, 2008 at 09:48:58AM -0400, Jorge Arellano Cid wrote: > > > > Hi, > > > > > > > > Can somebody please make the dialog for closing a window > > > > with tabs open? > > > > > > "Close Window" only closes the current tab anyway. > > > > Yes. > > > > > "Exit Dillo" closes all windows including tabs. > > > So, do you think about a dialog in the "Exit Dillo" case when > > > there is more than one tab or more than one window or both? > > > > Both, plus the window manager's "close window" if there're open Tabs. > > > > > Do we have the number of open windows somewhere? > > > > In bw.cc's num_bws. > > > > Ok, please check attached patch. > It relies on the current browser window to be stored in a window's > user_data. > We may want to reconsider this, but certainly not before the > release. Committed. -- Cheers Jorge.-

Sept. 30, 2008

patch: changeLinkColor

by jcid＠dillo.org

On Mon, Sep 29, 2008 at 08:50:18PM +0200, Johannes Hofmann wrote: > On Sun, Sep 28, 2008 at 04:40:53PM -0400, Jorge Arellano Cid wrote: > > On Sun, Sep 28, 2008 at 09:20:17PM +0200, Johannes Hofmann wrote: > > > On Sun, Sep 28, 2008 at 02:54:56PM -0400, Jorge Arellano Cid wrote: > > > > On Sun, Sep 28, 2008 at 05:55:10PM +0000, corvid wrote: > > > > > Encouraged by the idea that I am going in the right direction, I have > > > > > made a new one with spaceStyle: > > > > > > > > Funny how we were working on the same patch a the same time! > > > > > > > > I had an ancient version, and gave it a review. > > > > The link search is linear inside textblock. A linux gazette page > > > > showed more than 33000 words to color a link. On bigger pages it may be worst. > > > > It depends on the structure. For instance our bookmarks uses tables > > > > and the link is usually found in less than 10 words. > > > > > > > > The patch in CVS reduce the 35000 steps to 1500 or so (the > > > > sorted link list is sparse, so there's a penalty for looking > > > > for an actual link to compare to). > > > > > > > > > > Not sure I understand this optimization. > > > It is assuming that link numbers are always increasing, right? > > > > Right. > > > > > Can we assume this in dw/*? > > > > I checked html.cc and x_link is crescent. Not sure about the rest. > > > > > src/html.cc seems to be implemented currently in way that this is > > > true. But perhaps we could/should reuse link numbers for equal > > > destination urls in the future? > > > > In that case it'd need a revision. > > > > > Or someone might just choose hashes of the url string as link > > > number. > > > > > > BTW. with both implementations I now see issues with this example: > > > > > > <html> > > > <body> > > > <a href="http://www.dillo.org">dillo</a> > > > <a href="http://slashdot.org">slashdot</a> > > > <a href="http://www.dillo.org">dillo</a> > > > </body> > > > </html> > > > > > > When opening the first link in a new window, it doesn't change color > > > in the original one. > > > When opening it in a tab, the first one changes color. After a > > > reload also the second one changes color. > > > Am I missing something? > > > > Yes, the link color change is meant as a visual cue for the user > > to know the click is being processed. We could leave the link alone > > and change the mouse cursor instead. > > > > The link not changing color when openning it with the menu > > is IMO a bug, I'm looking for... > > > > BTW, the linear search patch is much simpler and as link > > clicking is not a performance critical task it could be left > > implemented in O(n). > > I prefer linear search. Once it really becomes a performance problem > we can look for an optimization. Committed corvid's version. -- Cheers Jorge.-

Sept. 30, 2008

an experiment regarding cross site request forgery

by corvid＠lavabit.com

Cross site request forgery is the one where the bad person sticks an image tag or some javascript or whatever on a page, and your privileges are used to do something. So my latest little experiment: out of the image urls your browser sees that have queries (the '?a=b&c=d&e=f'), how many are - just advertisement trash anyway - things you want where the request would work just as well with the query removed (e.g. forum software that likes to stick session ids on everything) - things that wouldn't still work but don't really matter (e.g. user icons) - things you need Here's a little bit of code that tries rejecting them. (If dillo had an option for such a thing someday, I imagine it would have a form more like "don't automatically load, and make it easier to know what the URL is before you load it manually")

Sept. 30, 2008

what crashes remain?

by corvid＠lavabit.com

I wrote: > Jorge wrote: > > On Mon, Sep 29, 2008 at 05:49:44PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Mon, Sep 29, 2008 at 02:09:36PM +0000, corvid wrote: > > > > > Jorge wrote: > > > > > > On Sun, Sep 28, 2008 at 12:52:47AM +0000, corvid wrote: > > > > > > > Playing with the file menu, I see that Alt-W, Alt-E, Alt-X, Alt-C > > > > > > > all segfault. I thought somebody said something (that I didn't pay > > > > > > > attention to) about the file menu since tabs were added, but if so, > > > > > > > I can't find that mail. > > > > > > > > > > > > Please check the patch in CVS. > > > > > > > > > > > > FLTK2 has a bug in that it regards the first menu item letter as > > > > > > a shortcut. > > > > > > > > > > > > Note: I tried with invisible shortcuts doing nothing, > > > > > > removing shortcuts and all that stuff, until I found this way > > > > > > to workaround the problem. > > > > > > > > > > > > Note2: Alt-W and Alt-X are accelerators, so they're OK. > > > > > > > > > > > > AFAIS there's no more segfault here. > > > > > > > > > > Alt-W and Alt-X still segfault for me. > > > > Does anybody else see this bug? > > Here's the backtrace that I get: > > #0 0x080c9df0 in fltk::Widget::any_of (this=0x70, f=4864) > at ../fltk/Widget.h:143 > #1 0x080c9e3c in fltk::Widget::takesevents (this=0x70) at ../fltk/Widget.h:168 > #2 0x080e43c4 in fltk::Widget::take_focus (this=0x70) at run.cxx:152 > #3 0x080d6bc5 in fltk::MenuBar::handle (this=0x816a5a0, event=12) > at MenuBar.cxx:94 [snip] MenuBar.cxx:93 went as follows: #0 a_UIcmd_close_bw (vbw=0x81b1958) at uicmd.cc:232 #1 0x08055bc9 in a_UIcmd_close_all_bw () at uicmd.cc:259 #2 0x08051c58 in menubar_cb (wid=0x8166288, data=0x810df5d) at ui.cc:477 #3 0x080d643a in fltk::Menu::popup () at Widget.cxx:49 #4 0x080d6cb9 in fltk::MenuBar::handle (this=0x816a440, event=12) at MenuBar.cxx:93 so MenuBar and its lastfocus_ are dead by line 94. There seems to be a pattern emerging lately :)

Sept. 30, 2008

what crashes remain?

by corvid＠lavabit.com

Jorge wrote: > On Mon, Sep 29, 2008 at 05:49:44PM +0000, corvid wrote: > > Jorge wrote: > > > On Mon, Sep 29, 2008 at 02:09:36PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Sun, Sep 28, 2008 at 12:52:47AM +0000, corvid wrote: > > > > > > Playing with the file menu, I see that Alt-W, Alt-E, Alt-X, Alt-C > > > > > > all segfault. I thought somebody said something (that I didn't pay > > > > > > attention to) about the file menu since tabs were added, but if so, > > > > > > I can't find that mail. > > > > > > > > > > Please check the patch in CVS. > > > > > > > > > > FLTK2 has a bug in that it regards the first menu item letter as > > > > > a shortcut. > > > > > > > > > > Note: I tried with invisible shortcuts doing nothing, > > > > > removing shortcuts and all that stuff, until I found this way > > > > > to workaround the problem. > > > > > > > > > > Note2: Alt-W and Alt-X are accelerators, so they're OK. > > > > > > > > > > AFAIS there's no more segfault here. > > > > > > > > Alt-W and Alt-X still segfault for me. > > Does anybody else see this bug? Here's the backtrace that I get: #0 0x080c9df0 in fltk::Widget::any_of (this=0x70, f=4864) at ../fltk/Widget.h:143 #1 0x080c9e3c in fltk::Widget::takesevents (this=0x70) at ../fltk/Widget.h:168 #2 0x080e43c4 in fltk::Widget::take_focus (this=0x70) at run.cxx:152 #3 0x080d6bc5 in fltk::MenuBar::handle (this=0x816a5a0, event=12) at MenuBar.cxx:94 #4 0x080ff1c3 in fltk::Widget::send (this=0x816a5a0, event=12) at Widget.cxx:804 #5 0x080c96d6 in fltk::Group::handle (this=0x816aa58, event=12) at Group.cxx:416 #6 0x080ff1c3 in fltk::Widget::send (this=0x816aa58, event=12) at Widget.cxx:804 #7 0x080c9691 in fltk::Group::handle (this=0x816a818, event=12) at Group.cxx:413 #8 0x080ff1c3 in fltk::Widget::send (this=0x816a818, event=12) at Widget.cxx:804 #9 0x080c9691 in fltk::Group::handle (this=0x815abb0, event=12) at Group.cxx:413 #10 0x080503e8 in UI::handle (this=0x815abb0, event=12) at ui.cc:809 #11 0x080ff1c3 in fltk::Widget::send (this=0x815abb0, event=12) at Widget.cxx:804 #12 0x080ef2ce in fltk::TabGroup::handle (this=0x815ab28, event=12) at TabGroup.cxx:239 #13 0x080567bf in CustTabGroup::handle (this=0x815ab28, e=12) at uicmd.cc:79 #14 0x080ff1c3 in fltk::Widget::send (this=0x815ab28, event=12) at Widget.cxx:804 #15 0x080c9691 in fltk::Group::handle (this=0x815a6a0, event=12) at Group.cxx:413 #16 0x0810160c in fltk::Window::handle () #17 0x080ff1c3 in fltk::Widget::send (this=0x815a6a0, event=12) at Widget.cxx:804 #18 0x080dfd11 in fltk::handle (event=12, window=0x815a6a0) at run.cxx:1319 #19 0x080dfdb9 in fltk::try_shortcut () at run.cxx:1195 #20 0x080d1167 in fltk::Input::handle_key () at Widget.cxx:49 #21 0x080d15d5 in fltk::Input::handle () at Widget.cxx:49 #22 0x080d18f1 in fltk::Input::handle () at Widget.cxx:49 #23 0x0805431c in CustInput::handle (this=0x81657f0, e=8) at ui.cc:82 #24 0x080ff1f2 in fltk::Widget::send (this=0x81657f0, event=8) at Widget.cxx:808 #25 0x080dfc4d in fltk::handle (event=8, window=0x815a6a0) at run.cxx:1293 #26 0x080e62a8 in fltk::handle () at x11/run.cxx:1961 #27 0x080e62f0 in do_queued_events () at x11/run.cxx:399 #28 0x080e661c in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:459 #29 0x080e66b7 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:463 #30 0x080e67ce in fltk::run () at run.cxx:399 #31 0x0804efab in main (argc=1, argv=0xbffffb44) at dillo.cc:127

Sept. 30, 2008

Window close dialog

by jcid＠dillo.org

On Mon, Sep 29, 2008 at 07:46:52PM +0200, Johannes Hofmann wrote: > Hi Jorge, > > On Mon, Sep 29, 2008 at 11:12:39AM -0400, Jorge Arellano Cid wrote: > > On Mon, Sep 29, 2008 at 04:03:55PM +0200, Johannes Hofmann wrote: > > > Hi, > > > > > > On Mon, Sep 29, 2008 at 09:48:58AM -0400, Jorge Arellano Cid wrote: > > > > Hi, > > > > > > > > Can somebody please make the dialog for closing a window > > > > with tabs open? > > > > > > "Close Window" only closes the current tab anyway. > > > > Yes. > > > > > "Exit Dillo" closes all windows including tabs. > > > So, do you think about a dialog in the "Exit Dillo" case when > > > there is more than one tab or more than one window or both? > > > > Both, plus the window manager's "close window" if there're open Tabs. > > > > > Do we have the number of open windows somewhere? > > > > In bw.cc's num_bws. > > > > just tried to implement that by creating a callback for the > fltk::Window. But then I noticed that user_data() of the windows is > already beeing used in ui.cc. > I don't understand why this is necessary. UI also contains a pointer > to the BrowserWindow (Bw). It helps the child widgets find their bw. e.g. search button, panel buttons, etc. They are nested in different ways depending on the panel shape choice so AFAIS there's no easy way to navigate up to the UI. One way solve it is to store the bw in the window's user_data(), thus a simple wid->window()->user_data() does the trick. Giving it some more thought, the danger of some function not belonging to the current UI geting the wrong bw is real, and it may end sending commands to the wrong bw. IOW: there's only one window for several tabs. When Tabs switch focus, the window()->user_data() is updated accordingly. If a background Tab requests its bw using window()->user_data() it will get the wrong one! (this may cause problems as the one reported by corvid.) If we can find an alternative method to get to a widget's bw (storing it in the CustTabGroup for instance), it'd be much better. -- Cheers Jorge.-

Sept. 30, 2008

what crashes remain?

by jcid＠dillo.org

On Mon, Sep 29, 2008 at 05:49:44PM +0000, corvid wrote: > Jorge wrote: > > On Mon, Sep 29, 2008 at 02:09:36PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Sun, Sep 28, 2008 at 12:52:47AM +0000, corvid wrote: > > > > > Playing with the file menu, I see that Alt-W, Alt-E, Alt-X, Alt-C > > > > > all segfault. I thought somebody said something (that I didn't pay > > > > > attention to) about the file menu since tabs were added, but if so, > > > > > I can't find that mail. > > > > > > > > Please check the patch in CVS. > > > > > > > > FLTK2 has a bug in that it regards the first menu item letter as > > > > a shortcut. > > > > > > > > Note: I tried with invisible shortcuts doing nothing, > > > > removing shortcuts and all that stuff, until I found this way > > > > to workaround the problem. > > > > > > > > Note2: Alt-W and Alt-X are accelerators, so they're OK. > > > > > > > > AFAIS there's no more segfault here. > > > > > > Alt-W and Alt-X still segfault for me. Does anybody else see this bug? > > > > Hmm... > > > > What fltk version are you using? > > > > Anyway, as a workaround, try removing the ampersand in the > > labels for "Close Window" and "Exit Dillo", in UI::make_menubar(). > > The latest snapshot, 6305. Same here... > Removing the ampersands == no more segfaults for me. Good, at least we have a workaround. -- Cheers Jorge.-

Sept. 29, 2008

segfault -- callback + closed window?

by Johannes.Hofmann＠gmx.de

Hi, On Mon, Sep 29, 2008 at 07:38:20PM +0000, corvid wrote: > I hit ',' a few times, going back past a page with a > big progressive jpeg webcomic, and hit ^Q to close the window > while dillo was thinking its way past that image. > I can reproduce a segfault with or without my close dialog patch. > Got: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 16384 (LWP 2782)] > 0x080fc708 in fltk::Widget::redraw (this=0x81cb680, flags=8 '\b') > at Widget.cxx:575 > 575 widget->damage_ |= DAMAGE_CHILD; > (gdb) bt > #0 0x080fc708 in fltk::Widget::redraw (this=0x81cb680, flags=8 '\b') > at Widget.cxx:575 > #1 0x0804f679 in UI::button_set_sens (this=0x82ce9d8, btn=UI_STOP, sens=0) > at ui.cc:1109 > #2 0x08054c59 in a_UIcmd_set_buttons_sens_cb (vbw=0x81ad858) at uicmd.cc:835 > #3 0x080e47f9 in fltk::wait () at TabGroup.cxx:116 > #4 0x080e489d in fltk::run () at TabGroup.cxx:116 > #5 0x0804efab in main (argc=1, argv=0xbffffb44) at dillo.cc:127 > > > Maybe that's just a part of life with callbacks... > Life is hard with callbacks, but I think it's just a bug :-) Cheers, Johannes

Sept. 29, 2008

segfault -- callback + closed window?

by corvid＠lavabit.com

Oh, and I want to make it clear that this has nothing to do with the patch Johannes just made which I haven't applied yet.

Sept. 29, 2008

segfault -- callback + closed window?

by corvid＠lavabit.com

I hit ',' a few times, going back past a page with a big progressive jpeg webcomic, and hit ^Q to close the window while dillo was thinking its way past that image. Got: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 2782)] 0x080fc708 in fltk::Widget::redraw (this=0x81cb680, flags=8 '\b') at Widget.cxx:575 575 widget->damage_ |= DAMAGE_CHILD; (gdb) bt #0 0x080fc708 in fltk::Widget::redraw (this=0x81cb680, flags=8 '\b') at Widget.cxx:575 #1 0x0804f679 in UI::button_set_sens (this=0x82ce9d8, btn=UI_STOP, sens=0) at ui.cc:1109 #2 0x08054c59 in a_UIcmd_set_buttons_sens_cb (vbw=0x81ad858) at uicmd.cc:835 #3 0x080e47f9 in fltk::wait () at TabGroup.cxx:116 #4 0x080e489d in fltk::run () at TabGroup.cxx:116 #5 0x0804efab in main (argc=1, argv=0xbffffb44) at dillo.cc:127 Maybe that's just a part of life with callbacks...

Sept. 29, 2008

patch: changeLinkColor

by Johannes.Hofmann＠gmx.de

On Sun, Sep 28, 2008 at 08:28:49PM +0000, corvid wrote: > Johannes wrote: > > BTW. with both implementations I now see issues with this example: > > > > <html> > > <body> > > <a href="http://www.dillo.org">dillo</a> > > <a href="http://slashdot.org">slashdot</a> > > <a href="http://www.dillo.org">dillo</a> > > </body> > > </html> > > > > When opening the first link in a new window, it doesn't change color > > in the original one. > > When opening it in a tab, the first one changes color. After a > > reload also the second one changes color. > > Am I missing something? > > Middle click changes the color for me whether it opens a tab or a window. > Sorry, only now I noticed that it only happens when opening the new window/tab via the "Link Options" menu. Cheers, Johannes

Sept. 29, 2008

patch: changeLinkColor

by Johannes.Hofmann＠gmx.de

On Sun, Sep 28, 2008 at 04:40:53PM -0400, Jorge Arellano Cid wrote: > On Sun, Sep 28, 2008 at 09:20:17PM +0200, Johannes Hofmann wrote: > > On Sun, Sep 28, 2008 at 02:54:56PM -0400, Jorge Arellano Cid wrote: > > > On Sun, Sep 28, 2008 at 05:55:10PM +0000, corvid wrote: > > > > Encouraged by the idea that I am going in the right direction, I have > > > > made a new one with spaceStyle: > > > > > > Funny how we were working on the same patch a the same time! > > > > > > I had an ancient version, and gave it a review. > > > The link search is linear inside textblock. A linux gazette page > > > showed more than 33000 words to color a link. On bigger pages it may be worst. > > > It depends on the structure. For instance our bookmarks uses tables > > > and the link is usually found in less than 10 words. > > > > > > The patch in CVS reduce the 35000 steps to 1500 or so (the > > > sorted link list is sparse, so there's a penalty for looking > > > for an actual link to compare to). > > > > > > > Not sure I understand this optimization. > > It is assuming that link numbers are always increasing, right? > > Right. > > > Can we assume this in dw/*? > > I checked html.cc and x_link is crescent. Not sure about the rest. > > > src/html.cc seems to be implemented currently in way that this is > > true. But perhaps we could/should reuse link numbers for equal > > destination urls in the future? > > In that case it'd need a revision. > > > Or someone might just choose hashes of the url string as link > > number. > > > > BTW. with both implementations I now see issues with this example: > > > > <html> > > <body> > > <a href="http://www.dillo.org">dillo</a> > > <a href="http://slashdot.org">slashdot</a> > > <a href="http://www.dillo.org">dillo</a> > > </body> > > </html> > > > > When opening the first link in a new window, it doesn't change color > > in the original one. > > When opening it in a tab, the first one changes color. After a > > reload also the second one changes color. > > Am I missing something? > > Yes, the link color change is meant as a visual cue for the user > to know the click is being processed. We could leave the link alone > and change the mouse cursor instead. > > The link not changing color when openning it with the menu > is IMO a bug, I'm looking for... > > BTW, the linear search patch is much simpler and as link > clicking is not a performance critical task it could be left > implemented in O(n). I prefer linear search. Once it really becomes a performance problem we can look for an optimization. Cheers, Johannes

Sept. 29, 2008

Window close dialog

by Johannes.Hofmann＠gmx.de

On Mon, Sep 29, 2008 at 11:12:39AM -0400, Jorge Arellano Cid wrote: > On Mon, Sep 29, 2008 at 04:03:55PM +0200, Johannes Hofmann wrote: > > Hi, > > > > On Mon, Sep 29, 2008 at 09:48:58AM -0400, Jorge Arellano Cid wrote: > > > Hi, > > > > > > Can somebody please make the dialog for closing a window > > > with tabs open? > > > > "Close Window" only closes the current tab anyway. > > Yes. > > > "Exit Dillo" closes all windows including tabs. > > So, do you think about a dialog in the "Exit Dillo" case when > > there is more than one tab or more than one window or both? > > Both, plus the window manager's "close window" if there're open Tabs. > > > Do we have the number of open windows somewhere? > > In bw.cc's num_bws. > Ok, please check attached patch. It relies on the current browser window to be stored in a window's user_data. We may want to reconsider this, but certainly not before the release. Cheers, Johannes

Sept. 29, 2008

what crashes remain?

by corvid＠lavabit.com

Jorge wrote: > On Mon, Sep 29, 2008 at 02:09:36PM +0000, corvid wrote: > > Jorge wrote: > > > On Sun, Sep 28, 2008 at 12:52:47AM +0000, corvid wrote: > > > > Playing with the file menu, I see that Alt-W, Alt-E, Alt-X, Alt-C > > > > all segfault. I thought somebody said something (that I didn't pay > > > > attention to) about the file menu since tabs were added, but if so, > > > > I can't find that mail. > > > > > > Please check the patch in CVS. > > > > > > FLTK2 has a bug in that it regards the first menu item letter as > > > a shortcut. > > > > > > Note: I tried with invisible shortcuts doing nothing, > > > removing shortcuts and all that stuff, until I found this way > > > to workaround the problem. > > > > > > Note2: Alt-W and Alt-X are accelerators, so they're OK. > > > > > > AFAIS there's no more segfault here. > > > > Alt-W and Alt-X still segfault for me. > > Hmm... > > What fltk version are you using? > > Anyway, as a workaround, try removing the ampersand in the > labels for "Close Window" and "Exit Dillo", in UI::make_menubar(). The latest snapshot, 6305. Removing the ampersands == no more segfaults for me.

Sept. 29, 2008

Window close dialog

by jcid＠dillo.org

On Mon, Sep 29, 2008 at 04:03:55PM +0200, Johannes Hofmann wrote: > Hi, > > On Mon, Sep 29, 2008 at 09:48:58AM -0400, Jorge Arellano Cid wrote: > > Hi, > > > > Can somebody please make the dialog for closing a window > > with tabs open? > > "Close Window" only closes the current tab anyway. Yes. > "Exit Dillo" closes all windows including tabs. > So, do you think about a dialog in the "Exit Dillo" case when > there is more than one tab or more than one window or both? Both, plus the window manager's "close window" if there're open Tabs. > Do we have the number of open windows somewhere? In bw.cc's num_bws. -- Cheers Jorge.-

Sept. 29, 2008

what crashes remain?

by jcid＠dillo.org

On Mon, Sep 29, 2008 at 02:09:36PM +0000, corvid wrote: > Jorge wrote: > > On Sun, Sep 28, 2008 at 12:52:47AM +0000, corvid wrote: > > > Playing with the file menu, I see that Alt-W, Alt-E, Alt-X, Alt-C > > > all segfault. I thought somebody said something (that I didn't pay > > > attention to) about the file menu since tabs were added, but if so, > > > I can't find that mail. > > > > Please check the patch in CVS. > > > > FLTK2 has a bug in that it regards the first menu item letter as > > a shortcut. > > > > Note: I tried with invisible shortcuts doing nothing, > > removing shortcuts and all that stuff, until I found this way > > to workaround the problem. > > > > Note2: Alt-W and Alt-X are accelerators, so they're OK. > > > > AFAIS there's no more segfault here. > > Alt-W and Alt-X still segfault for me. Hmm... What fltk version are you using? Anyway, as a workaround, try removing the ampersand in the labels for "Close Window" and "Exit Dillo", in UI::make_menubar(). > What's an accelerator? Kind of a shortcut that you set with an ampersand in the label of an fltk::Item. Disclaimer: "accelerator" may not be the correct name for it. -- Cheers Jorge.-

Sept. 29, 2008

what crashes remain?

by corvid＠lavabit.com

Jorge wrote: > On Sun, Sep 28, 2008 at 12:52:47AM +0000, corvid wrote: > > Playing with the file menu, I see that Alt-W, Alt-E, Alt-X, Alt-C > > all segfault. I thought somebody said something (that I didn't pay > > attention to) about the file menu since tabs were added, but if so, > > I can't find that mail. > > Please check the patch in CVS. > > FLTK2 has a bug in that it regards the first menu item letter as > a shortcut. > > Note: I tried with invisible shortcuts doing nothing, > removing shortcuts and all that stuff, until I found this way > to workaround the problem. > > Note2: Alt-W and Alt-X are accelerators, so they're OK. > > AFAIS there's no more segfault here. Alt-W and Alt-X still segfault for me. What's an accelerator?

Sept. 29, 2008

Window close dialog

by Johannes.Hofmann＠gmx.de

Hi, On Mon, Sep 29, 2008 at 09:48:58AM -0400, Jorge Arellano Cid wrote: > Hi, > > Can somebody please make the dialog for closing a window > with tabs open? "Close Window" only closes the current tab anyway. "Exit Dillo" closes all windows including tabs. So, do you think about a dialog in the "Exit Dillo" case when there is more than one tab or more than one window or both? Do we have the number of open windows somewhere? Cheers, Johannes

Sept. 29, 2008

Window close dialog

by jcid＠dillo.org

Hi, Can somebody please make the dialog for closing a window with tabs open? -- Cheers Jorge.-

Sept. 29, 2008

what crashes remain?

by jcid＠dillo.org

On Sun, Sep 28, 2008 at 12:52:47AM +0000, corvid wrote: > Johannes wrote: > > On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > > > I can't think of any other crashes, but I don't remember whether > > > Johannes still gets bus errors. > > > > No, they got fixed with > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-July/004649.html > > > > The only issues I'm seeing are the 128 tabs limit from fltk and the > > redraw storms related to the MenuTabPager. > > Playing with the file menu, I see that Alt-W, Alt-E, Alt-X, Alt-C > all segfault. I thought somebody said something (that I didn't pay > attention to) about the file menu since tabs were added, but if so, > I can't find that mail. Please check the patch in CVS. FLTK2 has a bug in that it regards the first menu item letter as a shortcut. Note: I tried with invisible shortcuts doing nothing, removing shortcuts and all that stuff, until I found this way to workaround the problem. Note2: Alt-W and Alt-X are accelerators, so they're OK. AFAIS there's no more segfault here. -- Cheers Jorge.-

Sept. 29, 2008

patch: show_msg=NO disable debug messages

by onepoint＠starurchin.org

On Thu, Sep 25, 2008 at 02:03:39PM -0400, Jorge Arellano Cid wrote: > In other words, for me, its OK to get rid of DEBUG_MSG unless > somebody else finds good use for it. I usually add my own debugging statements rather than use DEBUG_MSG . Maybe that says more about my ego than anything else :-) but FWIW I wouldn't miss DEBUG_MSG either. Regards, Jeremy Henty

Sept. 29, 2008

patch: changeLinkColor

by jcid＠dillo.org

On Sun, Sep 28, 2008 at 04:40:53PM -0400, Jorge Arellano Cid wrote: > On Sun, Sep 28, 2008 at 09:20:17PM +0200, Johannes Hofmann wrote: > > On Sun, Sep 28, 2008 at 02:54:56PM -0400, Jorge Arellano Cid wrote: > > > On Sun, Sep 28, 2008 at 05:55:10PM +0000, corvid wrote: > > > > Encouraged by the idea that I am going in the right direction, I have > > > > made a new one with spaceStyle: > > > > > > Funny how we were working on the same patch a the same time! > > > > > > I had an ancient version, and gave it a review. > > > The link search is linear inside textblock. A linux gazette page > > > showed more than 33000 words to color a link. On bigger pages it may be worst. > > > It depends on the structure. For instance our bookmarks uses tables > > > and the link is usually found in less than 10 words. > > > > > > The patch in CVS reduce the 35000 steps to 1500 or so (the > > > sorted link list is sparse, so there's a penalty for looking > > > for an actual link to compare to). > > > > > > > Not sure I understand this optimization. > > It is assuming that link numbers are always increasing, right? > > Right. > > > Can we assume this in dw/*? > > I checked html.cc and x_link is crescent. Not sure about the rest. > > > src/html.cc seems to be implemented currently in way that this is > > true. But perhaps we could/should reuse link numbers for equal > > destination urls in the future? > > In that case it'd need a revision. > > > Or someone might just choose hashes of the url string as link > > number. > > > > BTW. with both implementations I now see issues with this example: > > > > <html> > > <body> > > <a href="http://www.dillo.org">dillo</a> > > <a href="http://slashdot.org">slashdot</a> > > <a href="http://www.dillo.org">dillo</a> > > </body> > > </html> > > > > When opening the first link in a new window, it doesn't change color > > in the original one. > > When opening it in a tab, the first one changes color. After a > > reload also the second one changes color. > > Am I missing something? > > Yes, the link color change is meant as a visual cue for the user > to know the click is being processed. We could leave the link alone > and change the mouse cursor instead. > > The link not changing color when openning it with the menu > is IMO a bug, I'm looking for... It seems that carrying around widget, link and html->visited_color could do the trick. Maybe it's not worth the effort as the new window is enough visual feedback, and also the new tab... Comments? -- Cheers Jorge.-

Sept. 28, 2008

patch: changeLinkColor

by jcid＠dillo.org

On Sun, Sep 28, 2008 at 09:20:17PM +0200, Johannes Hofmann wrote: > On Sun, Sep 28, 2008 at 02:54:56PM -0400, Jorge Arellano Cid wrote: > > On Sun, Sep 28, 2008 at 05:55:10PM +0000, corvid wrote: > > > Encouraged by the idea that I am going in the right direction, I have > > > made a new one with spaceStyle: > > > > Funny how we were working on the same patch a the same time! > > > > I had an ancient version, and gave it a review. > > The link search is linear inside textblock. A linux gazette page > > showed more than 33000 words to color a link. On bigger pages it may be worst. > > It depends on the structure. For instance our bookmarks uses tables > > and the link is usually found in less than 10 words. > > > > The patch in CVS reduce the 35000 steps to 1500 or so (the > > sorted link list is sparse, so there's a penalty for looking > > for an actual link to compare to). > > > > Not sure I understand this optimization. > It is assuming that link numbers are always increasing, right? Right. > Can we assume this in dw/*? I checked html.cc and x_link is crescent. Not sure about the rest. > src/html.cc seems to be implemented currently in way that this is > true. But perhaps we could/should reuse link numbers for equal > destination urls in the future? In that case it'd need a revision. > Or someone might just choose hashes of the url string as link > number. > > BTW. with both implementations I now see issues with this example: > > <html> > <body> > <a href="http://www.dillo.org">dillo</a> > <a href="http://slashdot.org">slashdot</a> > <a href="http://www.dillo.org">dillo</a> > </body> > </html> > > When opening the first link in a new window, it doesn't change color > in the original one. > When opening it in a tab, the first one changes color. After a > reload also the second one changes color. > Am I missing something? Yes, the link color change is meant as a visual cue for the user to know the click is being processed. We could leave the link alone and change the mouse cursor instead. The link not changing color when openning it with the menu is IMO a bug, I'm looking for... BTW, the linear search patch is much simpler and as link clicking is not a performance critical task it could be left implemented in O(n). -- Cheers Jorge.-

Sept. 28, 2008

patch: changeLinkColor

by corvid＠lavabit.com

Johannes wrote: > BTW. with both implementations I now see issues with this example: > > <html> > <body> > <a href="http://www.dillo.org">dillo</a> > <a href="http://slashdot.org">slashdot</a> > <a href="http://www.dillo.org">dillo</a> > </body> > </html> > > When opening the first link in a new window, it doesn't change color > in the original one. > When opening it in a tab, the first one changes color. After a > reload also the second one changes color. > Am I missing something? Middle click changes the color for me whether it opens a tab or a window.

Sept. 28, 2008

patch: changeLinkColor

by Johannes.Hofmann＠gmx.de

On Sun, Sep 28, 2008 at 07:42:14PM +0000, corvid wrote: > Jorge wrote: > > On Sun, Sep 28, 2008 at 05:55:10PM +0000, corvid wrote: > > > Encouraged by the idea that I am going in the right direction, I have > > > made a new one with spaceStyle: > > > > Funny how we were working on the same patch a the same time! > > > > I had an ancient version, and gave it a review. > > The link search is linear inside textblock. A linux gazette page > > showed more than 33000 words to color a link. On bigger pages it may be worst. > > It depends on the structure. For instance our bookmarks uses tables > > and the link is usually found in less than 10 words. > > > > The patch in CVS reduce the 35000 steps to 1500 or so (the > > sorted link list is sparse, so there's a penalty for looking > > for an actual link to compare to). > > > > Please apply the spaceStyle part, and send it to me. > > Do we know that all of the (TEXT -- putting WIDGET aside for the moment) > contents of a link will have the same style? First likely example I could > come up with is how about in a utopian future dillo where tooltips are > implemented and there's an ABBR inside? Oh right. Just think about: <html> <body> <a href="http://slashdot.org">slash<b>dot</b></a> </body> </html> After clicking, the dot is no longer bold. Cheers, Johannes

Sept. 28, 2008

patch: changeLinkColor

by Johannes.Hofmann＠gmx.de

On Sun, Sep 28, 2008 at 02:54:56PM -0400, Jorge Arellano Cid wrote: > On Sun, Sep 28, 2008 at 05:55:10PM +0000, corvid wrote: > > Encouraged by the idea that I am going in the right direction, I have > > made a new one with spaceStyle: > > Funny how we were working on the same patch a the same time! > > I had an ancient version, and gave it a review. > The link search is linear inside textblock. A linux gazette page > showed more than 33000 words to color a link. On bigger pages it may be worst. > It depends on the structure. For instance our bookmarks uses tables > and the link is usually found in less than 10 words. > > The patch in CVS reduce the 35000 steps to 1500 or so (the > sorted link list is sparse, so there's a penalty for looking > for an actual link to compare to). > Not sure I understand this optimization. It is assuming that link numbers are always increasing, right? Can we assume this in dw/*? src/html.cc seems to be implemented currently in way that this is true. But perhaps we could/should reuse link numbers for equal destination urls in the future? Or someone might just choose hashes of the url string as link number. BTW. with both implementations I now see issues with this example: <html> <body> <a href="http://www.dillo.org">dillo</a> <a href="http://slashdot.org">slashdot</a> <a href="http://www.dillo.org">dillo</a> </body> </html> When opening the first link in a new window, it doesn't change color in the original one. When opening it in a tab, the first one changes color. After a reload also the second one changes color. Am I missing something? Cheers, Johannes

Sept. 28, 2008

what crashes remain?

by corvid＠lavabit.com

Jorge wrote: > On Sat, Sep 27, 2008 at 11:15:42PM +0000, corvid wrote: > > Jorge wrote: > > > On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > > > > It's still possible to crash dillo if you click on a remote link and > > > > quickly click on some images to load them. Doesn't crash every time, > > > > but typically within four tries or so. I had assumed it was the same > > > > thing as whatever was wrong with the menu crash, so I'd ignored it. > > > > > > > > If I stick > > > > a_Bw_stop_clients(bw, BW_Img); > > > > in the DilloHtml destructor, I can no longer get it to crash, but > > > > I randomly got a "Cache_process_queue Caught busy!!!" while browsing > > > > earlier today, so there's something wrong with just doing that. > > > > (Assuming it's related; I'm not in the habit of getting that MSG.) > > > > > > That message means big trouble: the event loop stepped over itself... > > > > > > I've tried several different ways but can't get to crash it. > > > > > > Does the attached patch help? > > > > Seems to be working well so far. > > Is there any danger in adding something like > > a_Nav_cancel_expect to a_UIcmd_stop()? > > What's the idea behind it? > > If you want to get rid of empty cache entries from > unsuccesful http connections, it's more complex than that. > BTW, I plan to do that after the release. I'm on page A. I try to go to page B, which seems to be taking a long time to think about resolving or contacting the host or whatever. I hit stop and go back to reading and want to continue loading images. Or if DNS couldn't resolve the hostname, I could hit stop to re-enable loading images.

Sept. 28, 2008

what crashes remain?

by jcid＠dillo.org

On Sat, Sep 27, 2008 at 11:15:42PM +0000, corvid wrote: > Jorge wrote: > > On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > > > It's still possible to crash dillo if you click on a remote link and > > > quickly click on some images to load them. Doesn't crash every time, > > > but typically within four tries or so. I had assumed it was the same > > > thing as whatever was wrong with the menu crash, so I'd ignored it. > > > > > > If I stick > > > a_Bw_stop_clients(bw, BW_Img); > > > in the DilloHtml destructor, I can no longer get it to crash, but > > > I randomly got a "Cache_process_queue Caught busy!!!" while browsing > > > earlier today, so there's something wrong with just doing that. > > > (Assuming it's related; I'm not in the habit of getting that MSG.) > > > > That message means big trouble: the event loop stepped over itself... > > > > I've tried several different ways but can't get to crash it. > > > > Does the attached patch help? > > Seems to be working well so far. > Is there any danger in adding something like > a_Nav_cancel_expect to a_UIcmd_stop()? What's the idea behind it? If you want to get rid of empty cache entries from unsuccesful http connections, it's more complex than that. BTW, I plan to do that after the release. > PS Stop should have a keyboard shortcut, I think. > I long had a reflex of hitting ESC from the netscape/mozilla > days, but of course ESC would be inconsistent for dillo. Could be. Maybe Ctrl-P. Although Stop is not yet doing exactly what it should. -- Cheers Jorge.-

Sept. 28, 2008

patch: changeLinkColor

by corvid＠lavabit.com

I wrote: > The registerName is because html.cc needs to have that working in > order to call changeLinkColor. By the way, in addition to html.cc, instanceOf is used in Textblock::addParbreak(). Perhaps we will see some effect from this.

Sept. 28, 2008

patch: changeLinkColor

by corvid＠lavabit.com

Johannes wrote: > On Sun, Sep 28, 2008 at 06:00:20AM +0000, corvid wrote: > > I just took the 0.8.6 version and replaced everything in it with > > dillo2 versions. (well, then had to add in the widget part) > > The fact that it seems to be working is kind of shocking. > > > > As for whether this is still the right way to do it, I leave this > > matter for the experts. > > Not that I'm an expert, but it looks right to me. It looks like it still needs to change spaceStyle. I wonder why spaceStyle is necessary... something to do with CSS?

Sept. 28, 2008

panel_size=small hides the menubar

by onepoint＠starurchin.org

On Sun, Sep 28, 2008 at 08:27:28AM -0400, Jorge Arellano Cid wrote: > On Sun, Sep 28, 2008 at 12:58:17PM +0100, Jeremy Henty wrote: > > > > If I add "panel_size=small" to ~/.dillo/dillo2rc then the menubar > > disappears! Huh? (~/.dillo/dillo2rc is otherwise identical to > > the default /etc/dill2rc) > > Well, more or less that's the idea with tiny, small and medium. Oh, I see! I was thinking of "the panel" as referring to just the button bar rather than the whole set of controls at the top. It makes more sense now but it's still a little surprising: I would expect a change of size specification to do nothing more than change the size of things, not make some of them disappear. > Whereas it has an inconsistency with the "show_menubar" preference, > that's happily ignored by the code. > > This should be corrected into a consistent and easy to use model. I would say that it would be simpler and more consistent to make "show_menubar" the only thing that determines whether the menubar is shown, and make "panel_size" affect nothing except the sizes of things. *If* there's an opportunity for a more radical change before release, why not move the File menubutton into the button bar (perhaps with a vertical divider to set them apart)? IMHO it's very ugly to have the File button sitting all alone at the top, wasting all that precious vertical whitespace for just one button! (That's why I only just noticed the menubar had gone, I normally turn it off anyway.) Regards, Jeremy Henty

Sept. 28, 2008

panel_size=small hides the menubar

by jcid＠dillo.org

On Sun, Sep 28, 2008 at 12:58:17PM +0100, Jeremy Henty wrote: > > If I add "panel_size=small" to ~/.dillo/dillo2rc then the menubar > disappears! Huh? (~/.dillo/dillo2rc is otherwise identical to the > default /etc/dill2rc) Well, more or less that's the idea with tiny, small and medium. Whereas it has an inconsistency with the "show_menubar" preference, that's happily ignored by the code. This should be corrected into a consistent and easy to use model. -- Cheers Jorge.-

Sept. 28, 2008

panel_size=small hides the menubar

by onepoint＠starurchin.org

If I add "panel_size=small" to ~/.dillo/dillo2rc then the menubar disappears! Huh? (~/.dillo/dillo2rc is otherwise identical to the default /etc/dill2rc) Regards, Jeremy Henty

Sept. 28, 2008

patch: changeLinkColor

by Johannes.Hofmann＠gmx.de

On Sun, Sep 28, 2008 at 06:00:20AM +0000, corvid wrote: > I just took the 0.8.6 version and replaced everything in it with > dillo2 versions. (well, then had to add in the widget part) > The fact that it seems to be working is kind of shocking. > > As for whether this is still the right way to do it, I leave this > matter for the experts. Not that I'm an expert, but it looks right to me. Cheers, Johannes

Sept. 28, 2008

patch: changeLinkColor

by corvid＠lavabit.com

I just took the 0.8.6 version and replaced everything in it with dillo2 versions. (well, then had to add in the widget part) The fact that it seems to be working is kind of shocking. As for whether this is still the right way to do it, I leave this matter for the experts. The registerName is because html.cc needs to have that working in order to call changeLinkColor.

Sept. 28, 2008

what crashes remain?

by corvid＠lavabit.com

Johannes wrote: > On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > > I can't think of any other crashes, but I don't remember whether > > Johannes still gets bus errors. > > No, they got fixed with > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-July/004649.html > > The only issues I'm seeing are the 128 tabs limit from fltk and the > redraw storms related to the MenuTabPager. Playing with the file menu, I see that Alt-W, Alt-E, Alt-X, Alt-C all segfault. I thought somebody said something (that I didn't pay attention to) about the file menu since tabs were added, but if so, I can't find that mail.

Sept. 28, 2008

what crashes remain?

by corvid＠lavabit.com

Jorge wrote: > On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > > It's still possible to crash dillo if you click on a remote link and > > quickly click on some images to load them. Doesn't crash every time, > > but typically within four tries or so. I had assumed it was the same > > thing as whatever was wrong with the menu crash, so I'd ignored it. > > > > If I stick > > a_Bw_stop_clients(bw, BW_Img); > > in the DilloHtml destructor, I can no longer get it to crash, but > > I randomly got a "Cache_process_queue Caught busy!!!" while browsing > > earlier today, so there's something wrong with just doing that. > > (Assuming it's related; I'm not in the habit of getting that MSG.) > > That message means big trouble: the event loop stepped over itself... > > I've tried several different ways but can't get to crash it. > > Does the attached patch help? Seems to be working well so far. Is there any danger in adding something like a_Nav_cancel_expect to a_UIcmd_stop()? PS Stop should have a keyboard shortcut, I think. I long had a reflex of hitting ESC from the netscape/mozilla days, but of course ESC would be inconsistent for dillo.

Sept. 28, 2008

what crashes remain?

by jcid＠dillo.org

On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > It's still possible to crash dillo if you click on a remote link and > quickly click on some images to load them. Doesn't crash every time, > but typically within four tries or so. I had assumed it was the same > thing as whatever was wrong with the menu crash, so I'd ignored it. > > If I stick > a_Bw_stop_clients(bw, BW_Img); > in the DilloHtml destructor, I can no longer get it to crash, but > I randomly got a "Cache_process_queue Caught busy!!!" while browsing > earlier today, so there's something wrong with just doing that. > (Assuming it's related; I'm not in the habit of getting that MSG.) That message means big trouble: the event loop stepped over itself... I've tried several different ways but can't get to crash it. Does the attached patch help? -- Cheers Jorge.-

Sept. 27, 2008

Dillo in OSX

by jcid＠dillo.org

On Sat, Sep 27, 2008 at 09:33:59PM +0200, Johannes Hofmann wrote: > On Thu, Sep 04, 2008 at 04:09:30PM -0400, Jorge Arellano Cid wrote: > > On Wed, Sep 03, 2008 at 06:28:49PM +0200, Johannes Hofmann wrote: > > > On Tue, Sep 02, 2008 at 09:20:03AM -0400, Jorge Arellano Cid wrote: > > > > On Mon, Sep 01, 2008 at 01:42:26PM +0200, Johannes Hofmann wrote: > > > > > Hi Jorge, > > > > > > > > > > how did You setup the OSX box to get a compiler and header files? > > > > > Did You install that huge XCode stuff, or is there another way? > > > > > I may get access to an OSX box to try dillo on it. > > > > > > > > How do I disable the double-buffer? > > > > > > Use the --disable-doublebuffer option when configuring dw2. > > > > Oh, yes, I forgot... > > (tried running ./configure --help in dillo2 not dw2) > > > > > > I tried dillo "as is" with clear_double_buffer() and without it, > > > > and the result is the same... > > > > > > Yeah, dw2 implements doublebuffering internally, so that does not > > > make a difference. > > > > I'll have access to that machine again sarting on September 12. > > > > Just tried current dillo on OSX with --disable-doublebuffer. It > works ok with some issues: > > * Some of the buttens disapear from time to time (Back > button for example). > > * The font size seems a bit too large so that there is not enough > space between words and lines. > > * Incoming data does not reliably trigger a page update. An > additional event like a mouse movement is necessary. > > Apart from that it's quite nice. Tabs are working fine. Oh, sorry, I forgot to tell you. That's exactly what I saw when testing without double buffer. -- Cheers Jorge.-

Sept. 27, 2008