- Dillo-dev - lists.mailman3.com

what's currently broken in dillo

by sgeerken＠dillo.org

On Fr, Jan 02, 2015, eocene wrote: > Sebastian wrote: > > > > > - on some sites, the ending words of a line are missing. > > > > > > The forecasts on the US national weather service page do this for me. > > > See the Detailed Forecast section. > > > Example: http://forecast.weather.gov/MapClick.php?lat=40&lon=-90 > > > > I'm not sure, I cannot reproduce it now; but I've fixed a bug > > demonstrated in the attached test page. Element #b is 1000px wide, but > > its parent, #a, is set to 100%, which refers to the viewport width > > (more or less), which may be less than 1000px. Note also #c, which is > > broken at the viewport width. > > > > Without 'adjust_min_width' set, parts of #b are indeed clipped; when > > set to 'YES', the width of #a, and so the srollable area, are adjusted > > (but not the width of #c), so that you can scroll to the right to read > > the rest. > > > > Currently, 'adjust_min_width' is not set by default. Probably, it > > should be set, to avoid such cases. What do you think? > > If it keeps text from being clipped, it sounds good. It is now set by default. > The weather page still breaks for me. Had you been able to reproduce the > problem earlier? I just tried moving dillorc and domainrc without any > effect on it. 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. Sebastian

Jan. 2, 2015

what's currently broken in dillo

by eocene＠gmx.com

Sebastian wrote: > > > > - on some sites, the ending words of a line are missing. > > > > The forecasts on the US national weather service page do this for me. > > See the Detailed Forecast section. > > Example: http://forecast.weather.gov/MapClick.php?lat=40&lon=-90 > > I'm not sure, I cannot reproduce it now; but I've fixed a bug > demonstrated in the attached test page. Element #b is 1000px wide, but > its parent, #a, is set to 100%, which refers to the viewport width > (more or less), which may be less than 1000px. Note also #c, which is > broken at the viewport width. > > Without 'adjust_min_width' set, parts of #b are indeed clipped; when > set to 'YES', the width of #a, and so the srollable area, are adjusted > (but not the width of #c), so that you can scroll to the right to read > the rest. > > Currently, 'adjust_min_width' is not set by default. Probably, it > should be set, to avoid such cases. What do you think? If it keeps text from being clipped, it sounds good. The weather page still breaks for me. Had you been able to reproduce the problem earlier? I just tried moving dillorc and domainrc without any effect on it.

Jan. 2, 2015

what's currently broken in dillo

by jcid＠dillo.org

On Fri, Jan 02, 2015 at 06:13:38PM +0100, Sebastian Geerken wrote: > > > > - on some sites, the ending words of a line are missing. > > > > The forecasts on the US national weather service page do this for me. > > See the Detailed Forecast section. > > Example: http://forecast.weather.gov/MapClick.php?lat=40&lon=-90 > > I'm not sure, I cannot reproduce it now; but I've fixed a bug > demonstrated in the attached test page. Element #b is 1000px wide, but > its parent, #a, is set to 100%, which refers to the viewport width > (more or less), which may be less than 1000px. Note also #c, which is > broken at the viewport width. > > Without 'adjust_min_width' set, parts of #b are indeed clipped; when > set to 'YES', the width of #a, and so the srollable area, are adjusted > (but not the width of #c), so that you can scroll to the right to read > the rest. > > Currently, 'adjust_min_width' is not set by default. Probably, it > should be set, to avoid such cases. What do you think? Speaking from experience gained from having to handle HTML parsing errors, and table apportioning algorithms, with all the contradicting directives, overrides, etc. In the long run, having dillo decide the final values by adding a cleanup stage at some points, has emerged as the choice with better rendering. (e.g. w3c_plus_heuristics=YES, cleanup_at_{open, close}(), contrast_visited_color=YES, ... ;) -- Cheers Jorge.-

Jan. 2, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

> > > - on some sites, the ending words of a line are missing. > > The forecasts on the US national weather service page do this for me. > See the Detailed Forecast section. > Example: http://forecast.weather.gov/MapClick.php?lat=40&lon=-90 I'm not sure, I cannot reproduce it now; but I've fixed a bug demonstrated in the attached test page. Element #b is 1000px wide, but its parent, #a, is set to 100%, which refers to the viewport width (more or less), which may be less than 1000px. Note also #c, which is broken at the viewport width. Without 'adjust_min_width' set, parts of #b are indeed clipped; when set to 'YES', the width of #a, and so the srollable area, are adjusted (but not the width of #c), so that you can scroll to the right to read the rest. Currently, 'adjust_min_width' is not set by default. Probably, it should be set, to avoid such cases. What do you think? Sebastian

Jan. 2, 2015

what's currently broken in dillo

by eocene＠gmx.com

Sebastian wrote: > On Sun, Dec 28, 2014, eocene wrote: > > Sebastian wrote: > > > On Mi, Dez 24, 2014, eocene wrote: > > > > - on some sites, rendering never stops as the horizontal scrollbar shows the > > > > page growing wider and wider. > > > > arstechnica.com does this like 95% of the time (I think deterministically -- > > like you can catch them at a time when their html is such that it doesn't > > show the problem, but it normally does.) > > This seems fixed now. Great :)

Jan. 2, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

On Sun, Dec 28, 2014, eocene wrote: > Sebastian wrote: > > On Mi, Dez 24, 2014, eocene wrote: > > > - on some sites, rendering never stops as the horizontal scrollbar shows the > > > page growing wider and wider. > > arstechnica.com does this like 95% of the time (I think deterministically -- > like you can catch them at a time when their html is such that it doesn't > show the problem, but it normally does.) This seems fixed now. Sebastian

Jan. 1, 2015

default search url [Re: here's 3.0.4.1 RC1]

by eocene＠gmx.com

Jorge wrote: > On Mon, Dec 08, 2014 at 12:40:48PM +0100, Sebastian Geerken wrote: > > It seems that this change fixes it: > > > > ---------------------------------------------------------------------- > > diff -r 9aa37b81c609 src/prefs.c > > --- a/src/prefs.c Tue Dec 02 16:33:49 2014 +0100 > > +++ b/src/prefs.c Mon Dec 08 12:37:15 2014 +0100 > > @@ -18,7 +18,7 @@ > > #define PREFS_FONT_CURSIVE "URW Chancery L" > > #define PREFS_FONT_FANTASY "DejaVu Sans" /* TODO: find good default */ > > #define PREFS_FONT_MONOSPACE "DejaVu Sans Mono" > > -#define PREFS_SEARCH_URL "http://duckduckgo.com/lite/?kp=-1&q=%s" > > +#define PREFS_SEARCH_URL "dd http://duckduckgo.com/lite/?kp=-1&q=%s" > > #define PREFS_NO_PROXY "localhost 127.0.0.1" > > #define PREFS_SAVE_DIR "/tmp/" > > #define PREFS_HTTP_REFERER "host" > > @@ -82,7 +82,6 @@ > > prefs.save_dir = dStrdup(PREFS_SAVE_DIR); > > prefs.search_urls = dList_new(16); > > dList_append(prefs.search_urls, dStrdup(PREFS_SEARCH_URL)); > > - dList_append(prefs.search_urls, NULL); /* flags a default search URL */ > > prefs.search_url_idx = 0; > > prefs.show_back = TRUE; > > prefs.show_bookmarks = TRUE; > > ---------------------------------------------------------------------- > > > > Not committed yet, since I'm not sure about the rationale. > > I'd also add: > > diff -r 978377ed5605 src/uicmd.cc > --- a/src/uicmd.cc Mon Dec 08 15:32:25 2014 +0100 > +++ b/src/uicmd.cc Mon Dec 08 22:58:53 2014 -0300 > @@ -682,7 +682,7 @@ static char *UIcmd_find_search_str(const > for (p = 0; p < dList_length(prefs.search_urls); p++) { > const char *search = > (const char *)dList_nth_data(prefs.search_urls, p); > - if (strncasecmp(str, search, len) == 0) { > + if (search && strncasecmp(str, search, len) == 0) { > prefs.search_url_idx = p; > url = UIcmd_make_search_str(str + len + 1); > break; > > (which solves the problem alone), but the cleanups above look > OK to me since AFAICS: > > * dd as default prefix for the DDG URL is fine. > * the NULL flag item is not used anymore. > * dialog.cc explicitly adds the extra item for menu building (n_it+1), > so the decreased number of elements is safe. I was thinking how I would prefer it if the built-in "dd" item would go away when I have search URLs in dillorc. Looking at prefsparser.cc, there's if (dList_length(lp) == 2 && !dList_nth_data(lp, 1)) { /* override the default */ void *data = dList_nth_data(lp, 0); dList_remove(lp, data); dList_remove(lp, NULL); dFree(data); } ...so I guess the NULL item was doing something.

Jan. 1, 2015

[cedric@reproducible.io: Thanks for your work on a browser that really cares about users' privacy!]

by jcid＠dillo.org

FYI, -- Cheers Jorge.-

Dec. 31, 2014

what's currently broken in dillo

by james.from.wellington＠gmail.com

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. Regards, James.

Dec. 29, 2014

what's currently broken in dillo

by jcid＠dillo.org

On Sun, Dec 28, 2014 at 02:44:55PM +0100, 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.) There're sites where "too many redraws" penalize rendering speed. See for instance [1] by going back and forward into it from the splash page. Most probably it's not related to large tables, but something lurks in there. [1] http://www.ethericwarriors.com/forum -- Cheers Jorge.-

Dec. 28, 2014