Fifth: A New Web Browser Based On WebKitFLTK

[curaga]

Would it be likely to work if I build the same way but with -fPIC (and the -static-...stuff gone)?

Not sure.

A minor rough spot I ran into with the Fifth configure script earlier: the version test uses <webkit.h>, so to install in /opt/wkf/ you need something like

CXXFLAGS="-I/opt/wkf/include -I/opt/wfk/include/webkitfltk -L/opt/wkf/lib

.
If there were an option like --with-webkitfltk=..., it would be a nice aesthetic touch.

In the latest versions (0.1.1 or current git) the path comes from the pkg-config file. So if you installed to /opt/wkf,
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/wkf/lib/pkgconfig ./configure

[Ibidem]

jsc no longer segfaults in the dynamic linker with -fno-pie (it crashes a little later, but that may be a known issue about thread stack size).

[curaga]

If you pull latest git, it now explicitly sets a good thread stack size. Musl's default 80kb is way too small.

[Ibidem]

If you pull latest git, it now explicitly sets a good thread stack size. Musl's default 80kb is way too small.

Thanks. But I encountered this:

$ Source/WebKit/fltk/testapp/testapp
Error compiling builtin: 
ASSERTION FAILED: result
parser/Parser.h(970) : WTF::PassRefPtr<T> JSC::parse(JSC::VM*, const JSC::SourceCode&, JSC::FunctionParameters*, const JSC::Identifier&, JSC::JSParserStrictness, JSC::JSParserMode, JSC::ParserError&, JSC::JSTextPosition*) [with ParsedNode = JSC::ProgramNode]
Segmentation fault (core dumped)

I do get a window, though.
This is after building in a dirty tree, so I don't know if everything that should have been built was.

[curaga]

That's the same as what jianzhong.huang posted to the musl list. I'm afraid I can't help there.

[curaga]

Phoronix spurred the implementation of usercss, I could no longer bear having to zoom out on the front page

[curaga]

New release for our non-git using friends.

v0.2
UserCSS.
Improved middle-clicking link behavior.
Iframe behavior fixes.
Ubuntu dash build fix.
Various bugfixes.

[curaga]

v0.3 released today. https://groups.google.com/forum/#!to...al/MWnf8y0ywN0

I'm happy to announce the new releases of WebkitFLTK and Fifth, 0.3 for both. The main points are usability and crash fixes, with only one bigger feature change, localStorage, enabled in such a way that you can't be tracked across sessions. Also cheers to the folks at Linux Format. I only recently heard of the feature in this year's February edition. Shortlog: WebkitFLTK ? ? ? Fix media-related crash on Steam store pages ? ? ? Group-protect the paster widget ? ? ? Add a new callback for tracking individual resources, including deferred ones ? ? ? Add limited support for running without X ? ? ? Allow enabling localStorage, but only in RAM ? ? ? Pass the suggested filename when converting main to dl, too ? ? ? Treat the clipboard as UTF8 ? ? ? When the pretty URL and real URL conflict, and protocols differ, use the real one ? ? ? Make the erroring url a link, for easier copying and retrying ? ? ? Backport all applicable webkit regression fixes Fifth ? ? ? Fix a crash when popping up an error console with some messages ? ? ? Urlbuttons now pass scrolling keys directly to web, if any ? ? ? Tabbar: treat drags < 10 pixels as clicks ? ? ? Add a toggle for localStorage ? ? ? Make sure control is passed while the url list is open, fixes a crash ? ? ? bookmark converter: Handle invalid directories, fixes #14 ? ? ? Document the use of proxies ? ? ? The home key takes focus ? ? ? The speed dial does not do partial redraws ? ? ? Add some common user-agent strings ? ? ? Add a file browser button to the usercss ? ? ? Make sure the shift-ctrl status is updated when pressing enter in the url dropdown https://sourceforge.net/projects/fif...ser/files/v0.3

[curaga]

Well yikes, this forum is horrible. Eats linebreaks for breakfast, and I cannot even edit my post. Read from the link.

[cb88]

Nice... glad to see it still progressing. I know this is a bit far out there but would it be possible to substitute the javascript engine for something more portable ala ductape even if it isn't fast at least it would work for alot for things... the rest should be pretty portable already. And hopefully WebAssembly will enable a more portable jit infrastructure that what we currently have.