- Dillo-dev - lists.mailman3.com

what's currently broken in dillo

by sgeerken＠dillo.org

On Tue, Jan 06, 2015, Sebastian Geerken wrote: > On Sun, Dec 28, 2014, Sebastian Geerken wrote: > > On Wed, Dec 24, 2014, eocene wrote: > > > - source is slow to render, seemingly something to do with large tables. > > > > Yes, I'm noticing that rendering large tables is much slower than in > > 3.0.4. I'll work on this. (Probably a side-effect of GROWS.) > > It has become much better, although still slower than 3.0.4. A simple gprof run showed another opportunity for optimization. There should now be no performance problems anymore with tables. Sebastian

Jan. 7, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

On Sun, Dec 28, 2014, Sebastian Geerken wrote: > On Wed, Dec 24, 2014, eocene wrote: > > - source is slow to render, seemingly something to do with large tables. > > Yes, I'm noticing that rendering large tables is much slower than in > 3.0.4. I'll work on this. (Probably a side-effect of GROWS.) It has become much better, although still slower than 3.0.4. Sebastian

Jan. 6, 2015

Core-dump pasting from one form field into another

by Johannes.Hofmann＠gmx.de

On Sat, Dec 27, 2014 at 08:42:55PM +0100, Johannes Hofmann wrote: > On Sat, Dec 27, 2014 at 06:22:12PM +0000, eocene wrote: > > James wrote: > > > This is exercisable in Dillo 3.0.4.1, but not new. I found it by > > > accident in my hack-up of Dillo 3.0.4. > > > > > > The reproduction is: > > > - enable cookies for .google.com > > > - navigate to https://mail.google.com/mail/?ui=html > > > - fight the links until you get a screen with two fields, one for the > > > username and one for the password > > > - type something into the username field > > > - select it and drag to the password field > > > -- core dump > > > > > > I am on: > > > > > > - OSX 10.6.8 > > > - Dillo 3.0.4.1 with SSL enabled > > > - FLTK 1.3.3 > > > - with dpid, etc from Dillo 3.0.4 with extensive hacking > > > > > > so the fault could be Mac-specific. > > > > I tried playing around a little, on linux and not having a gmail acct, > > and nothing wanted to go wrong, so, yeah, it might be an osx issue... > > Can't reproduce it either on DragonFly BSD. I can try later to get > a stack trace on osx. On MacOSX all attempts to drag and drop crash dillo for me. As it also causes confusion on X11 based systems I disabled DND alltogether for now. Cheers, Johannes

Jan. 6, 2015

should we have a dillo-announce list?

by jcid＠dillo.org

On Sat, Jan 03, 2015 at 07:49:29PM +0000, eocene wrote: > > Seems like a release announcements list would be valuable... +1 At least that way we'd have one official channel (without the burden of receiving the whole traffic in dillo-dev). -- Cheers Jorge.-

Jan. 6, 2015

what's currently broken in dillo

by jcid＠dillo.org

On Mon, Jan 05, 2015 at 03:59:15PM +0100, Sebastian Geerken wrote: > On Fr, Jan 02, 2015, Jorge Arellano Cid wrote: > > It's a bit sad to find time and again that 3.0.4 has better rendering > > than the new branch. (e.g. [1]) > > > > [1] http://actualidad.rt.com/economia/161785-china-devastador-dolar-rublo-yuanes > > It is getting better (fixing "plain" bugs). While examining why the > images are not shown, I noticed that some element is set at height 0. > Test the attached page in dillo and Firefox and notice the difference: > Firefox shows the first line, although it has height 0, but draws the > second line at the same position as the first, the latter shining > through. > > It is somewhat difficult to imitate this behavour [1]; but two > solutions are feasable: (i) ignore height (perhaps via user style > sheet); (ii) use 'height' only to make elements larger (somewhat > similar to 'adjust_min_width'). In both cases, the two lines would be > put on top of each other. I like (ii). It falls in the "make dillo decide when directives make no sense" philosophy I'm advocating for.. -- Cheers Jorge.-

Jan. 6, 2015

what's currently broken in dillo

by jcid＠dillo.org

Hi Sebastian, On Sun, Jan 04, 2015 at 02:00:52PM +0100, Sebastian Geerken wrote: > On Sa, Jan 03, 2015, Jorge Arellano Cid wrote: > > [...] > > One solution I've been thinking about is to customize the > > rendering for each user. In general terms, a user goes to a > > handful of websites regularly. Those sites are the ones he cares > > more about. > > > > If we for instance remember that for site X, the user prefers > > no embedded CSS, that's it. > > > > This would be stored in a plain text file as a simple line. The > > UI interface, under Tools|Customize may offer something like: > > > > [ ] Remember settings for this page > > [ ] Remember settings for this site > > > > That's it, after a few simple clicks, problem is gone. > > > > The idea is this to be exceptional, this is, used as an > > exception for a few sites as general rendering should solve most > > cases. > > > > FWIW, I'm planning to make a list of these ideas to work on > > this year and be of help in this area. > > First of all, let's see how many problems fall into the "plain bug" > category, and so are simple to fix (although it needs work and time). Yes, sure. Now, with some sites it's not clear whether something is a bug, bad HTML, contradicting directives, etc. IMHO, just there, having an easy (i.e. user ready, click-click) way to customize can help a lot. e.g.[1] Here, I don't know what's wrong, but reading the text in those colors clearly hurts. Avoiding embedded CSS "solves" the problem with one click (from a user perspective). I may try coding it a bit and check how it feels. [1] http://www.veteranstoday.com/2015/01/05/hate-conspiracies/ > Partly, this kind of customization is already possible by usage of > user style sheets; perhaps we could add a (proprietary) extension for > selecting specific sites. Yes, but this solution requires good knowledge on CSS and HTML and some digging time (as in the example above where we don't know the problem in advance). OTOH, clicking a pair of checkboxes and see whether that helps is much easier. It's a user-level "solution". > While we're at this: Attached is a page which renders differently in > dillo and Firefox; the latter closes the "em" implicitely, so that the > red box is below (not inside) the green one. It's very good you discovered this point! > From my understanding, > > (i) this is incorrect HTML, but Yes. > (ii) since "div" is not allowed within "em", this could be easily > detected, to mimic Firefox behaviour. Yes. > This page is a simplified version of a real-word page, and in some > cases, the implications for the rendering are quite extreme. Yes. IMO this is a good place to nail some "rendering bugs" (by reacting as FF to bad HTML). AFAIR, the HTML cleanup heuristics were tuned before DIV was supported! I'll work on this now. Please let me know of any other tags you've found in real pages that mess with DIV in this sense while I work on it (for instance EM is in the phrase set which should be treated similarly). It may end helping rendering of a lot of sites or just a few, who knows, but's definitely worth the try. See attached toy-patch for the test case. -- Cheers Jorge.-

Jan. 6, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

> Test the "soon" > attached page ...

Jan. 5, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

On Fr, Jan 02, 2015, Jorge Arellano Cid wrote: > It's a bit sad to find time and again that 3.0.4 has better rendering > than the new branch. (e.g. [1]) > > [1] http://actualidad.rt.com/economia/161785-china-devastador-dolar-rublo-yuanes It is getting better (fixing "plain" bugs). While examining why the images are not shown, I noticed that some element is set at height 0. Test the attached page in dillo and Firefox and notice the difference: Firefox shows the first line, although it has height 0, but draws the second line at the same position as the first, the latter shining through. It is somewhat difficult to imitate this behavour [1]; but two solutions are feasable: (i) ignore height (perhaps via user style sheet); (ii) use 'height' only to make elements larger (somewhat similar to 'adjust_min_width'). In both cases, the two lines would be put on top of each other. Sebastian [1] Complicated cases of overlapping elements are handled in the "dillo_grows" repository, at <http://flpsed.org/hgweb/dillo_grows>.

Jan. 5, 2015

what's currently broken in dillo

by eocene＠gmx.com

Sebastian wrote: > On Fri, Jan 02, 2015, eocene wrote: > > Sebastian wrote: > > > Yes, I now see; I assume that you mean this: > > > > > > http://www.dillo.org/~sgeerken/attic/forecast.weather.gov_01.png > > > > > > I'll look at it. > > > > Yes, that. Thanks... > > Finally works, although the floats ("Tonight", "Monday" ...) look a > bit different from Firefox. Thanks :)

Jan. 4, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

On Mon, Dec 29, 2014, James C. wrote: > I have missing words on the right, on the attached, which are exercisable only: > - with the CSS > - with at least one graphic correctly linked > > I didn't finish walking down a small test-case, because the other thing intervened. This works now, too. BTW, there were a couple of bugs occurring here. Sebastian

Jan. 4, 2015