[Dillo-dev] what's currently broken in dillo

[eocene]

Since fltk had a release today, I was thinking about where dillo stands at
present. Here are the problems that I can think of:

- vsource request crashes when dpid isn't working.
- source is slow to render, presumably something to do with large tables.
- on some sites, rendering never stops as the horizontal scrollbar shows the
page growing wider and wider.
- on some sites, the ending words of a line are missing.
- text search while loading, assert failed.
- img alt text not constrained by width/height.


_______________________________________________
Dillo-dev mailing list
Dill...@dillo.org
http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

[higuita]

Hi

On Tue, 4 Nov 2014 00:26:47 +0000, eocene <eoc...@gmx.com> wrote:
> Since fltk had a release today, I was thinking about where dillo stands
> at present. Here are the problems that I can think of:

I wanted to report this for a long time, this seems a good
opportunity :)

In the url below, all images are off the frame, making
everything look weird:

http://dont-starve-game.wikia.com/wiki/Crock_Pot_Recipes

Disabling the CSS don't fix the problem.

Also, i tried to build fltk svn and dillo hg and dillo is
reporting this:

g++ -I/usr/include/libpng14 -I/usr/include/freetype2 -O2 -fPIC -fvisibility-inlines-hidden -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O0 -fPIC -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dillo dillo.o paths.o tipwin.o ui.o uicmd.o bw.o cookies.o auth.o md5.o digest.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o domain.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg -L/usr/lib64 -lpng14 -L/usr/lib64 -lfltk -lXcursor -lXfixes -lXext -lXft -lfontconfig -lXinerama -lpthread -ldl -lm -lX11 -lz -lpthread -lX11
../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): In function `dw::fltk::FltkViewBase::handle(int)':
/home/higuita/build/dillo2/dillo3/dw/fltkviewbase.cc:367: undefined reference to `fl_oldfocus'
collect2: error: ld returned 1 exit status
make[3]: *** [dillo] Error 1

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

[James C]

Hi Higuita,

Please may I have:
- a screen shot of some of the breakage
- the list of web bugs on the page
?

I have 21 web bugs, and see many black boxes, but the only thing
that's obviously too far to the right is "A burnt Crock Pot from the
Reign of Giants DLC". I'm running hg dillo dated 26 Oct 14 plus the
diffs that I have sent to the list, one of which fixed some rendering
problems for me, but this page is not obviously exercising it.

Regards,
James.

[eocene]

> In the url below, all images are off the frame, making
> everything look weird:
>
> http://dont-starve-game.wikia.com/wiki/Crock_Pot_Recipes
>
> Disabling the CSS don't fix the problem.

Are you talking about the empty boxes to the left of the images? Looks
like it's some javascript thing.

> Also, i tried to build fltk svn and dillo hg and dillo is
> reporting this:
>

[snip]

> ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): In function `dw::fltk::FltkViewBase::handle(int)':
> /home/higuita/build/dillo2/dillo3/dw/fltkviewbase.cc:367: undefined reference to `fl_oldfocus'
> collect2: error: ld returned 1 exit status
> make[3]: *** [dillo] Error 1

I'm not sure why you're getting that.

[higuita]

On Tue, 4 Nov 2014 14:38:19 +0000, eocene <eoc...@gmx.com> wrote:
> Are you talking about the empty boxes to the left of the images? Looks
> like it's some javascript thing.

Yes!
In firefox, if i disable javascript, the page still renders
fine... but looking to the source, you may be right:


<td><a href="/wiki/Fruits" class="image image-thumbnail link-internal" title="Fruits">
<img src="data:image/gif;base64,R0lGODlhAQABAIABAAAAAP///yH5BAEAAAEALAAAAAABAAEAQAICTAEAOw%3D%3D" alt="Fruit" class="lzy lzyPlcHld " data-image-key="Fruit.png" data-image-name="Fruit.png" data-src="http://img2.wikia.nocookie.net/__cb20140514143205/dont-starve-game/images/thumb/a/a0/Fruit.png/32px-Fruit.png" onload="if(typeof ImgLzy==='object'){ImgLzy.load(this)}" height="32" width="32">
<noscript>
<img src="http://img2.wikia.nocookie.net/__cb20140514143205/dont-starve-game/images/thumb/a/a0/Fruit.png/32px-Fruit.png" alt="Fruit" class="" data-image-key="Fruit.png" data-image-name="Fruit.png" height="32" width="32">
</noscript></a>×0.5
</td>

So there are 2 image loaders, one with javascript, other without!

So the problem is that dillo is loading BOTH, creating the empty
square and the image right next to it, taken from the <noscript> block

> > ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): In function
> > `dw::fltk::FltkViewBase::handle(int)': /home/higuita/build/dillo2/dillo3/dw/fltkviewbase.cc:367:
> > undefined reference to `fl_oldfocus' collect2: error: ld returned 1
> > exit status make[3]: *** [dillo] Error 1
> I'm not sure why you're getting that.

I found that if i revert to fltk 1.3.2 it works, again building
the fltk 1.3.3, dillo build fails again.

I have done make clean on fltk and dillo on every try and tried
to clean the system from any old files, but same results.

greping the both fltk version for fl_oldfocus, i get the same
code, so is even weirder.

Can someone reproduce this or i have something broken on my
system?

Thanks again

[higuita]

> Please may I have:
> - a screen shot of some of the breakage

Screen shot attached.^H^H^H^H^H^H^H^H on the url below :)

http://picpaste.com/gkrellShoot_11-04-14_235147-M4JGRxAA.jpg

Note the images and next to the right the placeover where the
image should be.

> - the list of web bugs on the page

21 web bugs:

HTML warning: line 95, <meta> must be inside the HEAD section.
HTML warning: line 96, <meta> must be inside the HEAD section.
HTML warning: line 97, <meta> must be inside the HEAD section.
HTML warning: line 98, <meta> must be inside the HEAD section.
HTML warning: line 99, <meta> must be inside the HEAD section.
HTML warning: line 100, <meta> must be inside the HEAD section.
HTML warning: line 101, <meta> must be inside the HEAD section.
HTML warning: line 102, Unexpected closing tag: </head>.
HTML warning: line 103, <body> was already open.
HTML warning: line 718, <table> cellspacing attribute is obsolete.
HTML warning: line 1063, <big> is obsolete in HTML5.
HTML warning: line 1064, <big> is obsolete in HTML5.
HTML warning: line 1069, <big> is obsolete in HTML5.
HTML warning: line 1070, <big> is obsolete in HTML5.
HTML warning: line 1075, <big> is obsolete in HTML5.
HTML warning: line 1076, <big> is obsolete in HTML5.
HTML warning: line 1079, <big> is obsolete in HTML5.
HTML warning: line 1080, <big> is obsolete in HTML5.
HTML warning: line 1095, <table> cellspacing attribute is obsolete.
HTML warning: line 1158, <link> must be inside the HEAD section.
HTML warning: line 1158, <link> must be inside the HEAD section.

This witl fltk 1.3.2 and dillo e929d8bd7d6e tip

Thanks

[Jeremy Henty]

higuita wrote:

> > > ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): In function
> > > `dw::fltk::FltkViewBase::handle(int)': /home/higuita/build/dillo2/dillo3/dw/fltkviewbase.cc:367:
> > > undefined reference to `fl_oldfocus' collect2: error: ld returned 1
> > > exit status make[3]: *** [dillo] Error 1
> > I'm not sure why you're getting that.
>
> I found that if i revert to fltk 1.3.2 it works, again building
> the fltk 1.3.3, dillo build fails again.
>
> I have done make clean on fltk and dillo on every try and tried
> to clean the system from any old files, but same results.
>
> greping the both fltk version for fl_oldfocus, i get the same
> code, so is even weirder.
>
> Can someone reproduce this or i have something broken on my
> system?

I can reproduce this.

The Dillo source does something a little devious. It refers to
fl_oldfocus, but this symbol is not declared in any header, it is just
shared between two *.c files via an extern declaration (with a comment
that this is a hack to make Fl_Group work). Something has changed in
libfltk.so to stop the linker finding this symbol. I don't know what
(I am not experienced in debugging linking failures.)

Incidentally, yoshimi also fails to link against FLTK-1.3.3, although
a different symbol is involved.

Regards,

Jeremy Henty

[eocene]

Jeremy wrote:
> The Dillo source does something a little devious. It refers to
> fl_oldfocus, but this symbol is not declared in any header, it is just
> shared between two *.c files via an extern declaration (with a comment
> that this is a hack to make Fl_Group work). Something has changed in
> libfltk.so to stop the linker finding this symbol. I don't know what
> (I am not experienced in debugging linking failures.)

To the best of my recollection, something tricky was necessary because
Fl_Group didn't have the idea that the group itself could have focus
instead of one of the children. I can't immediately see how to get it
to work right without fl_oldfocus, but if we can't link, we have nothing,
so I'll take out fl_oldfocus, and hopefully someone will figure out
something at some point...

[Jeremy Henty]

I wrote:

> The Dillo source does something a little devious. It refers to
> fl_oldfocus, but this symbol is not declared in any header, it is
> just shared between two *.c files via an extern declaration (with a
> comment that this is a hack to make Fl_Group work). Something has
> changed in libfltk.so to stop the linker finding this symbol. I
> don't know what (I am not experienced in debugging linking
> failures.)

Got it! When using autoconf, FLTK-1.3.3 compiles (if possible) with
-fvisibility=hidden . This means that fl_oldfocus is marked as local
instead of global in libfltk.so , which breaks linking Dillo. You can
work around this with " ac_cv_cxx_fvisibility=no ./configure ... ".

[Jorge Arellano Cid]

Hi,

On Sun, Nov 16, 2014 at 05:17:06AM +0000, eocene wrote:
> Jeremy wrote:
> > The Dillo source does something a little devious. It refers to
> > fl_oldfocus, but this symbol is not declared in any header, it is just
> > shared between two *.c files via an extern declaration (with a comment
> > that this is a hack to make Fl_Group work). Something has changed in
> > libfltk.so to stop the linker finding this symbol. I don't know what
> > (I am not experienced in debugging linking failures.)
>
> To the best of my recollection, something tricky was necessary because
> Fl_Group didn't have the idea that the group itself could have focus
> instead of one of the children. I can't immediately see how to get it
> to work right without fl_oldfocus, but if we can't link, we have nothing,
> so I'll take out fl_oldfocus, and hopefully someone will figure out
> something at some point...

Good try, wandering focus got so annoying that I had to start scratching
the itch! ;)

FYI, I'm testing a patch that so far behaves OK.


--
Cheers
Jorge.-

[Jeremy Henty]

eocene wrote:

> [...] I'll take out fl_oldfocus, and hopefully someone will figure

> out something at some point...

Should we release 3.0.5 to fix this for distro users? Otherwise their
dillo will break when their distro updates to a FLTK-1.3.3 *.so .

Regards,

Jeremy Henty

[Jorge Arellano Cid]

Hi Jeremy,

On Mon, Nov 17, 2014 at 05:33:41PM +0000, Jeremy Henty wrote:
>
> eocene wrote:
>
> > [...] I'll take out fl_oldfocus, and hopefully someone will figure
> > out something at some point...
>
> Should we release 3.0.5 to fix this for distro users? Otherwise their
> dillo will break when their distro updates to a FLTK-1.3.3 *.so .

IMHO current repo is not as stable as it should for a new release.

I'd pack a 3.0.4.1 with the fix for FLTK-1.3.3.

The repo has more than enough for a version bump when its moment comes!

--
Cheers
Jorge.-

[Jeremy Henty]

Jorge Arellano Cid wrote:

> On Mon, Nov 17, 2014 at 05:33:41PM +0000, Jeremy Henty wrote:
> >
> > Should we release 3.0.5 to fix this for distro users? Otherwise their
> > dillo will break when their distro updates to a FLTK-1.3.3 *.so .
>
> IMHO current repo is not as stable as it should for a new release.
>
> I'd pack a 3.0.4.1 with the fix for FLTK-1.3.3.

That was what I had in mind. Sorry if that was not clear.

> The repo has more than enough for a version bump when its moment
> comes!

I would say it deserves to be 3.1 at least! :-)

Regards,

Jeremy Henty

[Jorge Arellano Cid]

On Mon, Nov 17, 2014 at 01:54:46PM -0300, Jorge Arellano Cid wrote:
> Hi,
>
> On Sun, Nov 16, 2014 at 05:17:06AM +0000, eocene wrote:
> > Jeremy wrote:
> > > The Dillo source does something a little devious. It refers to
> > > fl_oldfocus, but this symbol is not declared in any header, it is just
> > > shared between two *.c files via an extern declaration (with a comment
> > > that this is a hack to make Fl_Group work). Something has changed in
> > > libfltk.so to stop the linker finding this symbol. I don't know what
> > > (I am not experienced in debugging linking failures.)
> >
> > To the best of my recollection, something tricky was necessary because
> > Fl_Group didn't have the idea that the group itself could have focus
> > instead of one of the children. I can't immediately see how to get it
> > to work right without fl_oldfocus, but if we can't link, we have nothing,
> > so I'll take out fl_oldfocus, and hopefully someone will figure out
> > something at some point...
>
> Good try, wandering focus got so annoying that I had to start scratching
> the itch! ;)
>
> FYI, I'm testing a patch that so far behaves OK.

Committed.

[eocene]

Jorge wrote:
> On Mon, Nov 17, 2014 at 01:54:46PM -0300, Jorge Arellano Cid wrote:
> > Good try, wandering focus got so annoying that I had to start scratching
> > the itch! ;)
> >
> > FYI, I'm testing a patch that so far behaves OK.
>
> Committed.

If I go to a page that has a Fl_Input, give focus to the input, move the
cursor out of the dillo window, and move it back into the dillo window,
focus does not return to the input.

[Jorge Arellano Cid]

On Tue, Nov 18, 2014 at 05:57:50PM +0000, eocene wrote:
> Jorge wrote:
> > On Mon, Nov 17, 2014 at 01:54:46PM -0300, Jorge Arellano Cid wrote:
> > > Good try, wandering focus got so annoying that I had to start scratching
> > > the itch! ;)
> > >
> > > FYI, I'm testing a patch that so far behaves OK.
> >
> > Committed.
>
> If I go to a page that has a Fl_Input, give focus to the input, move the
> cursor out of the dillo window, and move it back into the dillo window,
> focus does not return to the input.

OK, now I have code that also works for this case...

If you have another interesting test case like this, please let
me know now (before I send it to you for the final reality checks).


--
Cheers
Jorge.-

[eocene]

Jorge wrote:
> On Tue, Nov 18, 2014 at 05:57:50PM +0000, eocene wrote:
> > Jorge wrote:
> > > On Mon, Nov 17, 2014 at 01:54:46PM -0300, Jorge Arellano Cid wrote:
> > > > Good try, wandering focus got so annoying that I had to start scratching
> > > > the itch! ;)
> > > >
> > > > FYI, I'm testing a patch that so far behaves OK.
> > >
> > > Committed.
> >
> > If I go to a page that has a Fl_Input, give focus to the input, move the
> > cursor out of the dillo window, and move it back into the dillo window,
> > focus does not return to the input.
>
> OK, now I have code that also works for this case...
>
> If you have another interesting test case like this, please let
> me know now (before I send it to you for the final reality checks).

I can't think of anything in particular right now...

[Jorge Arellano Cid]

On Tue, Nov 18, 2014 at 05:57:50PM +0000, eocene wrote:

> Jorge wrote:
> > On Mon, Nov 17, 2014 at 01:54:46PM -0300, Jorge Arellano Cid wrote:
> > > Good try, wandering focus got so annoying that I had to start scratching
> > > the itch! ;)
> > >
> > > FYI, I'm testing a patch that so far behaves OK.
> >
> > Committed.
>
> If I go to a page that has a Fl_Input, give focus to the input, move the
> cursor out of the dillo window, and move it back into the dillo window,
> focus does not return to the input.

Committed a new patch.

--
Cheers
Jorge.-

[eocene]

Jorge wrote:
> I'd pack a 3.0.4.1 with the fix for FLTK-1.3.3.

Looking at ChangeLog, I'd argue that if we're making any release, we
should also have

- Don't load background images in --local mode.

and probably

- Fix Makefile to pick up LIBJPEG_CPPFLAGS.

and perhaps

- Remove Fl_Printer stub that always gave problems compiling under OSX.

[Jorge Arellano Cid]

On Wed, Nov 19, 2014 at 08:16:20PM +0000, eocene wrote:
> Jorge wrote:
> > I'd pack a 3.0.4.1 with the fix for FLTK-1.3.3.
>
> Looking at ChangeLog, I'd argue that if we're making any release, we
> should also have
>
> - Don't load background images in --local mode.
>
> and probably
>
> - Fix Makefile to pick up LIBJPEG_CPPFLAGS.
>
> and perhaps
>
> - Remove Fl_Printer stub that always gave problems compiling under OSX.

+1

--
Cheers
Jorge.-

[eocene]

Jorge wrote:
> On Wed, Nov 19, 2014 at 08:16:20PM +0000, eocene wrote:
> > Jorge wrote:
> > > I'd pack a 3.0.4.1 with the fix for FLTK-1.3.3.
> >
> > Looking at ChangeLog, I'd argue that if we're making any release, we
> > should also have
> >
> > - Don't load background images in --local mode.
> >
> > and probably
> >
> > - Fix Makefile to pick up LIBJPEG_CPPFLAGS.
> >
> > and perhaps
> >
> > - Remove Fl_Printer stub that always gave problems compiling under OSX.
>
> +1

It looks like I'll be semi-busy through Monday or so, but if no one
else feels like doing it, I'll look into creating a branch, committing
changes, version number, splash verbiage, etc....

[eocene]

I wrote:
> Jorge wrote:
> > On Wed, Nov 19, 2014 at 08:16:20PM +0000, eocene wrote:
> > > Jorge wrote:
> > > > I'd pack a 3.0.4.1 with the fix for FLTK-1.3.3.
> > >
> > > Looking at ChangeLog, I'd argue that if we're making any release, we
> > > should also have
> > >
> > > - Don't load background images in --local mode.
> > >
> > > and probably
> > >
> > > - Fix Makefile to pick up LIBJPEG_CPPFLAGS.
> > >
> > > and perhaps
> > >
> > > - Remove Fl_Printer stub that always gave problems compiling under OSX.
> >
> > +1
>
> It looks like I'll be semi-busy through Monday or so, but if no one
> else feels like doing it, I'll look into creating a branch, committing
> changes, version number, splash verbiage, etc....

After doing all of that just now, I was giving a little methodical testing
before pushing my changes, and I found that there's still a bug in the focus
fix.

If the page has focus, and the cursor leaves the page and returns to it, it
seems to be fine.
If an input has focus, and the cursor leaves the page and returns to it, it
seems to be fine.
If an input has focus and you click on the page to give it focus instead,
and then the cursor leaves the page and returns to it, the input is given
focus instead.


PS I was mistaken when I thought "Fix Makefile to pick up LIBJPEG_CPPFLAGS"
related to a bug that made it into a release. The bug actually came from the
float code that was merged in.

[Jorge Arellano Cid]

Right!

Please try this patch:

diff -r fb02b8b26017 dw/fltkviewbase.cc
--- a/dw/fltkviewbase.cc Fri Nov 21 21:58:27 2014 +0100
+++ b/dw/fltkviewbase.cc Thu Nov 27 10:10:22 2014 -0300
@@ -365,6 +365,8 @@ int FltkViewBase::handle (int event)
// FLTK delivers UNFOCUS to the previously focused widget
if (find(Fl::focus()) < children())
focused_child = Fl::focus(); // remember the focused child!
+ else if (Fl::focus() == this)
+ focused_child = NULL; // no focused child this time
return 0;
case FL_KEYBOARD:
if (Fl::event_key() == FL_Tab)


--
Cheers
Jorge.-

[eocene]

Jorge wrote:
> On Tue, Nov 25, 2014 at 08:14:45PM +0000, eocene wrote:
> > After doing all of that just now, I was giving a little methodical testing
> > before pushing my changes, and I found that there's still a bug in the focus
> > fix.
> >
> > If the page has focus, and the cursor leaves the page and returns to it, it
> > seems to be fine.
> > If an input has focus, and the cursor leaves the page and returns to it, it
> > seems to be fine.
> > If an input has focus and you click on the page to give it focus instead,
> > and then the cursor leaves the page and returns to it, the input is given
> > focus instead.
>
> Right!
>
> Please try this patch:

Seems to be working. Changes pushed.
I'm guessing that 'hg update 3.0.4.1' may be necessary for you to switch from
the 'default' branch after pulling.

[Jorge Arellano Cid]

On Thu, Nov 27, 2014 at 04:41:41PM +0000, eocene wrote:
> Jorge wrote:
> > On Tue, Nov 25, 2014 at 08:14:45PM +0000, eocene wrote:
> > > After doing all of that just now, I was giving a little methodical testing
> > > before pushing my changes, and I found that there's still a bug in the focus
> > > fix.
> > >
> > > If the page has focus, and the cursor leaves the page and returns to it, it
> > > seems to be fine.
> > > If an input has focus, and the cursor leaves the page and returns to it, it
> > > seems to be fine.
> > > If an input has focus and you click on the page to give it focus instead,
> > > and then the cursor leaves the page and returns to it, the input is given
> > > focus instead.
> >
> > Right!
> >
> > Please try this patch:
>
> Seems to be working. Changes pushed.
> I'm guessing that 'hg update 3.0.4.1' may be necessary for you to switch from
> the 'default' branch after pulling.

Can you push changeset: 3976:d6a45d54f49a to the default branch too?
(I don't know how to do it without making a new patch).

--
Cheers
Jorge.-

[eocene]

Jorge wrote:
> On Thu, Nov 27, 2014 at 04:41:41PM +0000, eocene wrote:
> > Seems to be working. Changes pushed.
> > I'm guessing that 'hg update 3.0.4.1' may be necessary for you to switch from
> > the 'default' branch after pulling.
>
> Can you push changeset: 3976:d6a45d54f49a to the default branch too?
> (I don't know how to do it without making a new patch).

Do you mean have a changeset be part of multiple branches? I don't think
that can be done.

My impression is that merging after we finish the branch won't be anything
more than:

hg update default
hg merge 3.0.4.1

(and I see that hg commit comes with a '--close-branch' that people use when
they're irritated by having too many old branches visible in hg branches,
which doesn't sound like a problem for us at present)