- Dillo-dev - lists.mailman3.com

patch: multipart/form-data encoding for form submission

by place＠gobigwest.com

Jorge wrote: > On Fri, Feb 29, 2008 at 06:19:31PM +0000, place wrote: > > Jorge wrote: > > > > > > > - This patch always uses the same boundary, but a different > > > > one REALLY should be used for every form submission. At > > > > the least, the string should be scrambled up somehow. > > > > > > Yes, please finish that part. > > > > > > Probably checking the boundary string against URL_DATA, > > > with strstr is a good idea too. > > > > Attached. > > > > I'm not proud of this code, but special cases > > were getting in the way of attempts at cleanup. > > Have you tried something like?: > > </pseudocode> > > Html_submit_form2() > ... > if (ENC_MULTIPART) { > append every single "name" "value" pair into a Dstr > do { > make boundary > } while (strstr(Dstr, boundary) || maxtries); > } > ... > encode as usual. > > </pseudocode> > > If yes, why does it fail? I hadn't looked at that specifically. Let's see... To avoid duplicating the big case statement, I'd want to make a char *Html_get_input_value(input) { switch (input->type) { ... } return value; } if (ENC_MULTIPART) { for (each input in the form) { value = Html_get_input_value(input); dStr_append(data, name); dStr_append(data, value); } ...boundary... etc. ... } But for a file input, it could have embedded nulls, so make Html_get_input_value() return a Dstr* instead. Okay. But for an image input, thanks to clickpos, I'd have to make it return a list of name/value pairs. Maybe that's not too bad, but it does put me in a bit of a "stupid HTML and its stupid special cases!" mood. Random thought: I wonder whether url->data gets eradicated after sending somehow, or if copies of it stick around in copies of the url on, I don't know, the nav stack or whatever. If there are copies floating around, that'll be no fun if they were each to contain a big file input in their data. > PS: I usually manually delete the CC of my replies to you, thinking > that you'll get it from dillo-dev. Do you want the extra copy? I know someone who, when cc:ed, tends to say "I read the list" :)

Feb. 29, 2008

patch: multipart/form-data encoding for form submission

by jcid＠dillo.org

On Fri, Feb 29, 2008 at 06:19:31PM +0000, place wrote: > Jorge wrote: > > > > > - This patch always uses the same boundary, but a different > > > one REALLY should be used for every form submission. At > > > the least, the string should be scrambled up somehow. > > > > Yes, please finish that part. > > > > Probably checking the boundary string against URL_DATA, > > with strstr is a good idea too. > > Attached. > > I'm not proud of this code, but special cases > were getting in the way of attempts at cleanup. Have you tried something like?: </pseudocode> Html_submit_form2() ... if (ENC_MULTIPART) { append every single "name" "value" pair into a Dstr do { make boundary } while (strstr(Dstr, boundary) || maxtries); } ... encode as usual. </pseudocode> If yes, why does it fail? -- Cheers Jorge.- PS: I usually manually delete the CC of my replies to you, thinking that you'll get it from dillo-dev. Do you want the extra copy?

Feb. 29, 2008

patch: multipart/form-data encoding for form submission

by place＠gobigwest.com

Jorge wrote: > > > - This patch always uses the same boundary, but a different > > one REALLY should be used for every form submission. At > > the least, the string should be scrambled up somehow. > > Yes, please finish that part. > > Probably checking the boundary string against URL_DATA, > with strstr is a good idea too. Attached. I'm not proud of this code, but special cases were getting in the way of attempts at cleanup.

Feb. 29, 2008

[patch] redraw optimization now including tables

by jcid＠dillo.org

Hi, > > [...] > > From a distance it looks like a conditionalRedraw() may be the needed call > > (I don't know well what expose means). I mean if this conditional redraw > > sees that nothing has changed in the specified area, it can simply return, > > otherwise redraw. > > Yes, that's the idea of the new virtual method resizeDrawImpl(). > Each widget can remember what has already been drawn and what might > have changed because of resizes and then draw only the necessary > parts. It depends on each widget how careful it is. > Tables have the unfortunate property of changing their layout all over > when new cells are added thereby requiring complete redraws. We may track the colWidths vector. If it doesn't change, layout is kept. > > > The redrawing is left > > > to the Table-code, which then can be optimized. > > > Please test carefully and report any anomalies you find. > > > > I haven't found any anomalies. :-) > > Excellent. Then please commit this one. I will try to improve upon > this. Patch committed. Thanks for the explanations. I'll give it some testing when having some time. -- Cheers Jorge.-

Feb. 29, 2008

[patch] use CURSOR_MOVE when drag scrolling

by jcid＠dillo.org

Hi, > the patch below disallows drag scrolling over links where the middle > mouse button is used to open the link in a new window. It also > changes the cursor to CURSOR_MOVE when drag scrolling. Committed. -- Cheers Jorge.-

Feb. 29, 2008

Re: patch: not-a-png message

by jcid＠dillo.org

On Fri, Feb 29, 2008 at 04:42:05PM +0000, place wrote: > Just noticed this in my tree while making multipart diffs. I'd forgotten > about it... Committed. -- Cheers Jorge.-

Feb. 29, 2008

[patch] redraw optimization now including tables

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Fri, Feb 29, 2008 at 10:18:45AM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > On Wed, Feb 27, 2008 at 05:56:36PM +0100, Johannes Hofmann wrote: > > Hello, > > > > below is an improved version of the redraw optimization. It now also > > covers table based pages - at least to some point. > > Yes, in fact it avoids redraws on the test posted in my last email. > If I give that test another page, e.g. www.gnu-darwin.org/update.html, > it can also avoid _some_ redraws. So the partial optimization seems to > be working. Yes, the patch only tries to avoid redraws that change nothing on the screen. For complex tables that get rearranged all the time while loading, there is still a lot of redraws. However there is certainly room for improvement. For the fun of it, you can comment out the lines in table.hh where redrawY gets reset. That saves a lot of redraws at the cost of some anomalies... > > > The challenge is to make the already commited optimization work > > recursively. > > Do you want me to commit this new patch, or to keep the already > committed one? > > > > Other than I originally thought topLevel is always a > > Textblock. Table based pages simply consist of a Textblock with a > > huge Table as child widget. Textblock now needs to avoid redrawing > > the child area when the table size increases. > > AFAIU textblock draws by lines and as the first line is a huge table > it requests a redraw of it. With this patch it does not. It leaves the drawing of the table to the table code. > > I don't know yet why textblock is requesting a redraw; I assume that > as the table size changed, textblock gets notified and as it doesn't > know better it asks the child widgets for a full redraw. If the resizing does not change anything that is actually drawn by the Textblock (like real text), it does not need to request a redraw. > > From a distance it looks like a conditionalRedraw() may be the needed call > (I don't know well what expose means). I mean if this conditional redraw > sees that nothing has changed in the specified area, it can simply return, > otherwise redraw. Yes, that's the idea of the new virtual method resizeDrawImpl(). Each widget can remember what has already been drawn and what might have changed because of resizes and then draw only the necessary parts. It depends on each widget how careful it is. Tables have the unfortunate property of changing their layout all over when new cells are added thereby requiring complete redraws. > > > > The redrawing is left > > to the Table-code, which then can be optimized. > > Please test carefully and report any anomalies you find. > > I haven't found any anomalies. :-) Excellent. Then please commit this one. I will try to improve upon this. Cheers, Johannes > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 29, 2008

[patch] add ctrl-f shortcut for findText

by jcid＠dillo.org

On Thu, Feb 28, 2008 at 10:46:40PM +0100, Johannes Hofmann wrote: > Hi, > > patch below adds ctrl-f shortcut for findText. > BTW, shouldn't ctrl-b open the bookmarks page as it did > in dillo1? Yes, both shortcuts committed. -- Cheers Jorge.-

Feb. 29, 2008

[patch] redraw optimization now including tables

by jcid＠dillo.org

Hi Johannes, On Wed, Feb 27, 2008 at 05:56:36PM +0100, Johannes Hofmann wrote: > Hello, > > below is an improved version of the redraw optimization. It now also > covers table based pages - at least to some point. Yes, in fact it avoids redraws on the test posted in my last email. If I give that test another page, e.g. www.gnu-darwin.org/update.html, it can also avoid _some_ redraws. So the partial optimization seems to be working. > The challenge is to make the already commited optimization work > recursively. Do you want me to commit this new patch, or to keep the already committed one? > Other than I originally thought topLevel is always a > Textblock. Table based pages simply consist of a Textblock with a > huge Table as child widget. Textblock now needs to avoid redrawing > the child area when the table size increases. AFAIU textblock draws by lines and as the first line is a huge table it requests a redraw of it. I don't know yet why textblock is requesting a redraw; I assume that as the table size changed, textblock gets notified and as it doesn't know better it asks the child widgets for a full redraw. From a distance it looks like a conditionalRedraw() may be the needed call (I don't know well what expose means). I mean if this conditional redraw sees that nothing has changed in the specified area, it can simply return, otherwise redraw. > The redrawing is left > to the Table-code, which then can be optimized. > Please test carefully and report any anomalies you find. I haven't found any anomalies. :-) -- Cheers Jorge.-

Feb. 29, 2008

[patch] add ctrl-f shortcut for findText

by Johannes.Hofmann＠gmx.de

Hi, patch below adds ctrl-f shortcut for findText. BTW, shouldn't ctrl-b open the bookmarks page as it did in dillo1? Cheers, Johannes diff -r 44838cc1f38d src/ui.cc --- a/src/ui.cc Sun Feb 24 23:15:53 2008 +0100 +++ b/src/ui.cc Thu Feb 28 22:43:22 2008 +0100 @@ -702,7 +702,10 @@ int UI::handle(int event) // Handle these shortcuts here. if (event == SHORTCUT) { if (event_state(CTRL)) { - if (k == 'l') { + if (k == 'f') { + a_UIcmd_findtext_dialog((BrowserWindow*) user_data ()); + ret = 1; + } else if (k == 'l') { a_UIcmd_open_url_dialog(user_data()); ret = 1; } else if (k == 'n') {

Feb. 28, 2008