- Dillo-dev - lists.mailman3.com

dillo-3.0 is on site for testing!
by jcid＠dillo.org Sept. 9, 2011

Sept. 9, 2011

Hi there, After a long list of fixes and features: [ok] moveToWidget(). Jorge has code for this. [ok] downloads dpi string escaping. [ok] alt text wrapping (which looks like a nice feature). [ok] remove large panel. [ok] https dialog storm (BUG#868). [ok] The findbar input doesn't know about Ctrl+{a,e,d,k}. [ok] something other than "ctab%d" for initial tab label. [ok] single close tab button with tooltip. [ok] valgrind logs: close window [ok] valgrind logs: cancel expected url [ok] segfault with Ctrl-s (web search) [ok] UI_TEMPORARILY_SHOW_PANELS [ok] leave link into a native FLTK widget [ok] remove pointeronlink(), panelmode_cb_i() [ok] the panel problems when resizing from very small. [ok] resize problems when tabs overflow [ok] URL_ILLEGAL_CHARS [ok] Fixed CustLightButton "light" color deactivation. [ok] hoverTooltip glitch (tooltip linger when going into a child DIV). [ok] tab overflow (code a handler) [ok] valgrind error for first tab close, then resize(). [ok] update the Changelog [ok] update links in splash page [ok] default search engine [ok] new-tab and window title [ok] CSS adjacent sibling selectors [ok] margin-bottom + some margin collapse [ok] fix doctree leak [ok] first click on a link missed after middle-click on a scrollbar [ok] Fix redraw loops and reenable limit_text_width dillorc option dillo-3.0 is available from: http://www.dillo.org/download/ This should be our last release candidate, unless something major appears. Please download, build, test and report how it goes. If there's no show stopper in a couple of days, the announcement to the outside world will be made. ;) -- Cheers Jorge.-

7 16

ipv6 addresses
by dennisn＠dennisn.dyndns.org Sept. 8, 2011

Sept. 8, 2011

Is it possible to specify ipv6 addresses into dillo's address bar?

2 1

dillo close dialog and fluxbox on dual head
by higuita7＠yahoo.co.uk Sept. 8, 2011

Sept. 8, 2011

Hi i dont know if this is a problem with dillo or with fluxbox, but when i try to close a dillo with several tabs, i get always the close dialog (title is Choice5) on my secondary X11 head. If i try to setup fluxbox to force the dialog to open on head 1, it still opens on head 2. if i do the same thing for all other dillo dialogs, like open file, search (title ask), etc , i fluxbox puts the window in the configured head. If i try to set the position and head, fluxbox puts the dialog in the right position, but in the wrong head. If i try to run the fltk-1.3/test/message test, i can setup the head of those messages without any problem. i'm using the latest dillo3 "hg version" with the latest fltk1.3 svn , running on a slackware64 with Fluxbox 1.3.1 and a dual head setup. The main head (1) is right, secondary head (2) is left. They are setup with xrandr on a ati r600 card: xrandr --output DVI-0 --auto --primary --dpi 96 --output VGA-0 --left-of DVI-0 --auto --dpi 96 xrandr --output DVI-0 --primary --set underscan off As dillo is the only app i found with this problem, and even other dillo windows work fine, i suspect something in dillo3 or in fltk1.3 that is forcing the Choice5 dialog to stay on head 2... probably just because is on the left (so closer to the 0,0 X11 virtual display corner), instead of using the virtual position of each head. What you think? should i open a bug in fluxbox, in fltk or is this a dillo problem? Thanks in advance for the help and thanks for dillo higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

3 8

Query dpid or running dillos
by dennisn＠dennisn.dyndns.org Sept. 7, 2011

Sept. 7, 2011

Is there a way to query dillo (or dpid?) for the links it currently has open? (dpidc/dillo don't seem to have such an option :p) "dillo --xid XID" is able to access a specific window... but I guess there is no way to currently read that "property" (link). (Oh, speaking of which, the "--xid XID" feature is buggy here ... it loads the link, but renders with a wide (200pixel-ish?) margin on the left, which doesn't match the actual clickable button/link-areas on the page. Dillo version 2.2.1, fltk-1.3.0.)

2 2

dillo_port1.3 only opens so many tabs, then stops opening more tabs
by rogerx.oss＠gmail.com Sept. 7, 2011

Sept. 7, 2011

I just noticed, pulling a git/svn/cvs copy yesterday, I can only open so many tabs (screen/display width?) and then Dill will stop opening new tabs after a link is clicked to open in a new tab. The only thing printed within the startx stdout is "Nav_open_url:(include_clicked_url_here) and no other activity such as "a_Nav_expect_done: repush!" or "[cookies dpi]:" etc... -- Roger http://rogerx.freeshell.org/

2 3

page that redraws endlessly
by corvid＠lavabit.com Sept. 6, 2011

Sept. 6, 2011

http://www.dillo.org/test/redraws.html For me, it still breaks with default dillorc options, and also with a dillo from April 2010.

3 12

prefs.show_url
by corvid＠lavabit.com Sept. 3, 2011

Sept. 3, 2011

I just found that turning off prefs.show_url messes up the appearance of the UI.

1 0

valgrind still unhappy despite expect changes
by jcid＠dillo.org Sept. 2, 2011

Sept. 2, 2011

On Sun, Aug 28, 2011 at 06:53:54PM +0000, corvid wrote: > > I can't reproduce this with valgrind-3.6.1 on wheezy. > > > > No valgrind error report before or after these debug messages: > > > > a_Nav_cancel_expect_if_eq:: calling a_Nav_cancel_expect > > Dillo: normal exit! > > > > I tested by pushing a remote URL on CLI and closing the window > > before the page data starts flowing (i.e. to cancel the > > "expect"), and also with the cancelled download code path. > > Neither one produced an error. > > I saw that there was another log entry the other day > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… > > Do you think something sneaky could be going on, or does it seem > like it must come down to configuration differences somehow? AFAIS, either one is possible... Me not being able to reproduce it says it's most probably be OK for the codepaths I tested (FWIW, the ones I can see). If there's an untested codepath, well... OTOH, valgrind produces some false positives (its docs say it) and gcc optimization can also play a role... So, I'd try to find a simple test case that produces the log. Then, test this problematic codepath here, and see what comes out of the exercise. Can you reproduce the bug? Do you have a simple test case? -- Cheers Jorge.-

4 16

valgrind doctree leak
by corvid＠lavabit.com Aug. 28, 2011

Aug. 28, 2011

(from Jeremy's logs) ==2186== 928 (32 direct, 896 indirect) bytes in 1 blocks are definitely lost in loss record 815 of 958 ==2186== at 0x40275CC: operator new(unsigned int) (vg_replace_malloc.c:255) ==2186== by 0x806E258: Doctree::push() (doctree.hh:67) ==2186== by 0x806C1FC: StyleEngine::startElement(int) (styleengine.cc:93) ==2186== by 0x8076DB8: Html_process_tag(DilloHtml*, char*, int) (html.cc:3507) ==2186== by 0x8077A33: Html_write_raw(DilloHtml*, char*, int, int) (html.cc:3822) ==2186== by 0x8070543: DilloHtml::write(char*, int, int) (html.cc:552) ==2186== by 0x80775BD: Html_callback(int, _CacheClient*) (html.cc:3725) ==2186== by 0x80627AD: Cache_process_queue (cache.c:1195) ==2186== by 0x80629A2: Cache_delayed_process_queue_callback (cache.c:1260) ==2186== by 0x40C0876: Fl::wait(double) (in /usr/lib/libfltk.so.1.3) ==2186== by 0x40C0A30: Fl::run() (in /usr/lib/libfltk.so.1.3) ==2186== by 0x804F08A: main (dillo.cc:436)

2 1

problems with very long alt text
by jcid＠dillo.org Aug. 28, 2011

Aug. 28, 2011

On Fri, Aug 26, 2011 at 07:29:21PM +0200, hiro wrote: > With tinycorelinux and Xorg-7.5 i915 on 1024x768 I get a completely > garbled screen and unresponsive system, CPU ran hot and I had to > reboot. > I can reboot into VESA if you want. [later hiro wrote:] > Ok I don't get the bug with Xvesa, tinycorelinux' default Xserver. Excellent! This proves the point (AFAICS). Thank you very much. -- Cheers Jorge.-

1 1