Fossil Forum

I can confirm it's not the version of Firefox per se, because I tried it in
one of my repos with version 126 and it worked fine. Maybe some browser
extensions you use? Do you have the same issue with extensions disabled?

Meanwhile, if you disable JavaScript (or use NoScript or similar) you should
get the old Forum version.

In any case, it would be good if we can reproduce your issue so it can be
fixed, if there's an issue that happens only under specific conditions.

I typed the preview tab, and then typed post. And happened: nothing.

Did you remember to press the Post button twice? If you press it once, it changes to a button that is labeled "Confirm submit [3]" where the number represents a timeout of 3 seconds that makes sure you want to post to the forum. If you don't press the button a second time within the 3 seconds it will not send the data.

I will now type preview press twice.Strange procedure.

It works!!! Thanks!

OP says:

I had also problems with these tabs in the wiki as I was trying to integrate mathjax in a fossil repo.

i'm not sure that can work with the new preview without us adding hooks to make it possible (to pass the client the updated preview element so they can post-process it).

Martin says:

I can confirm it's not the version of Firefox per se, because I tried it in one of my repos with version 126 and it worked fine.

With the exception of the locking of an edit to keep multiple tabs from stomping on each other, it "should" work for any browser going back at least 5 years. If it requires something newer than that (and cannot gracefully fall back like the locking can) then it's a bug and it's my fault.

Andy says:

Did you remember to press the Post button twice? If you press it once, it changes to a button that is labeled "Confirm submit ..."

You might not believe how frequently that button's creator forgets to do that :/.

Thanks to everyboda and excuse for the troubles. I did not get that I have to confirm and click twice. As far as I knew, confirming many times is a Windows procedure.

Well, I did not forget to press the button. I did not even come to the idea that I have to press it twice. Thanks to Andy Bradford for the detailed explanation. I really needed it. I never used Windows except at small pauses at the library to surf in WWW. The same with all that "Desktops Environments" whose purpose I never understood. Just only X11 with mainly twm or fvwm, after using cli in vt100 and similar. Believe me, twice clicking is definitively not normal. Typing "yes" after a commando also not.

For replying I am seeing two previw buttons. First in among three tabs (Reply, Previe, Help), and above it together with the post button.

I was enthusiastic that the forum and wiki worked with mathjax, at least with plain text. The preview in the wiki does work. I must test the forum. With pikchr does not work.

Believe me, twice clicking is definitively not normal.

No, but people immediately editing posts a few seconds seconds after they submit is, and those send notification mails to hundreds of people, so a confirmation is required before posting. It gives us a moment to reconsider before triggering those emails.

With pikchr does not work.

Works for me?

Believe me, twice clicking is definitively not normal.

It’s not just like a button that needs a double click on a webpage (I would find that weird too). But when clicking once, the text change for “confirm submit” with a countdown timer.

Yes, it’s different, but I find it’s a great idea to avoid accidental post. Z db4d98a

I meant pikchr with mathjax. It would be nice if one could put a formula inside a pikchr square. But the code mathjax generates probably conflicts with pikchr.

the code mathjax generates probably conflicts with pikchr.

It would be better to say that MathML — MathJax’s output form — is opaque to Pikchr.

One of Pikchr's core operating principles is sizing objects based on rough guesstimates of font metrics, which in turn is based on a presumption that it is running inside a CSS environment where the fonts are “normal,” as with the stock Fossil skins. This is why the default padding is generous, and even with “fit” there’s a bit of air around the text. It’s trying to avoid clipping the text without going to the trouble of rendering it and then measuring its exact pixel dimensions. It guesses, rather than measures.

Now consider what this means when the text Pikchr sees — MathJax markup — gets rendered to another form out from under it, and even then, Pikchr cannot be expected to make good guesses about what it will be rendered as, in MathML form. As but one example, what is the width of sqrt(x)? In MathJax, that’s two glyphs that render on top of each other, with the outer one’s width set in part by the width of the inner one. This is far beyond Pikchr’s ability to cope with; in its present state, it will just count seven glyphs and make its guess based on “normal" font metrics, leaving you with too much air around your √𝑥 left and right, but a smidge too little on top, because it isn’t accounting for the upper bit of the surd sign.

The situation isn’t hopeless, but to do as you’d wish, MathJax would have to run first on page load, and only then could you run a WASM-compiled Pikchr instance — as used by /pikchrshow — that has been taught how to look at the rendered DOM and get exact pixel measurements to compute its object sizes for layout purposes. All doable…and yet undone, at present.

Complicating all this is that the Fossil project will never — as a matter of longstanding policy — take on MathJax as a first-party dependency, so any accommodation for its possible use has to be done conditionally, ideally in terms of the DOM alone, so that the browser intermediates between the two. That then requires you to carefully sequence things at the skin level (?) so that the MathML rendering occurs before the Pikchr rendering.

Patches thoughtfully considered. 🧐 Z ee4631a1aecfd6d77f6f9a86b8b764b5

But when clicking once, the text change for "confirm submit" with a countdown timer.

To be fair, the first time I tried the new Forum post editor, I too didn't notice that I had to click the button a second time before the timer expired. I only noticed it because I had another browser (or tab) open for a different thread and navigated to the list and didn't see my response.

Perhaps the interaction is too subtle?

Perhaps the interaction is too subtle?

Fair assessment. We can style the buttons differently while counting down, or use some completely different confirmation (not counting window.alert(), which browsers give the user the option of disabling because marking people used it too much in the 1990s). Suggestions and/or patches are welcomed.

Another UX oddity this feature causes occurs on phone screens, where the countdown forces a recomputation of the layout on each timer tick, which can cause the button to jump about, “evading” your tap.

Between this and the confusion over novel (thus unexpected) UX, are you certain it’s paying its freight? Z 9ae

Kill two birds with one stone: do away with the timer. Change the button back to 'Submit'/'post as user' if it loses focus, such as in the intended case where you have second thoughts and decide to do something other than submit. In the other case, the user has as long as they need to figure out what is going on and make the positive decision to click again.

I wonder if the code to do this should be there anyway: playing around with it to see if the loss of focus already has some effect, clicking post then something else like the edit window or Preview or even 'Help!' leaves the counter running. That feels slightly disconcerting, though also over picky.

Trevor

Another UX oddity...

i'd not seen that but yeah, that would irritate me.

Between this and the confusion over novel (thus unexpected) UX, are you certain it’s paying its freight?

Not even a little!

Trevor says:

Kill two birds with one stone: do away with the timer. Change the button back to 'Submit'/'post as user' if it loses focus, such as in the intended case where you have second thoughts and decide to do something other than submit.

Hovering and losing focus are desktop-specific. Mobile doesn't have those so we can't rely on them for anything. Z

If at least it would render the formula and one could adjust the size manually ...

Some emails clients have a grace period of, say, ten seconds between pressing the Send button and actually sending a message. During that grace period, an Undo/Cancel button becomes prominently available to block the delivery. For Fossil, it might be, for example, an overlay with a timer at the bottom of whatever page the user is seeing. And the delay could be customised in Fossil's settings.

Another UX oddity...

i'd not seen that but yeah, that would irritate me.

Between this and the confusion over novel (thus unexpected) UX, are you certain it’s paying its freight?

Not even a little!

Trevor says:

Kill two birds with one stone: do away with the timer. Change the button back to 'Submit'/'post as user' if it loses focus, such as in the intended case where you have second thoughts and decide to do something other than submit.

Hovering and losing focus are desktop-specific. Mobile doesn't have those so we can't rely on them for anything. (Edit: mobile has focus, but giving focus to one on mobile almost necessarily requires tapping it.) Z

For Fossil, it might be, for example, an overlay with a timer at the bottom of whatever page the user is seeing.

If we delay the sending we risk that the user closes the page or switches tabs (in which case the browser might make this one go idle). Okay, we've got the local edit stash, so that might not be too horrible, but it would be irritating to sit and wait for it to send before i can tap ctrl-w (as is my norm, visiting most posts directly via their email notifications).

For what it's worth, I've experienced the new post UX,
and find it very confusing. Had I not read (skimmed) this thread,
I probably would not have "sent" my post, and noticed later I guess.

Not a fan. Now I know its quirks, so fine. But not friendly to newcomers.

Not a fan. Now I know its quirks, so fine. But not friendly to newcomers.

Patches and concrete suggestions are happily received. Vague statements of annoyance aren't actionable.