Recently I tried using the Fossil chat room with my (older) trusted Firefox browser (Firefox-52.9.0 on a 64-Bit Linux system).

... Is that behaviour intended?

It "should" work on any "recent" browser, where "recent" is roughly the last 5 years (with MSIE being the obligatory exception because of its tendency to lag tech standards by 3+ years). If you can tell us exactly why it's failing, e.g. with messages from the dev console (tap F12 then reload the page), we might be able to get chat working on FF 52. It would also be interesting to know whether the /wikiedit page works for you (my vague suspicion is that it does not).

What browsers are recommended for the fossil web pages?

By and large the fossil UI works without any significant JavaScript, but certain "highly-interactive" applications are largely implemented client-side and require full HTML5 and JS6 (a.k.a. ECMAScript 6 a.k.a. JS 2015) support. Specifically, /wikiedit, /fileedit, and /chat fall into that category.

Are there any easy workarounds...?

One thing comes to mind which might be affecting you: if you have disabled the browser's ability to send referrer headers then none of our ajax-based pages will work for you. The referrer header is required for implementing Cross-Site Request Forgery (CSRF) protections and fossil provides no way of disabling those protections. Search this page for "CSRF" for information about enabling that setting in Firefox.

Aside from that, my only suggestion is a newer browser.

If you can tell us exactly why it's failing, e.g. with messages from the dev console (tap F12 then reload the page), we might be able to get chat working on FF 52.

In the "Web-Konsole" I see the following message:

TypeError: p.then(...).then(...).catch(...).finally is not a function

chat:1021:1

_

It would also be interesting to know whether the /wikiedit page works for you (my vague suspicion is that it does not).

I believe, it does work for me. I just created and edited the index page with it. It also looks the same as in Chromium-89.

One thing comes to mind which might be affecting you: if you have disabled the browser's ability to send referrer headers then none of our ajax-based pages will work for you. The referrer header is required for implementing Cross-Site Request Forgery (CSRF) protections and fossil provides no way of disabling those protections. Search this page for "CSRF" for information about enabling that setting in Firefox.

I have not disabled the sending of referrer headers. network.http.sendRefererHeader is set to the default value 2 according to the "about:config" page of my browser.

TypeError: p.then(...).then(...).catch(...).finally is not a function

Aha: /wikiedit and /filepage both use our own ajax API, whereas /chat uses the not-quiet-yet-standardized window.fetch API. According to:

https://caniuse.com/fetch

your version of FF supports that, but apparently that's not the case.

There's not a quick fix for that. Resolving it requires refactoring the fetch() calls in chat to use fossil.fetch instead. That's now on my list of TODOs.

There's not a quick fix for that. Resolving it requires refactoring the fetch() calls in chat to use fossil.fetch instead.

@mxb That's done but not yet in the trunk. If you can check out and try this branch, it would be really helpful:

https://fossil-scm.org/home/timeline?r=chat-fetch-port

Meanwhile i've installed this version on my server, where we've been using chat non-stop for a month or more, to test it for a few days there before merging. So far, so good.

I am rather delighted to have a working version for my trusted Firefox-52.9.0 now. :)

If you can check out and try this branch, it would be really helpful:

https://fossil-scm.org/home/timeline?r=chat-fetch-port

I compiled it via a downloaded tarball of that check-in...

With that executable I now get to see the loading buttons and the chat messages,
that I did not get to see with the stable fossil-2.14.

I can also succesfully post chat messages now.

The page footer now ends with "Fossil 2.15 [147ff84e21] 2021-03-21 18:51:54".

Appart from that, I have tried the Fossil chat with Firefox-86.
With that browser both versions of the chat work.
(There are a few features... only available in my old browser, that make me prefer that one however.)

Playing around a little, I switched back to serving the pages with Fossil-2.14,
while my Firefox-52.9.0 client was still in the chat.
As was to be expected, the chat continued to work, because the client still was using working code.
After reloading the chat page, the chat was of course unworkable again
- until I switched the server back to that new version and reloaded the chat page again.

The versions I compiled turned out to create far larger executables than f.e. the stable versions in the download section.
The first gets to be about 15 MB, the second just about 6.4 MB.

I have tried "configure --help" to perhaps find some configure option to get the file size down.
But so far I have not found any.

Try strip(1)'ing the binary. It may have symbol and debug data.

Try strip(1)'ing the binary. It may have symbol and debug data.

I had a rather quick look at the manpage.

I may need to look into that more thoroughly some time.

Using "strip fossil" did indeed bring down the size to about 4.3 MB!
And it was a fast process as well.

I don't know if that could perhaps also have done some damage
- apart from loosing the ability to properly debug...
Perhaps I should have used "strip -d fossil" instead.

So far I have not seen problems from the stripping.

Yes, I also thought, there could be debug data increasing the size.
And I was hoping so see a configure option like "--without-debug"
to keep the size down in the process of creating the executable.

Perhaps there really is such an option...

I am rather delighted to have a working version for my trusted Firefox-52.9.0 now. :)

Great, thank you for trying it out. Now we know that window.fetch is not as portable as we'd like.

I have tried "configure --help" to perhaps find some configure option to get the file size down. But so far I have not found any.

As John suggests, run "strip fossil" to remove the debug information from it.

As John suggests, run "strip fossil" to remove the debug information from it.

Thank you.
Your explicit statement increases my trust, that I have probably not damaged the executable by the command "strip fossil" - that really brought the size down!

I had noticed your reply only after my previous reply.

Your explicit statement increases my trust, that I have probably not damaged the executable by the command "strip fossil" - that really brought the size down!

Stripping just removes information useful for debugging - it won't damage your binary. It has all sorts of options but they're never needed outside of highly specialized cases.

Interestingly, though, the size of a fossil binary can vary wildly from one system to the next. On my x86/64 systems a static binary is nearly 7MB and a dynamically-linked on is 4.8MB. On my ODroid U3 (32-bit ARM) it's 3.5MB, and on my Pi4B (64-bit ARM but hybrid 32/64-bit kernel) it's 3.7MB.

Hello stephan! I am writing because you seem to have a (sadly really common) misconception.

The referrer header is required for implementing Cross-Site Request Forgery (CSRF)

No, it is not required! Although I have to admit, it's kind of easy to interpret the OWASP article you linked that way. The fact is, the referrer header is one of the things the attacker CAN easily spoof, therefore it should never ever be relied upon for security.

Instead, since a lot of sites still put sensitive data in the url (for example php defaults storing session id in url if cookies are disabled), referrers could even count as vulnerabilities. And all browser vendors agree: they disabled referrer sending from https sites to http sites. Of course they knew it is a half-assed solution, and they really cared about user's privacy too, so they disabled referrer sending everywhere... Nah, just kidding. Everyone deployed https and kept collecting referrer data while a "Referrer-Policy" http header was created for the few who wish/need to opt-out.

Regardless of the history and the privacy implications, I think the referrer checking code in Fossil should be orphaned to promote other, real CSRF mitigations - some are mentioned in the corresponding OWASP cheat sheet.

The referrer header is required for implementing Cross-Site Request Forgery (CSRF)

No, it is not required! Although I have to admit, it's kind of easy to interpret the OWASP article you linked that way.

Fair enough. Allow me to rephrase that as: required by fossil's implementation of CSRF protections. That particular topic and the underlying code are both entirely foreign to me, aside from ensuring that the bits of fossil i work on conform to the app's CSRF measures by calling the function which checks the request.