June 2008 - Dillo-dev - lists.mailman3.com

another segfault

by corvid＠lavabit.com

Johannes wrote: > On Sat, Jun 07, 2008 at 06:49:22PM -0400, Jorge Arellano Cid wrote: > > On Sat, Jun 07, 2008 at 02:24:09PM +0000, corvid wrote: > > > Johannes wrote: > > > > now I've got some more info on that problem. The buffer on which > > > > Html_write_raw is operating (0x285c8000 in this case) is free'd by > > > > a_Cache_set_content_type(). I don't understand the details though. > > > > Do you have an idea? > > > > > > Ah! Does this help? > > > > > > > > --- dillo2/src/html.cc 2008-06-05 14:06:50.000000000 +0000 > > > +++ dillo2-cur/src/html.cc 2008-06-07 14:16:37.000000000 +0000 > > > @@ -5449,6 +5449,9 @@ static void Html_process_tag(DilloHtml * > > > /* Call the open function for this tag */ > > > Tags[ni].open (html, tag, tagsize); > > > > > > + if (html->stop_parser) > > > + return; > > > + > > > /* Now parse attributes that can appear on any tag */ > > > if (tagsize >= 8 && /* length of "<t id=i>" */ > > > (attrbuf = Html_get_attr2(html, tag, tagsize, "id", > > > > > > I tried to simplify the code by avoiding a return point in the middle of > > the function. It took long to figure a way! > > > > Please test the patch in CVS. > > Are you sure it's in CVS? Current CVS still shows the bug. How is it breaking?

June 8, 2008

RFC: removing the search dialog

by weigelt＠metux.de

* Jorge Arellano Cid <jcid(a)dillo.org> schrieb: Hi, > I believe one of the important things that we could support is > custom keyboard shortcuts in dillorc. ACK. Maybe would should go the way Mutt does: it internally works with commands, and keystrokes are mapped to commands. Such an simple command interpreter would be cool. If Dillo also provides an 9P server which publishes internal states and an command channel, it would be even cooler :) > * right-click context menus. > * providing some keyboard shortcuts. Both should be configurable. > AFAICS multiple dillorc files are simpler. ACK cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 8, 2008

recent style/layout segfaults

by Johannes.Hofmann＠gmx.de

On Sat, Jun 07, 2008 at 10:16:14PM +0000, corvid wrote: > Johannes wrote: > > Comments welcome! I feel a bit uncomfortable proposing a > > pretty drastic change like this. > > Although obviously I don't know the code well, it seems like an improvement. > > PS Jeremy's new html.cc is in CVS now, so the dillo2 part of the patch > no longer applies very cleanly. Ah ok. I updated the dillo2 part: http://www.ecademix.com/JohannesHofmann/tmp/layoutless_style.dillo2

June 8, 2008

another segfault

by Johannes.Hofmann＠gmx.de

On Sat, Jun 07, 2008 at 06:49:22PM -0400, Jorge Arellano Cid wrote: > On Sat, Jun 07, 2008 at 02:24:09PM +0000, corvid wrote: > > Johannes wrote: > > > now I've got some more info on that problem. The buffer on which > > > Html_write_raw is operating (0x285c8000 in this case) is free'd by > > > a_Cache_set_content_type(). I don't understand the details though. > > > Do you have an idea? > > > > Ah! Does this help? > > > > > --- dillo2/src/html.cc 2008-06-05 14:06:50.000000000 +0000 > > +++ dillo2-cur/src/html.cc 2008-06-07 14:16:37.000000000 +0000 > > @@ -5449,6 +5449,9 @@ static void Html_process_tag(DilloHtml * > > /* Call the open function for this tag */ > > Tags[ni].open (html, tag, tagsize); > > > > + if (html->stop_parser) > > + return; > > + > > /* Now parse attributes that can appear on any tag */ > > if (tagsize >= 8 && /* length of "<t id=i>" */ > > (attrbuf = Html_get_attr2(html, tag, tagsize, "id", > > > I tried to simplify the code by avoiding a return point in the middle of > the function. It took long to figure a way! > > Please test the patch in CVS. Are you sure it's in CVS? Current CVS still shows the bug. Cheers, Johannes

June 8, 2008

Small html and form cleanups

by onepoint＠starurchin.org

How about some *small* patches for a change? :-) * "a_Html_free()" is only used in html.cc , so change it to "static Html_free()". * The form argument of Html_input _image is unused, so delete it. * The html.cc code that uses debug.h has moved to form.cc , so remove the '#include "debug.h"' and move the '#define DEBUG_LEVEL'. Regards, Jeremy Henty

June 8, 2008

patch: image input data submission

by jcid＠dillo.org

On Sat, Jun 07, 2008 at 11:59:00PM +0000, corvid wrote: > For image inputs, the dillo1 code would send > name=value > name.x=x-coord > name.y=y-coord > > When I was getting this working for dillo2, I was uncertain whether > name=value should be in there > (http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-April/004085.html) > I saw that firefox didn't send it, but I left it alone, since including it > shouldn't hurt anything. > > I later saw that it was clearer in html3.2: > "The x and y values of the location clicked are passed to the server: In > the submitted data, image fields are included as two name/value pairs. The > names are derived by taking the name of the field and appending ".x" for > the x value, and ".y" for the y value." > > and just as clear as day in "web forms 2.0": > "Image buttons, during this step, must be handled as if they were two > controls, one with the control's name with .x appended, whose value is > the x coordinate selected by the user, and the other with the control's > name with .y appended, whose value is the y coordinate selected by the > user. If the control's name is the empty string (e.g. if the name attribute > is omitted) then the names x and y must be used instead." > > > So I'll sneak in a patch before Jeremy gets back to form cleanup. > (All that actually changes in buildQueryData() is that the > DILLO_HTML_INPUT_IMAGE case goes up above Html_get_input_values() ) > Committed. -- Cheers Jorge.-

June 8, 2008

patch: image input data submission

by corvid＠lavabit.com

For image inputs, the dillo1 code would send name=value name.x=x-coord name.y=y-coord When I was getting this working for dillo2, I was uncertain whether name=value should be in there (http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-April/004085.html) I saw that firefox didn't send it, but I left it alone, since including it shouldn't hurt anything. I later saw that it was clearer in html3.2: "The x and y values of the location clicked are passed to the server: In the submitted data, image fields are included as two name/value pairs. The names are derived by taking the name of the field and appending ".x" for the x value, and ".y" for the y value." and just as clear as day in "web forms 2.0": "Image buttons, during this step, must be handled as if they were two controls, one with the control's name with .x appended, whose value is the x coordinate selected by the user, and the other with the control's name with .y appended, whose value is the y coordinate selected by the user. If the control's name is the empty string (e.g. if the name attribute is omitted) then the names x and y must be used instead." So I'll sneak in a patch before Jeremy gets back to form cleanup. (All that actually changes in buildQueryData() is that the DILLO_HTML_INPUT_IMAGE case goes up above Html_get_input_values() )

June 8, 2008

another segfault

by jcid＠dillo.org

On Sat, Jun 07, 2008 at 02:24:09PM +0000, corvid wrote: > Johannes wrote: > > now I've got some more info on that problem. The buffer on which > > Html_write_raw is operating (0x285c8000 in this case) is free'd by > > a_Cache_set_content_type(). I don't understand the details though. > > Do you have an idea? > > Ah! Does this help? > > --- dillo2/src/html.cc 2008-06-05 14:06:50.000000000 +0000 > +++ dillo2-cur/src/html.cc 2008-06-07 14:16:37.000000000 +0000 > @@ -5449,6 +5449,9 @@ static void Html_process_tag(DilloHtml * > /* Call the open function for this tag */ > Tags[ni].open (html, tag, tagsize); > > + if (html->stop_parser) > + return; > + > /* Now parse attributes that can appear on any tag */ > if (tagsize >= 8 && /* length of "<t id=i>" */ > (attrbuf = Html_get_attr2(html, tag, tagsize, "id", I tried to simplify the code by avoiding a return point in the middle of the function. It took long to figure a way! Please test the patch in CVS. -- Cheers Jorge.-

June 8, 2008

recent style/layout segfaults

by corvid＠lavabit.com

Johannes wrote: > Comments welcome! I feel a bit uncomfortable proposing a > pretty drastic change like this. Although obviously I don't know the code well, it seems like an improvement. PS Jeremy's new html.cc is in CVS now, so the dillo2 part of the patch no longer applies very cleanly.

June 8, 2008

RFC: removing the search dialog

by jcid＠dillo.org

Hi, Finally I got some time to answer this subject that needs some thought. > [Justus wrote:] > I was thinking about improving the dillo experience by adding some > functionality / shortcuts people have come to expect. But what people > expect is influenced by their background, their choice of desktop > environment and platform. Yes, the main point is different people like things in different ways. If we can provide a simple way to do things and offer the possibility to customize _some_ things, better. I believe one of the important things that we could support is custom keyboard shortcuts in dillorc. There are different shortcut sets, hardcoded into the user's brain, and they depend on what apps. the person is accustomed to use. For instance, if I've been using an editor where the "find text" function is F3, I'd like to have F3 do the same in dillo. > [Justus wrote:] > We could pick one / some user interface guideline(s) ([1] lists some) > and try to adhere to it / them. Or we could pick one popular browser and > copy its 'feel'. Dillo has come to have it's own "simple" feel, and users have been communicative in making clear they like it. Now that we changed the UI, we have to define some things though. The basic model behind dillo is simplicity achieved with: * right-click context menus. * providing some keyboard shortcuts. As stated before, we can improve it by allowing custom keybindings. On Sat, May 24, 2008 at 04:44:32AM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey :) > > I hacked up opera (at least I _think_ they do it this way) style search > engine handling. I am not too happy with what I did to the config file > parser, but it works for now :). I like the idea of having multiple search engines. As a matter of fact since some years (But manpower/priorities etc...). Well, the CLI is mainly for advanced users, and I'd like to provide a UI that's orthogonal with what we have before tackling a CLI. For instance, the same search engines can be listed from a right-click menu on the search button. e.g. .------------------. . Google . . Wikipedia . . Free Dictionary . . Linux Packages . . SomeWhere Else . '------------------' Now, if a dialog pops-up: .-------------------------------------. . Search Wikipedia: . . [ ] . . [Cancel] [OK] . '-------------------------------------' it'd be quite simple and mnemonic. OTOH, if instead of dialog, the Location bar is focused, it'd not be clear for a new user whether it is for an URL or a new text string. The pop-up provides enough clues. If the pop-up dialog is to be avoided, it'd be nice to have it displaying the same information in the panel, perhaps hiding the navigation buttons. .----------------------------------------------------------------------. . Search Wikipedia: . . [ ] [P] . '----------------------------------------------------------------------' (now we have enough visual clues) Why up and not down like findtext, because that way is easier to tell web searching from page searching (I used to make that mistake a lot! :-) BTW, I don't yet know why avoiding pop-up dialogs is considered good. Don't get me wrong, I prefer the find text bar as it is now, but for other things, I don't yet see the problem. For instance on popup dialogs, messages and inputs. <topic change> Ctrl-X shortcuts in menus: This is another topic that needs feedback. The simplicity of current right-click menus is nice, but they don't provide mnemonic feedback on what shortcuts the listed items have. Probably having the shortcuts listed outclasses the readability, and they should be back, together with a shortcut customization scheme. > I am not sure what I would like to see, but for the moment I'd go with > dictionaries and the ability to include other files. This way we could > ship some config files (think browser personalities) and the user could > include the one he likes best and fine tune the settings in his personal > dillorc. AFAICS multiple dillorc files are simpler. > I was also unsure about the proper way to inform the user of errors and > I believe the reason for this is simply that there is no mechanism to do > this properly. Currently there are two ways: * pop-up dialog message. * status bar message. Openning a new dillo window with a custom HTML message is an option too. The advantages/disadvantages should be considered. For instance, with "view source", there's the clear advantage of having "find text" functionality for free. -- Cheers Jorge.-

June 7, 2008