January 2015 - Dillo-dev - lists.mailman3.com

Core-dump pasting from one form field into another

by johannes.hofmann＠gmx.de

Hi James, On Tue, Jan 20, 2015 at 08:50:22PM +1300, James C wrote: > Hi All, > > I think I've worked out what's going on with drag-and-drop. > > We're compiling with -fno-rtti and (some parts of) fltk do > dynamic_cast, which needs rtti. The run-time handling for detecting > the conflict is nonexistent/unforgiving. > > When I make the change below and rebuild, drag-and-drop starts working for me. Cool that you found the reason! >From http://en.wikipedia.org/wiki/FLTK fltk is supposed to work without rtti, but things might have changed of course. It would be cool if you could bring up the topic on an fltk list to see if it's intended like this. Cheers, Johannes

Jan. 20, 2015

a different lines->getRef() segfault

by eocene＠gmx.com

A new page was just coming in -- seems like the same sort of problem as last time. (gdb) bt #0 0xb77bb424 in __kernel_vsyscall () #1 0xb72f9661 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb72fca92 in *__GI_abort () at abort.c:92 #3 0xb72f2878 in *__GI___assert_fail ( assertion=0x8151afe "i >= 0 && this->num - i > 0", file=0x8151aee "../lout/misc.hh", line=167, function=0x8151ba0 "T* lout::misc::SimpleVector<T>::getRef(int) const [with T = dw::Textblock::Line]") at assert.c:81 #4 0x080a9040 in lout::misc::SimpleVector<dw::Textblock::Line>::getRef ( this=0x953b618, i=-1) at ../lout/misc.hh:167 #5 0x080a2786 in dw::Textblock::sendSelectionEvent (this=0x916c610, eventType=dw::core::SelectionState::BUTTON_RELEASE, event=0xbfbb8180) at textblock.cc:1093 #6 0x080a24c3 in dw::Textblock::buttonReleaseImpl (this=0x916c610, event=0xbfbb8180) at textblock.cc:1008 #7 0x080d8910 in dw::core::Widget::buttonRelease (this=0x916c610, event=0xbfbb8180) at widget.cc:1027 #8 0x080cd617 in dw::core::Layout::processMouseEvent (this=0x90fc058, event=0xbfbb8180, type=dw::core::Layout::BUTTON_RELEASE) at layout.cc:1234 #9 0x080cd00e in dw::core::Layout::buttonEvent (this=0x90fc058, type=dw::core::Layout::BUTTON_RELEASE, view=0x90f9f60, numPressed=1, x=127, y=180, state=0, button=1) at layout.cc:1023 #10 0x080c46ae in dw::core::Layout::buttonRelease (this=0x90fc058, view=0x90f9f60, numPressed=1, x=127, y=180, state=0, button=1) at layout.hh:345 #11 0x080c33f7 in dw::fltk::FltkViewBase::handle (this=0x90f9f60, event=2) at fltkviewbase.cc:319 #12 0x080c5e8a in dw::fltk::FltkViewport::handle (this=0x90f9f60, event=2) at fltkviewport.cc:331 #13 0x080ded22 in send(int, Fl_Widget*, Fl_Window*) () #14 0x080dfbaf in Fl::handle_(int, Fl_Window*) () #15 0x080dff0e in Fl::handle(int, Fl_Window*) () #16 0x08107e9d in fl_handle(_XEvent const&) () #17 0x08107fbc in do_queued_events() () #18 0x0810822a in fl_wait(double) () #19 0x080e08af in Fl::wait(double) () #20 0x080e099d in Fl::run() () #21 0x08052f7a in main (argc=1, argv=0xbfbb8854) at dillo.cc:588

Jan. 20, 2015

Core-dump pasting from one form field into another

by james.from.wellington＠gmail.com

Hi All, I think I've worked out what's going on with drag-and-drop. We're compiling with -fno-rtti and (some parts of) fltk do dynamic_cast, which needs rtti. The run-time handling for detecting the conflict is nonexistent/unforgiving. When I make the change below and rebuild, drag-and-drop starts working for me. The executable size penalty is significant. The only 3+MB one is the only one with rtti turned on: ...$ ls -l versions/*/*/src/dillo -rwxr-xr-x 1 ... staff 2943392 25 Nov 21:42 versions/cookies/dillo-jfw01/src/dillo -rwxr-xr-x 1 ... staff 3253032 20 Jan 20:10 versions/everything/dillo-jfw01/src/dillo -rwxr-xr-x 1 ... staff 2943096 26 Oct 16:46 versions/pull-everything/dillo-jfw01/src/dillo -rwxr-xr-x 1 ... staff 2942840 15 Sep 18:11 versions/render/dillo-jfw01/src/dillo -rwxr-xr-x 1 ... staff 2942448 28 Oct 17:58 versions/ssh-everything-dirty/dillo-jfw01/src/dillo ...$ There are two dynamic casts in fltk: ./src/Fl_cocoa.mm:3792: if ( dynamic_cast<Fl_Input_*>(w) != NULL || dynamic_cast<Fl_Text_Display*>(w) != NULL) { ./src/Fl_cocoa.mm:3973: BOOL to_quartz = dynamic_cast<Fl_Printer*>(this) != NULL; I have no opinion yet about how difficult they would be to replace. The way forward should be decided by someone who remembers why no-rtti was originally turned on. Regards, James. $ hg diff configure.ac diff -r e773dab661ec configure.ac --- a/configure.ac Wed Sep 17 00:24:37 2014 +1200 +++ b/configure.ac Tue Jan 20 20:49:00 2015 +1300 @@ -488,7 +488,8 @@ dnl if eval "test x$GCC = xyes"; then - CXXFLAGS="$CXXFLAGS -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions" + CXXFLAGS="$CXXFLAGS -Wall -W -Wno-unused-parameter -fno-exceptions" +dnl removed -fno-rtti to enable DND in FLTK fi AC_SUBST(BASE_CUR_WORKING_DIR) On 1/7/15, Johannes Hofmann <Johannes.Hofmann at gmx.de> wrote: > 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 > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Jan. 20, 2015

form input placeholder text

by eocene＠gmx.com

Everyone's getting into the habit of using the html5 placeholder attributes on form inputs to tell users what the inputs are for, decreasing usability for the rest of us, so I implemented it for INPUT text/password. (It's also legal on TEXTAREA.) http://www.dillo.org/test/input_placeholder.diff

Jan. 20, 2015

addParbreak, display:inline

by eocene＠gmx.com

I was looking at why the page numbers at the bottom of a startpage search results page aren't visible. It seems that the numbers are forms with display:inline. open_form has HT2TB(html)->addParbreak (9, html->wordStyle ()); Am I correct in thinking that the assorted addParbreak()s have to come out at some point for display to work, or is there some other plan? I note that the html5 spec has: "In quirks mode, the following rules are also expected to apply: ... form { margin-bottom: 1em; }" to provide the gap in this case.

Jan. 19, 2015

resolution independent px

by sgeerken＠dillo.org

On So, Jan 18, 2015, Johannes Hofmann wrote: > As nobody actually has a problem at the moment I think we can > postpone this. It will come up again as high resolution devices are > becoming more popular. Furthermore, if such devices become more common, web designers may become more aware of this problem; something like this ---------------------------------------------------------------------- Some text and an image: <img src="http://www.dillo.org/Icons/ProgramIcon32.png" style="min-height: 1em"> ---------------------------------------------------------------------- would solve the problem, too (test it with different font sizes in dillo 3.1-dev). Sebastian

Jan. 18, 2015

should we have a dillo-announce list?

by eocene＠gmx.com

James wrote: > I've discovered openhub by accident: > https://www.openhub.net/p?ref=homepage&q=dillo > > Would it be a sensible place to announce new releases of Dillo? Are people using ohloh/openhub? I remember someone coming along at one point during dillo2 and mentioning it on the list (perhaps asking what to put in certain fields in the entry for dillo?), but that was a while ago. I was imagining asking Andreas to add a dillo-announce to lists.dillo.org...

Jan. 18, 2015

resolution independent px

by eocene＠gmx.com

Johannes wrote: > As nobody actually has a problem at the moment I think we can > postpone this. It will come up again as high resolution devices are > becoming more popular. Speaking of high resolution devices, does it look like there's much value these days in trying to get dillo to work better in the world of touch interfaces, or has dillo been utterly passed by there for one reason or another?

Jan. 18, 2015

resolution independent px

by Johannes.Hofmann＠gmx.de

Hi, On Sun, Jan 18, 2015 at 09:20:06PM +1300, James C wrote: > Hi Johannes, > > Reading the link, it looks like normally viewed displays with any > resolution between about 50 DPI and 140 DPI will have one CSS pixel > exactly equal to one device pixel; so resolutions outside that are the > definition of 'differs a lot' in the standard. > > What's the overhead of asking the library to re-scale the image to the > size that it already is? If it's significant, then maybe there needs > to be a special case for 1:1. the overhead is significant in case images would not be scaled otherwise, so we would want to special case it somehow. > > I start out with a bias against adding another run-time option, but > it's based on my not-very-relevant experience of adding an option to > dpid. > > Contradicting myself, the standard implies that there could be an > option for viewing distance, in which case there could be a special > case to that option for 'never scale'. As nobody actually has a problem at the moment I think we can postpone this. It will come up again as high resolution devices are becoming more popular. Cheers, Johannes > > Regards. > James. > > On 1/18/15, Johannes Hofmann <Johannes.Hofmann at gmx.de> wrote: > > On Fri, Jan 16, 2015 at 12:14:19PM -0300, Jorge Arellano Cid wrote: > >> On Fri, Jan 16, 2015 at 08:50:13AM +0100, Johannes Hofmann wrote: > >> > Hi, > >> > > >> > attached is a patch that would enable resolution independent > >> > handling of px as described in [1]. > >> > It would result in roughly equally sized images on high and low > >> > resolution devices at the cost of a higher overhead for additional > >> > image scaling. > >> > >> A long time ago, image scaling was relatively low overhead, > >> but since dillo got correct gamma correction, it became much > >> more expensive. > >> > >> I remember testing this and the difference was noticeable. > >> It was left anyway because the amount of scaled images > >> in the average web page is low. > >> > >> > >> > Is there a need for something like this? > >> > >> I don't know... > >> > >> > Should it be enabled via config option or should we do it > >> > automatically if we detect a DPI value that differs a lot from > >> > the standard value? > >> > >> For me, it is hard to say without knowing the main use of it. > >> What I do know is that our scaling is CPU intensive, so I tend > >> to have it off unless necessary. > > > > It's only useful if you have a high resolution device where DPI is > > much higher than about 70. In that case images will be rendered > > very small. > > > > I currently don't have such a device, so personally I don't have > > any need for this now. I just wanted to get feedback from dillo-dev > > in case someone already ran into this issue. > > > > Cheers, > > Johannes > > > > _______________________________________________ > > Dillo-dev mailing list > > Dillo-dev at dillo.org > > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

Jan. 18, 2015

resolution independent px

by james.from.wellington＠gmail.com

Hi Johannes, Reading the link, it looks like normally viewed displays with any resolution between about 50 DPI and 140 DPI will have one CSS pixel exactly equal to one device pixel; so resolutions outside that are the definition of 'differs a lot' in the standard. What's the overhead of asking the library to re-scale the image to the size that it already is? If it's significant, then maybe there needs to be a special case for 1:1. I start out with a bias against adding another run-time option, but it's based on my not-very-relevant experience of adding an option to dpid. Contradicting myself, the standard implies that there could be an option for viewing distance, in which case there could be a special case to that option for 'never scale'. Regards. James. On 1/18/15, Johannes Hofmann <Johannes.Hofmann at gmx.de> wrote: > On Fri, Jan 16, 2015 at 12:14:19PM -0300, Jorge Arellano Cid wrote: >> On Fri, Jan 16, 2015 at 08:50:13AM +0100, Johannes Hofmann wrote: >> > Hi, >> > >> > attached is a patch that would enable resolution independent >> > handling of px as described in [1]. >> > It would result in roughly equally sized images on high and low >> > resolution devices at the cost of a higher overhead for additional >> > image scaling. >> >> A long time ago, image scaling was relatively low overhead, >> but since dillo got correct gamma correction, it became much >> more expensive. >> >> I remember testing this and the difference was noticeable. >> It was left anyway because the amount of scaled images >> in the average web page is low. >> >> >> > Is there a need for something like this? >> >> I don't know... >> >> > Should it be enabled via config option or should we do it >> > automatically if we detect a DPI value that differs a lot from >> > the standard value? >> >> For me, it is hard to say without knowing the main use of it. >> What I do know is that our scaling is CPU intensive, so I tend >> to have it off unless necessary. > > It's only useful if you have a high resolution device where DPI is > much higher than about 70. In that case images will be rendered > very small. > > I currently don't have such a device, so personally I don't have > any need for this now. I just wanted to get feedback from dillo-dev > in case someone already ran into this issue. > > Cheers, > Johannes > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Jan. 18, 2015