- Dillo-dev - lists.mailman3.com

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

I'm feeling quite accomplished, then :-) I'll probably go in and work on it some more when I have time -- I'd like to get dpid, etc. to at least compile. I should also put together a README with info on the build process/dependencies since some of them are a little trickier than others. I suspect the HTTP problem is from the clumsy dFcntl() implementation; I'm not sure I implemented non-blocking IO correctly, and Win32 doesn't appear to support close-on-exec at all. I'll take another look at that later, since I really want this thing to work myself. Thanks for the feedback & cheers, ~Benjamin On Sat, 28 Aug 2010 04:15:37 -0400, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > Hi Benjamin, > > Cool! I just had a quick look over the patch and it looks pretty > clean. If someone is willing to make it work properly and to > maintain the Win32 port, I would like to see it committed to dillo > main line. > > Cheers, > Johannes

Aug. 28, 2010

Another (native) Dillo-Win32 patch

by Johannes.Hofmann＠gmx.de

Hi Benjamin, On Fri, Aug 27, 2010 at 08:12:24PM -0400, Benjamin Johnson wrote: > If anyone's interested, I've been working on a new patch to add native > Win32 support to Dillo 2.x. It needs attention for a more experienced > porter and is not yet ready for prime time, but it produces a running > dillo.exe and should provide a reasonable base for further efforts. > > More information is here: > http://obeythepenguin.users.sourceforge.net/dillo/ > > This is a complex patch that introduces several new low-level APIs, > mainly sockets-related. There are also some minor fixes to #include > paths and other such small changes. Cool! I just had a quick look over the patch and it looks pretty clean. If someone is willing to make it work properly and to maintain the Win32 port, I would like to see it committed to dillo main line. Cheers, Johannes

Aug. 28, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

If anyone's interested, I've been working on a new patch to add native Win32 support to Dillo 2.x. It needs attention for a more experienced porter and is not yet ready for prime time, but it produces a running dillo.exe and should provide a reasonable base for further efforts. More information is here: http://obeythepenguin.users.sourceforge.net/dillo/ This is a complex patch that introduces several new low-level APIs, mainly sockets-related. There are also some minor fixes to #include paths and other such small changes. Apologies for the long message -- I hope somebody finds this useful :-)

Aug. 28, 2010

Disable caching

by jcid＠dillo.org

On Wed, Aug 25, 2010 at 06:59:34PM +0000, corvid wrote: > Fredrik wrote: > > Hi, > > although caching mostly is good, there is serveral occasions when it's > > not wanted, specially with todays web2.0-concepts (user generated pages, > > etc.). > > > > Is there a way to disable caching in dillo? Maybe only for some sites? > > > > I've searched the archives and found a patch doing this, it was however > > dated back in 2003. So I'm intrested in som up-to-date information. > > To the best of my knowledge, > - no one is working on it > - but a good patch would be gladly accepted. > > Was there any discussion in the archive on why the 2003 patch wasn't > integrated? AFAIR, at that time most of the no-cache directives were used to refresh advertising, and some sites did it by refreshing the main page each time. Besides the bandwith/money waste (nasty with pay-per-traffic billing), it killed offline-browsing. Now, being able to follow no-cache "only for some sites" may be useful as a feature. Personally, I believe most of the web2.0 sites will not work with dillo until some javascript subset is implemented. -- Cheers Jorge.-

Aug. 26, 2010

Disable caching

by corvid＠lavabit.com

Fredrik wrote: > Hi, > although caching mostly is good, there is serveral occasions when it's > not wanted, specially with todays web2.0-concepts (user generated pages, > etc.). > > Is there a way to disable caching in dillo? Maybe only for some sites? > > I've searched the archives and found a patch doing this, it was however > dated back in 2003. So I'm intrested in som up-to-date information. To the best of my knowledge, - no one is working on it - but a good patch would be gladly accepted. Was there any discussion in the archive on why the 2003 patch wasn't integrated?

Aug. 25, 2010

Disable caching

by iveqy＠iveqy.com

Hi, although caching mostly is good, there is serveral occasions when it's not wanted, specially with todays web2.0-concepts (user generated pages, etc.). Is there a way to disable caching in dillo? Maybe only for some sites? I've searched the archives and found a patch doing this, it was however dated back in 2003. So I'm intrested in som up-to-date information. Regards iveqy

Aug. 25, 2010

html.cc cleanups

by Johannes.Hofmann＠gmx.de

On Wed, Aug 25, 2010 at 06:47:48AM +0100, Jeremy Henty wrote: > > I have started looking at html.cc to think about the "parse quoted > attributes like Firefox" patch, and here are some cleanups in the > meantime. They remove two unused structs and make variable names > consistent between function typedefs and function definitions. (NB: > the third patch depends on the second to apply cleanly, although they > are logically independent.) Committed. Cheers, Johannes

Aug. 25, 2010

html.cc cleanups

by onepoint＠starurchin.org

I have started looking at html.cc to think about the "parse quoted attributes like Firefox" patch, and here are some cleanups in the meantime. They remove two unused structs and make variable names consistent between function typedefs and function definitions. (NB: the third patch depends on the second to apply cleanly, although they are logically independent.) Regards, Jeremy Henty

Aug. 25, 2010

Quoted attribute parsing: summary

by jcid＠dillo.org

Hi Jeremy, It's a relief to see how things have evolved in ten years. I'm happily surprised! In the beginning Mozilla/FF did crazy stuff to make sense out of the most obnoxious tag soup. At that time we only parsed correct content (as from the SPEC) and everybody ended saying "dillo is broken" (despite the nice warning messages :-). Then we ended correcting tag soup as much as we could (but kept the nice warnings, which just a few souls cared for). At that moment we followed the "When in doubt, follow FF" motto which served us well, for the reasons you describe well. Now it's great to see a sensible turn into a better direction. I've considered this patch at least three times during this ten years, and I know FF behaved differently back then. I even committed the patch once, only to see lots of content dissappear from the page, and had to backpedal. Looking at the attached examples with FF is quite telling. (please read the comments below). On Wed, Aug 18, 2010 at 12:05:30AM +0100, Jeremy Henty wrote: > > Johannes Hofmann wrote: > > > But for me firefox 3.6.3 shows something given the following HTML > > (as does current dillo): > > > > <div title="foo >hello world</div>dillo is great > > That's Firefox's workaround that I described in my original post: if > it sees EOF while parsing a quoted attribute value (ie. if it *never* > sees a matching quote) then it goes back to the opening quote, > discards it, and parses an unquoted attribute value. So it ends up > parsing your example exactly as it would parse > > <div title=foo >hello world</div>dillo is great > > which gives the same result as vanilla Dillo, but for entirely > different reasons. > > But Firefox only does that if it can't find the matching quote at all; > if you feed it > > <div title="foo >hello world</div>dillo is great [... repeat > 'dillo is great' 10000 times ...]</div><div title="bar"> > > then it matches the second double quote with the first and *all* the > text disappears. Which is exactly what HTML5 says it should do. Of > course vanilla Dillo does *better* than Firefox for this example, but > in the real world I think it does *worse*. JavaScript fragments that > confound Dillo's algorithm are far more common than examples such as > the above that it handles well. > > OK, here's a new proposal: when parsing quoted attribute values, let's > copy Firefox! That would: (a) sensibly handle the missing quotes > examples that people have suggested (which my proposed patch does not > do), (b) handle well-formed JavaScript fragments correctly (which > vanilla Dillo does not do), (c) parse well-formed HTML5 as per the > HTML5 specification, (d) conform to Firefox's established practice, > and (e) not break Reddit! That's 5 wins! Agreed. I'll be looking forward for the patch. > It's true that we can't expect people to fix their HTML just because > the HTML5 specification says it's broken. And it's even less likely > that they will fix it just because it breaks in Dillo. But it is very > likely that they will fix it if it breaks in Firefox, so copying > Firefox is a good idea, even if you don't care about the HTML5 > specification. > > And, why should we care about edge cases that vanilla Dillo handles > better than Firefox, since those are precisely the cases that people > will fix to keep their Firefox users happy and that we can therefore > expect *not* to see! There's no point in having an algorithm that in > theory is better than Firefox's, because in practice it's not. > > So, why not just copy Firefox? I can't see any downside. Agreed, and that's what we've done for some time now. In the beginning we followed the SPECS, which caused more harm than good to the project in the long term. FWIW, when HTML was defined as XML, only a few servers provided it with the xhtml MIME type, because it risked not being rendered if incorrect, which didn't happen when served as "tag soup". The W3C and WDG, among others, built nice validators which were not used to correct the state of the web. Business logic prevailed: why waste resources on 1-2% of the market. As you see, we've had to sail with the tides. -- Cheers Jorge.-

Aug. 18, 2010

Quoted attribute parsing: summary

by onepoint＠starurchin.org

Johannes Hofmann wrote: > On Wed, Aug 18, 2010 at 12:05:30AM +0100, Jeremy Henty wrote: > > > > So, why not just copy Firefox? I can't see any downside. > > I agree. Can you adjust the patch? Then I'd like to wait what Jorge > and corvid say, but I think it's best to mimic Firefox. I'll work on a new patch next week. (I'd like to do it sooner but real life has already alloc()ed the rest of this week.) Thanks for your comments, Jeremy Henty

Aug. 18, 2010