- Dillo-dev - lists.mailman3.com

[patch]: html.cc: DilloHtmlForm::getCurrentInput()

by onepoint＠starurchin.org

This refactors DilloHtmlForm code into a new "inline DilloHtmlInput *getCurrentInput()" method. It's just like the earlier patch that created DilloHtml::getCurrentForm() . Comments are welcome, although I hope it is uncontroversial. Regards, Jeremy Henty

May 27, 2008

[patch]: html.cc cleanup: DilloHtml::currentForm()

by corvid＠lavabit.com

> corvid wrote: > > > I just remembered that inputs don't have to be in forms according to > > the spec, > > Ouch, yes. I guess this is because JavaScript can read inputs > whether or not they are inside a form? Yes, although I ran into it when I was looking up information about inputs. The pages liked to show examples of them, but dillo would give me bug meter messages instead.

May 26, 2008

Re: (working) prototype of charset decoding in cache.c

by corvid＠lavabit.com

Jorge wrote: > > But I mean it finishes seeing the first head, enables view source, > > user views the source, and then the charset in the second head causes > > a repush. Is the parser avoiding that? > > Yes, once you are IN_BODY, HEAD can't be re-opened, > and META doesn't work outside HEAD. But if I give it a page containing <html> <head> <title>first head</title> </head> <body> body </body> <head> <meta http-equiv="content-type" content="text/html; charset=iso-8859-1"> </head> </html> I get .. META Content-Type changes charset to: iso-8859-1 .. META Content-Type gave charset as: iso-8859-1 a_Nav_expect_done: repush! > I'd prefer to try the dpi before optimizing. I don't know dpis, so to me that's the difficult way...

May 26, 2008

[patch]: DilloHtmlForm class: WAS: Re: [Dillo-dev] [patch]: html.cc cleanup: DilloHtml::currentForm()

by jcid＠dillo.org

On Mon, May 26, 2008 at 09:07:46PM +0100, Jeremy Henty wrote: > > A revised version of the previous patch that applies cleanly against > the latest CVS. No other changes. Committed. -- Cheers Jorge.-

May 26, 2008

[patch]: html.cc cleanup: DilloHtml::currentForm()

by onepoint＠starurchin.org

corvid wrote: > I just remembered that inputs don't have to be in forms according to > the spec, Ouch, yes. I guess this is because JavaScript can read inputs whether or not they are inside a form? > ... so maybe it won't be as easy to move so much to form.cc (unless > form.cc is given an html-ui-widgety general sort of name...) I think the real obstacle is circular data structures and dependencies. DilloHtml objects have pointers to DilloHtmlForm objects, which have pointers to ::form::Form objects which in turn depend on DilloHtml objects. So the code can't be split up as it stands. My tentative solution is to factor things through APIs that treat pointers as black boxes. For example, "delete form_ptr;", which requires the DilloHtmlForm class definition, could be wrapped inside a function "Html_form_delete (DilloHtmlForm *form_ptr);", which only requires the declaration "class DilloHtmlForm;". I'm sure it can be done but it may be too messy to be worth doing. At the moment I am doing cleanups that I think are clearly worth doing anyway and hoping that they will also help us to split up html.cc in a useful way. Regards, Jeremy Henty

May 26, 2008

[patch]: DilloHtmlForm class: WAS: Re: [Dillo-dev] [patch]: html.cc cleanup: DilloHtml::currentForm()

by onepoint＠starurchin.org

A revised version of the previous patch that applies cleanly against the latest CVS. No other changes. Jeremy Henty

May 26, 2008

Re: (working) prototype of charset decoding in cache.c

by jcid＠dillo.org

On Mon, May 26, 2008 at 07:31:14PM +0000, corvid wrote: > Jorge wrote: > > On Mon, May 26, 2008 at 03:01:53PM +0000, corvid wrote: > > > > > [...] > > > > > - a_Cache_[gs]et_content_type and capi and nav. Ugh again. > > > > > I don't know whether there's a timing issue with changing decoders > > > > > due to a meta tag at the same time that a view source window is being > > > > > opened. > > > > > > > > Yes there is. > > > > > > > > Simple to solve by allowing view source after parsing the HEAD > > > > element only. > > > > > > Do you think badly-formed html with, e.g., > > > <head>..</head><body>...</body><head><meta..charset..></head> <body>...</body> > > > is worth worrying about? > > > > This is already handled in the parser. > > But I mean it finishes seeing the first head, enables view source, > user views the source, and then the charset in the second head causes > a repush. Is the parser avoiding that? Yes, once you are IN_BODY, HEAD can't be re-opened, and META doesn't work outside HEAD. > > But now that you mention this, we have to be careful with > > reload. It deletes the entry from the cache before making the > > request. > > > > A simple solution is just to close the view-source window in > > this corner case. > > Ah, yes. Stupid corner cases! :) > > > I was saying that I was pushing around content-type instead of charset > > > because I liked changing it to text/plain in the dialog. > > > If there's no dialog, maybe I'll go back to charset. > > > > > > "View source" as a bw is not a bad idea. It reuses code and > > adds findtext for free, but currently loses the line numbers. > > (which match nicely with the bug meter). > > > > This is a separate problem. > > > > One way to have both features in "View source" is with a dpi > > that gets the source from dillo and sends back an html page. The > > simple way is to prefix line numbers and wrap with PRE. > > > > It can be sent with a no-cache directive, or removed from cache > > upon window close. > > > > The problem of sending back and forth a huge page may be not > > as bad as it looks because huge pages are seldom inspected for > > source from a browser, and it can be handled anyway. > > Maybe adding a callback that stuffs in line numbers before going into > the regular plain callback would work and be tiny. > a_Capi_open_url(Web, our_special_callback, ...) > Oh well, I realize it's premature to dream too hard about > this at this point :) I'd prefer to try the dpi before optimizing. Having one path helps a lot with... Oh, I already gave that lines. ;) The ones that read the paper, please raise your hands. :-) -- Cheers Jorge.-

May 26, 2008

[patch]: html.cc cleanup: DilloHtml::currentForm()

by corvid＠lavabit.com

I just remembered that inputs don't have to be in forms according to the spec, so maybe it won't be as easy to move so much to form.cc (unless form.cc is given an html-ui-widgety general sort of name...)

May 26, 2008

Re: (working) prototype of charset decoding in cache.c

by corvid＠lavabit.com

Jorge wrote: > On Mon, May 26, 2008 at 03:01:53PM +0000, corvid wrote: > > > > [...] > > > > - a_Cache_[gs]et_content_type and capi and nav. Ugh again. > > > > I don't know whether there's a timing issue with changing decoders > > > > due to a meta tag at the same time that a view source window is being > > > > opened. > > > > > > Yes there is. > > > > > > Simple to solve by allowing view source after parsing the HEAD > > > element only. > > > > Do you think badly-formed html with, e.g., > > <head>..</head><body>...</body><head><meta..charset..></head> <body>...</body> > > is worth worrying about? > > This is already handled in the parser. But I mean it finishes seeing the first head, enables view source, user views the source, and then the charset in the second head causes a repush. Is the parser avoiding that? > But now that you mention this, we have to be careful with > reload. It deletes the entry from the cache before making the > request. > > A simple solution is just to close the view-source window in > this corner case. Ah, yes. Stupid corner cases! > > I was saying that I was pushing around content-type instead of charset > > because I liked changing it to text/plain in the dialog. > > If there's no dialog, maybe I'll go back to charset. > > > "View source" as a bw is not a bad idea. It reuses code and > adds findtext for free, but currently loses the line numbers. > (which match nicely with the bug meter). > > This is a separate problem. > > One way to have both features in "View source" is with a dpi > that gets the source from dillo and sends back an html page. The > simple way is to prefix line numbers and wrap with PRE. > > It can be sent with a no-cache directive, or removed from cache > upon window close. > > The problem of sending back and forth a huge page may be not > as bad as it looks because huge pages are seldom inspected for > source from a browser, and it can be handled anyway. Maybe adding a callback that stuffs in line numbers before going into the regular plain callback would work and be tiny. a_Capi_open_url(Web, our_special_callback, ...) Oh well, I realize it's premature to dream too hard about this at this point :)

May 26, 2008

[patch]: html.cc cleanup: DilloHtml::currentForm()

by onepoint＠starurchin.org

On Mon, May 26, 2008 at 02:57:09PM -0400, Jorge Arellano Cid wrote: > Committed as: > > inline DilloHtmlForm *getCurrentForm (); Cool, but that name change will break the second patch I just submitted. :-( I'll resubmit a fixed version. Regards, Jeremy Henty

May 26, 2008