Fifth: A New Web Browser Based On WebKitFLTK

[Luke]

Partially downloaded web videos are playable

download a video without know if the video is good or bad, is a stupid thing

Not exactly: if bandwidth is the issue open the file in mplayer/mpv/whatever as soon as it appears and see what you are getting. Most "web-optimized" video has the headers in front so partial files can be played. I use qt-faststart to set up my archive videos this way, as archive.org returns the original file.

A video that is at the limits of what a computer can play is often too much to play in the browser but will play well in the better video players like mplayer/mplayer2/mpv, Xine, and VLC. I do not know if that's true in Windows (where Windows Media Center performs no better than the browser), but I know this for a fact when they are running under Linux. I sometimes advise people viewing my videos in 540X960 resolution to download if they get playback issues on Pentium 4's or netbooks.

If you are worried about maliciously tampered video aimed at a browser/flash exploit, a browser exploit won't even run when loaded into a video player instead of the browser. Exploit code sitting in a downloaded file is like a bullet sitting on the table: it is harmless unless fired (executed). A really skilled opponent aiming at you in person or at downloaders in general would have to guess which video player, which version with which vulnerablity his file would be opened in. Probably he would guess everything would be running under MS Windows and roll snakeyes with most of us on this forum.

[curaga]

Perhaps you could build a version that draws the *this is too much crap line* at a different place... I personally think being able to play videos in a video tag is important enough a feature that it is a must have.... I can see how you would want to not include it on a basis of lightweightness/speed. but on the other hand it doesn't go against your non-app/native only philosophy.

In any case I've been hoping someone would build a nice FLTK browser for a long time thanks again.

Well, the gstreamer html5 code already exists in the tree due to webkitgtk. If you wanted to, you should be able to get it running with a little hacking - change some defines, perhaps add some binding code.

Oh and you're welcome!

[Ibidem]

i have luck viewing youtube via both ff and chrome. i use real distro (fedora), so gnash does compile, but neither gnash nor adobe flash is installed. chrome has builtin plugin though.
but all this does not matter because i also have download buttons for youtube via ff plugin. it does not need new browser, it needs having some brains

Alpine uses a different libc that doesn't spill the guts of malloc everywhere, and gnash really hates that.
That different libc also means that Adobe Flash, Chrome, and pepper Flash aren't going to work without a good bit of mucking around.

Currently, the selection of browsers is much more limited than is some distros:
Firefox, Midori, Dillo, links, elinks, lynx, and now Otter.

I probably could use a Firefox plugin, though when I did that in Debian (a couple years ago) it was unreliable.

But I do have to say that the numbers he's using for RAM seem to be virtual memory - shared libs, which is arbitrary and garbage unless you turned off overcommit.

pmap -d explicitly excludes shared libs, try it on any process. Shared lib pages are not writable, shared lib data is, but so is static lib data. It's true it's not perfect as thread stacks are fully counted, but that means ~7mb per thread (8mb stack minus estimated 1mb needed), and no browser uses more than 10-20 threads, most use less than you have cores. Thus the maximum measurement error is ~140mb (depends on how many threads are used), not enough to explain the Otter/Arora RAM use. It's the best measurement I've found so far, way more accurate than top/other methods measuring RSS/VSZ.

I said that because the memory use I'm seeing for otter is usually under 200 MB VSZ (42 MB was RES for a couple tabs, with VSZ of just over 100 MB).
Seeing the difference, I looked at the output of pmap -d, I glanced at its output and top, noticed that pmap column 1 was VSZ, and somehow got the impression that column 2 was VSZ less shared libs. Looking again, it appears to match RES less shared libs.
But I still see no correlation between the numbers you have for Otter and what I see on my computer (Otter at roughly 0.9.04-dev45, Qt 5.3.2-r1, Alpine Linux edge; 1 GB RAM, swap off). I can see no explanation unless Tom's Hardware is eating massive amounts of RAM (I tried going there, but was blocked), or you have a completely different configuration of Qt5.

Still, I'm interested in Fifth; I might put together an APKBUILD shortly...

[Ibidem]

curaga: by the way, expect a pull request sometime soon; I'm trying to get WebkitFLTK building on musl, and have made a few small changes already (enough to build libwtf and some in JavaScriptCore)
It's mainly little details like OS(LINUX) vs defined(__GLIBC__), generic libstdc++ having different headers, whether isnan() needs to be in namespace std...

[Djhg2000]

Works well on Debian Jessie, however I had to use the precompiled version because "fltk-config --version" returns version 1.3.1 (despite having installed 1.3.2-6+b1). I like how lightweight it is, though I do miss having a spell checker (English is not my native language). I do realize this is an early version but I think I'll make it my primary browser if it proves stable enough, I really like it that much.

[curaga]

@Ibidem

Yeah, I saw your fork this morning and checked the commits. I'm willing to take changes like that, but as you're changing generic webkit code, you should also submit it to webkit.

They have a bit convoluted contribution process: post a patch to a bug report including a changelog in the proper ChangeLog file, mark it specially for review, and click the build bot requester button.

[curaga]

Works well on Debian Jessie, however I had to use the precompiled version because "fltk-config --version" returns version 1.3.1 (despite having installed 1.3.2-6+b1). I like how lightweight it is, though I do miss having a spell checker (English is not my native language). I do realize this is an early version but I think I'll make it my primary browser if it proves stable enough, I really like it that much.

FLTK 1.3.2 is not really enough, you'd get a fairly bad experience if it would even compile. Various focus issues, UI things, text editing matters are fixed in the recent 1.3.3 release.

Spell checking is quite possible to add, just needs somebody who wants it enough Look in editorclient.cpp in webkitfltk, and compare with the editorclient of other webkit ports if you're interested.

[pal666]

Alpine uses a different libc that doesn't spill the guts of malloc everywhere, and gnash really hates that.

you confused 'provides popular sysv api' with 'spills the guts of malloc everywhere'. also you try to use router distro to run browser. maybe main bug is within you ?

That different libc also means that Adobe Flash, Chrome, and pepper Flash aren't going to work without a good bit of mucking around.

that libc is broken, not different. different would provide same apis with different implementations.

I probably could use a Firefox plugin, though when I did that in Debian (a couple years ago) it was unreliable.

ff is perfectly capable of playing youtube without plugins. (on a real distro that is)

[Ibidem]

FLTK 1.3.2 is not really enough, you'd get a fairly bad experience if it would even compile. Various focus issues, UI things, text editing matters are fixed in the recent 1.3.3 release.

Spell checking is quite possible to add, just needs somebody who wants it enough Look in editorclient.cpp in webkitfltk, and compare with the editorclient of other webkit ports if you're interested.

It has a hard requirement on 1.3.3; set_active()/clear_active() are not present before then. But I'm having to do a little prodding with FLTK 1.3.3, since -fvisiblity=hidden makes fl_oldfocus hidden, breaking ABI (and the workaround for dillo allegedly causes focus problems); building src/Fl.o with -fvisibility-inlines-hidden instead works.

[curaga]

I'm not sure where exactly the Debian package lies between 1.3.2 and 1.3.3, it seems to have many patches from SVN.

That FLTK symbol is a lib-internal one, it's not in any of the public headers. Dillo really shouldn't use it...