Fossil Forum

If I clone the "tips" repo and launch it locally (using "fossil ui tips.fossil") then "New Thread" also works there. I think there might be something wrong with Stephan's JS on that page. I'll leave this for him to debug...

For anyone willing to have a look: Write access to the forum requires an account, which can be created using self-registration.

With my apologies for the delay.

i have done so and can reproduce it, but only on that site, and i've currently no clue how that site is different.

The immediately suspect was the "jsbundle" mode but i've just tested a clone of /tips with all of those options and it's working fine. (BTW: changing that from "inline" to "bundled" will, in the aggregate, save a fair amount of bandwidth because fossil goes way out of its way to make its JS cacheable.)

i do see two requests blocked from your site - external requests to cloudflare which both ublock origin and my browser's default settings block, but i can see no way how those would interfere.

click... click... click...

The clues...

• The JS is all there in the page. The only errors reported in the console in FF or Chrome are from the Cloudflare request blockage.
• The DOM inspector shows that the skeleton for the new forum widget is there, which says that the JS is never being run.
• However, the old form is missing, which says that it was ripped out before the JS failed (without any dev console errors).
• After hitting the page many times with the dev tools open, i sometimes see the old form appear and then disappear, which further suggests that the JS is failing between the time it unplugs that and plugs in the new one.
• The browser debugger is not catching any exceptions, which suggests that the failure is not an error, per se, but that it appears to be aborting the process normally (in error).

Without dev console errors the only option i have is the fine-toothed-comb one. Similarly disappointing, no workaround which would restore the old form comes to mind. It's well past bedtime here but i will get on this tomorrow immediately after the dog walk.

For anyone willing to have a look: Write access to the forum requires an account, which can be created using self-registration.

With my apologies for the delay.

i have done so and can reproduce it, but only on that site, and i've currently no clue how that site is different.

The immediately suspect was the "jsbundle" mode but i've just tested a clone of /tips with all of those options and it's working fine. (BTW: changing that from "inline" to "bundled" will, in the aggregate, save a fair amount of bandwidth because fossil goes way out of its way to make its JS cacheable.)

i do see two requests blocked from your site - external requests to cloudflare which both ublock origin and my browser's default settings block, but i can see no way how those would interfere.

click... click... click...

The clues...

• The JS is all there in the page. The only errors reported in the console in FF or Chrome are from the Cloudflare request blockage.
• The DOM inspector shows that the skeleton for the new forum widget is there but still hidden, which says that the JS is never being run.
• However, the old form is missing, which says that it was ripped out before the JS failed (without any dev console errors).
• After hitting the page many times with the dev tools open, i sometimes see the old form appear and then disappear, which further suggests that the JS is failing between the time it unplugs that and plugs in the new one.
• The browser debugger is not catching any exceptions, which suggests that the failure is not an error, per se, but that it appears to be aborting the process normally (in error).

Without dev console errors the only option i have is the fine-toothed-comb one. Similarly disappointing, no workaround which would restore the old form comes to mind. It's well past bedtime here but i will get on this tomorrow immediately after the dog walk.

Similarly disappointing, no workaround which would restore the old form comes to mind.

Not a fix, but a one-shot workaround: it turns out that if you pass ?nojs to /forumnew, that causes it to not plug in the new editor. It doesn't disable all JS, it only skips the editor-swap which happens in the new form. However, there is no one central route to that page so we can't just monkey-patch your site's links to include that (as a temporary workaround).

The problem is still an absolute mystery but is being actively investigated with priority. It's still, even with the fossil version deployed on the tips forum, unreproducible anywhere but from that remote site/forum combination.

For anyone willing to have a look:

Mystery solved: that site uses a completely custom BODY tag, which is fundamentally incompatible with several of our JS apps and CSS rules which filter on the body's CSS class list to toggle certain sections on.

The tips /forumnew has: <body>

But a working forum emits: <body class="forum rpage-forumnew cpage-forumnew">

So the quick fix for your site is to visit it with a non-edited skin: https://core.tcl-lang.org/tips?skin=default (passing skin= unsets the preference and reverts to the broken one).

We do not currently have a way to inject those CSS class names into custom skins, so we don't have a way for you to patch your custom skin for this. i will look into that, but your short-term workaround is to not use the skin you're currently using. Once we have a fixworkaround, it will involve you editing your skin to ensure that the proper CSS classes are in place. That's not just a fix for this page, but for a growing number of them where CSS filters like body.cpage-wikiedit is used to enable certain JS and CSS only on certain pages.

Both of your work-arounds look like they will allow people to create a new thread again. For now that unblocks the workflow. Thanks for the quick response.

I am ready to start editing the skin, once that option has been added.

I am ready to start editing the skin, once that option has been added.

It turns out there's no need: we now, as of programmatically inject those classes into the BODY during our JS bootstrapping, so they'll get injected even for skins which emit bare BODY tags. We're now just waiting for US East Coast to wake up so we can get that deployed.

PS: the reason it was not locally reproducible at first was because a local cookie was causing me to use the "default" skin, which does not repro the problem. Only by clearing my local cookies and storage did the problem appear locally, at which point the source of it was found almost immediately.

I am ready to start editing the skin, once that option has been added.

It turns out there's no need: we now, as of programmatically inject those classes into the BODY during our JS bootstrapping, so they'll get injected even for skins which emit bare BODY tags. We're now just waiting for US East Coast to wake up so we can get that deployed.

PS: the reason it was not locally reproducible at first was because a local cookie was causing me to use the "default" skin, which does not repro the problem. Only by clearing my local cookies and storage did the problem appear locally, at which point the source of it was found almost immediately.

Edit: this problem would have shown up much sooner if /chat were in use on that repository, as /chat misbehaves spectacularly if the body is missing its fossil-set CSS classes.

The Fossil on core.tcl-lang.org has been recompiled with Stephan's latest fixes and appears to be working now.

It's all looking good again. Thanks.

It turns out there's no need

Nevertheless, the change to how the skin handles <body> tags goes back to 2018, in release 2.5. One has to wonder what other things they're lagging on, and should sync up.

This is why the skin editor has a diffing feature.

Unfortunately, cloudflare blocks diffing the page header text. It will probably block submitting any changes as well. I guess it considers submitting HTML to be very naughty.

Fossil takes being a distributed version control system to its limits. If you have suitable permissions on the remote:

$ cd ~/a/checkout/directory
$ fossil conf pull all
$ fossil ui

Now make your skin changes, test them locally, and then:

$ cd ~/a/checkout/directory
$ fossil conf push skin

Now it's running on the remote without any need for Cloudflare's sign-off.

(The "all" in the first command is technically an over-reach, but if you're intending to have a clone mirroring the remote as closely as possible, you want all the config zones.)