Expand / collapse button for forum posts:

• Changing the width of the web browser window, so that running text may reflow horizontally and take up more or less space vertically, does not update (i.e. activate or deactivate) the expand / collapse button. This can lead to the situation of hidden text that is impossible to make visible.

• The double-clicking action for the text of an overlong post (which would normally initiate word-by-word selection mode†, for example) seems to have been repurposed so that it acts the same as clicking expand / collapse, but combined with a "random" jump in the scrolling position (presumably, to scroll the expand / collapse button to the top of the viewport). This considerably disrupts reading flow, and makes selecting and copying text inconvenient, for example from long posts containing source code specimens.

† In fact, I'm doing a triple-click to initiate line-by-line selection mode, and then using the (Ctrl+)Shift+Arrow keys to expand the selection to the desired amount of lines, but that is broken, too.

Wiki editor:

• "Save changes" → "(3...2...1) Really save changes?" Seriously? ;-) Since this "confirmation" doesn't seem to prevent any impending loss of data, it should really be dropped. By the way, the button text is changed from "Save changes" to "Save" after the countdown has elapsed.

Backwards compatibility:

• This is not a request for the new features to support old browsers, but this check-in breaks the side-by-side diff scrolling in IE. I'm regularly using Fossil on legacy physical and virtual machines, and I'd be very happy if at least the basic functionality could be left intact, i.e. if this part could be reverted to non-modernized.

Windows compatibility:

• Neither of the AJAX-ified /fileedit nor /wikiedit pages seem to work on Windows (tested with the preview builds downloaded from the Fossil website). I haven't found the time to investigate, but a quick glance at the browser's network tab shows that the former gets an empty XHR response for the "commit" action, and the latter gets 404 XHR responses for various actions.

Changing the width of the web browser window, so that running text may reflow horizontally and take up more or less space vertically, does not update (i.e. activate or deactivate) the expand / collapse button. This can lead to the situation of hidden text that is impossible to make visible.

That happens because the expand/collapse is only applied when the page is loaded, and only applies to posts which are currently taller than the size limit. i'm not sure how it could be applied dynamically to all posts, but suggestions are welcomed.

The double-clicking action for the text of an overlong post (which would normally initiate word-by-word selection mode†, for example) seems to have been repurposed so that it acts the same as clicking expand / collapse, but combined with a "random" jump in the scrolling position (presumably, to scroll the expand / collapse button to the top of the viewport).

It scrolls to the top of the next post. If we don't do that when collapsing the post when you end up "somewhere" in the page, but it might be 5 posts below the collapsed one (depending on how tall it was).

This considerably disrupts reading flow, and makes selecting and copying text inconvenient, for example from long posts containing source code specimens.

It disrupts the flow more if we don't scroll, i promise. Suggestions on how to better handle the collapsing case are welcomed. For me it seems that the only reasonable/consistent thing we can do is scroll the next post into the viewport.

† In fact, I'm doing a triple-click to initiate line-by-line selection mode, and then using the (Ctrl+)Shift+Arrow keys to expand the selection to the desired amount of lines, but that is broken, too.

i didn't even know that triple-click and arrowing around was a possibility :/.

i don't like the double-click to collapse, but i more dislike having to scroll down 500 lines to find the collapse button.

Apropos: consider what happens if you scroll down 500 lines, tap the collapse button, and then we don't scroll the next post into view. The answer: you have to scroll back up 500 lines to get to the post which comes after the collapsed post.

"Save changes" → "(3...2...1) Really save changes?" Seriously? ;-) Since this "confirmation" doesn't seem to prevent any impending loss of data, it should really be dropped.

It's far too easy to accidentally save if there's no confirmation (i've done it) and i refuse to use window.confirm() for reasons previous discussed at length. We can change the label, yes, but i'm not removing the confirmation. As said before, if someone will implement a custom modal confirmation dialog API which does not require confirm() then i will gladly switch to that one.

By the way, the button text is changed from "Save changes" to "Save" after the countdown has elapsed.

Once the ajax request starts the button is still in the "the page has unsaved changes" state until the ajax request is complete. The button is disabled at that point, though (that different is not visible in all skins). We could arguably change the text to "saving...", but that currently feels like overkill. i'll look into that later on today, though.

This is not a request for the new features to support old browsers, but this check-in breaks the side-by-side diff scrolling in IE. I'm regularly using Fossil on legacy physical and virtual machines, and I'd be very happy if at least the basic functionality could be left intact, i.e. if this part could be reverted to non-modernized.

That first line is fixing illegal code. The second one i can rewrite, but, honestly, we can't be expected to support all JS code on non-standard platforms. If the browser does not support forEach() in that context then it doesn't fully support HTML5, and fossil's pages are HTML5. Part of HTML5 compatibility is supporting the accompanying JS APIs.

If that forEach() addition is breaking in your browser then there's no way that either wikiedit or fileedit will work in that browser, as both make heavy use of the standard forEach() APIs.

Neither of the AJAX-ified /fileedit nor /wikiedit pages seem to work on Windows (tested with the preview builds downloaded from the Fossil website). I haven't found the time to investigate, but a quick glance at the browser's network tab shows that the former gets an empty XHR response for the "commit" action, and the latter gets 404 XHR responses for various actions.

i'll need more information than that. i don't have Windows to test on and there's nothing in the JS code which is browser-specific (resp. the JS uses only standards-defined APIs). My vague suspicion is that your browser is not sending HTTP referrer information with XHR requests, and those pages cannot work without that (it's needed for CSRF validation). You might also be running into a missing forEach() implementation, as above.

If you're talking about any version of IE older than <= 11 then it's almost certainly not going to work and there's no fixing that without going back to a static wiki editor. Edit: MSIE <= 11 won't work because they're missing NodeList.forEach.

If you're talking about any version of IE older than 11 then it's almost certainly not going to work and there's no fixing that without going back to a static wiki editor.

MSIE 11 also doesn't support forEach() on querySelectorAll() results:

https://developer.mozilla.org/en-US/docs/Web/API/NodeList/forEach#Browser_Compatibility

MSIE is the only HTML5-era browser which doesn't support that, and the new ajax pages will not work as-is without that functionality. "Fixing" them to work with such browsers is left as an exercise for someone who has those browsers to test with.

We could arguably change the text to "saving...", but that currently feels like overkill. i'll look into that later on today, though.

That's now checked in but was a bit of a hack, as it required working around "linear timing" assumptions which made relabeling impossible (namely, after confirmation the confirmation process reverts the button's text to its pre-confirmation state, so any label change made by the save process gets overwritten microseconds later).

https://fossil-scm.org/fossil/info/9f3747d8a5542a06

It's far too easy to accidentally save if there's no confirmation (i've done it)

To clarify why making accidental saving "less likely" is so important to me: if we were "just" saving in the normal sense, overwriting an existing wiki page, saving by accident would not bother me at all. However, any save is creating a permanent blockchain entry which cannot be undone without restoring the whole repo from a backup. The ability to easily create an accidental permanent entry in the blockchain doesn't sit well with me, and thus wikiedit and fileedit make extra effort to keep that from happening.

It's far too easy to accidentally save if there's no confirmation

The old editor had an "unprotected" Save button. I don't recall a huge problem resulting from this.

Furthermore, very few other software programs second-guess you when you say Save.

What's next, a "Yes, I'm really sure" for fossil ci as well?

Even in the rare case where you do accidentally save, what's the cost? Wiki posts are deltified, so it can't be space. If it's accidental publication before you're ready, you probably shouldn't be using wiki anyway. The whole point of wiki is, "This is the current version of the doc as of the last time I edited it."

This feature is solving a tiny problem at a cost to everyday usability. Please take it out.

If you're feeling adamant about keeping this, then you might ask why you keep hitting that button accidentally. Maybe you should just move it to where you're less likely to do that?

If the browser does not support forEach()...

This feature you're using is only in 92% of browsers globally. 8% is too much user base to throw out, IMHO.

As for where the threshold is, I'd say it'd have to be somewhere under 1%.

The solutions are to either use a helper library like jQuery or to include the polyfill in your code. Once you follow the second path enough times, you've overpaid for not using a helper library. :)

i don't have Windows to test on

Microsoft provides free IE11 VMs for the purpose.

I agree with Warren on the save/countdown button. It's annoying and should go.

Also one thing I miss is that on save it doesn't exit the editor and display the page I just saved like the original editor.

I though the pagename above the edit console on the left was a link to display the page. But it's not.

So I would ask for:

• save exits the editor and displays the saved page

you can:

• add a checkbox [ ] keep editing

if you feel the user should be able to stay on the page.

Thanks for considering this.

I agree with Warren on the save/countdown button. It's annoying and should go.

Apparently i'm going to have a fight on my hands if i want to keep this. i don't mind saying: i think all of you are wrong on this point ;) and will attribute it to the general insanity currently going on worldwide ;).

If i remove that, i HAVE to remove it from fileedit as well, simply for consistency's sake (consistency counts for a lot). Please consider carefully whether it should be possible to accidentally, via mis-click, make a commit via the web interface.

The save confirmation is now removed in the trunk for wikiedit^misref, but it is retained for the discard/reload button because it's too easy to lose edits without a confirmation there, especially since it's right next to the save button. Removing it from fileedit is still TODO (because consistency dictates both-or-neither). (EDIT: nevermind - the fileedit commit doesn't have/need a confirmation because tapping that particular button by accident is exceedingly unlikely.)

^misref = i'm still very unpleased about that.

Also one thing I miss is that on save it doesn't exit the editor and display the page I just saved like the original editor.

That's very much by design. Just added: another link across the top/right (where the history link appears) which will return you to the "viewer" page.

save exits the editor and displays the saved page

That's not going to happen, plain and simple. It literally never crossed my mind that someone would want it to do that, as it's a more cumbersome way to work.

i love being able to edit multiple pages without having to leave the editor. If it can only edit a single page and then the editor closes then the whole page selection infrastructure (the first tab and its related Ajax route) is quite useless: we could simply require passing on the name of the page to edit in the URL like the old-style editor does. (That's supported as well, but it's not required, and that's a feature, not a bug.)

add a checkbox [ ] keep editing

if you feel the user should be able to stay on the page.

i won't add such a checkbox defaulted to on, as that would seriously annoy my own usage of the editor. i'll look at adding one defaulted to off, though.

What i could be convinced to do is that if the page is passed a page name when it's started (meaning it was probably visited via one of the edit links), the checkbox defaults to checked, else it defaults to not checked.

... click click type type ...

Nevermind: i am convinced that with the addition of the "viewer" link (see above), the checkbox simply adds unnecessary clicks and UI noise. Please try out that link and let us know how you feel about it. The checkbox hasn't been ruled out but i'm not convinced that it would be that useful now.

---

1. ^{^ a b} Misreference

save exits the editor and displays the saved page

Rather than a checkbox, i have locally (not yet checked in) added a second save button labeled Save & Close which, if saving succeeds, sends the user back to /wiki?name=.... That seems far easier to use than a checkbox, and gives both of us the editing style we want.

Is that agreeable?

Can you suggest a label for the other save button? Save & Continue sounds silly to me. It currently says "Save changes", but "changes" seems kind of redundant, especially since the save buttons are disabled until it detects that edits have been made (whether or not those edits really equate to a change, as tracking that would be computationally/battery life expensive).

So I would ask for:

save exits the editor and displays the saved page

Follow-up after 6+ months of using the new wiki editor: though i admittedly first thought that "save & exit" was a silly idea, in no small amount of practice it turns out that i literally never use the "save" button, always preferring the "save & close" button. i'm half tempted to remove the "save" button, but figure someone will cry out if it suddenly disappears. (Edit: nevermind - that button still allows me to edit multiple wiki pages in a single sitting.)

More proof that forum feedback on new features is generally a good thing.

I'm still glad you took out the double-tap confirmation bit.

As for Save vs Save & Close, I misused Save the first few times, thinking it was just a way to force use of the browser-side data saving, ending up with published commits before I was ready. Once I realized the distinction, I've largely stopped using Save, since I can usually finish an edit session before my 1980s trained Save reflexes push me to explicitly save my work.

About the only time I do use it is when I've got a very long edit in progress and find myself at a convenient stopping point and want to publish what I have. It's rare, but it happens.

Once I realized the distinction, I've largely stopped using Save, since I can usually finish an edit session before my 1980s trained Save reflexes push me to explicitly save my work.

Anecdote: Turbo Pascal 4's IDE didn't save before running its program, and i lost work more than once in late-80's high school comp-sci class because the code endless looped or some such and required a reboot of the DOS system. (We also had a prankster who liked to unplug monitors, leaving the user thinking the computer had crashed and prompting them to press the power button.) After the first couple of times, one quickly learns to save every time the fingers are idle, and that habit still lives with me today.

That said...

Once you get used to /wikiedit and /fileedit automatically stashing edits in window.localStorage every time the editor widget loses focus, you'll wish that i would finally get around to doing the same thing in the forum editors ;).

The old editor had an "unprotected" Save button. I don't recall a huge problem resulting from this.

Furthermore, very few other software programs second-guess you when you say Save.

Most apps don't irrevocably modify a blockchain. That's the sole reason i aim to make saving a "non-kneejerk-reaction" feature.

What's next, a "Yes, I'm really sure" for fossil ci as well?

In the CLI confirmation is implicit in having to type out the full command. A single tap or click, very possibly by accident, does not imply confirmation.

This feature is solving a tiny problem at a cost to everyday usability. Please take it out.

i disagree thoroughly that having to tap twice in the same screen location qualifies as a usability penalty. If we remove it from wikiedit then we have to, for consistency, do the same in fileedit, and fileedit is where accidental saves really need to be avoided.

In Windows one has to double-click to open anything, so we could argue that Windows requires confirmation to even open a file. (And then there's the "are you sure you trust this executable?" dialog for a double confirmation.)

If you're feeling adamant about keeping this, then you might ask why you keep hitting that button accidentally. Maybe you should just move it to where you're less likely to do that?

i've done it once, and that was too many times. If you have a suggestion for a placement for an accident-safe placement of the save button, i'm all ears, but keep in mind the note above about fileedit. (If we add a drop-down menu for it, it's still two taps away, with the taps being in different screen locations, increasing the usability pain.)

This feature you're using is only in 92% of browsers globally. 8% is too much user base to throw out, IMHO.

We cannot expect anyone who writes JS for fossil to be aware of, and code around, every missing feature of MSIE. That's a return to the pre-jQuery days of JS.

The solutions are to either use a helper library like jQuery or to include the polyfill in your code. Once you follow the second path enough times, you've overpaid for not using a helper library. :)

We know that 3rd-party libs are well-beaten topic, and any 3rd-party library other than the most trivial of polyfills is not something i am comfortable including into the tree just for the sake of a minority-share (and shrinking) browser. Aside from NodeList.forEach(), i have no reason to believe that MSIE is missing any other of the standardized APIs we use.

i will put some effort into working around this, but i'm going to grumble and moan about it the whole time.

Microsoft provides free IE11 VMs for the purpose.

And i have a stubborn streak which prohibits me from testing an even more stubborn browser.

Most apps don't irrevocably modify a blockchain.

Fossil used to. :)

A single tap or click, very possibly by accident, does not imply confirmation.

Maybe what you want instead is a "revert to version" feature in the editor. That should exist anyway. Working with historical wiki versions has always been more difficult than it needed to be.

In Windows one has to double-click to open anything,

What has that got to do with anything? The correct analogy is to File → Save.

I'm surprised a proper double-click works here anyway. That should be a different UI event from two single clicks. I suppose it works only because it's a different button after the JS changes it the first time, so the browser delivers two different onClick events to the handler.

You've replaced standard behavior with nonstandard behavior and are now claiming that it's less likely to cause problems.

...does not imply confirmation.

That's where we differ: I don't want Fossil to ask for confirmation. I want the tool to do what I told it to, because I've got my Big Boy Pants on right now. If I screw up, I've got re-edit, purge, and shun to fix it today, and hopefully "revert" later.

I assume part of what's going on here is your frequent use of a tablet. I don't use /fileedit or /wikiedit on a tablet, so to me, it's not like my mouse is going to go wandering off and clicking buttons randomly. For you, just picking the tablet up may click things based on how you grab the nearly-borderless screens that are in vogue right now.

Therefore, I wonder if you should make this conditional on mobile.

Maybe what you want instead is a "revert to version" feature in the editor. That should exist anyway. Working with historical wiki versions has always been more difficult than it needed to be.

That's something i looked at early on and punted to "version 2." i'd first like to get the forum editor ajaxified, as having that would have simpified my life somewhat today.

What has that got to do with anything? The correct analogy is to File → Save.

What is has to do with anything is that double-tapping a save button is exactly the same amount of work as opening anything in Windows (i.e. most users expect 2 clicks). As far as File→Save goes, double-tapping the save button is literally one half as much work as move mouse → click File → move mouse → click Save.

Is one "extra" click really that onerous, provided that not having it increases the odds of "polluting" the blockchain with unwanted edits? (That's a rhetorical question.)

You've replaced standard behavior with nonstandard behavior and are now claiming that it's less likely to cause problems.

i'm claiming it's less likely to cause accidental rubbish in the blockchain.

The standard solution would be a confirmation dialog, but:

1. window.confirm() is simply out of the question because browsers can and do block it, and how it responds to JS (true or false, i.e. confirmed/cancelled) when it's blocked is undefined.

2. Properly implementing a modal confirmation dialog which works well on both desktop and mobile is beyond my current level of ambition.

3. My understanding, based on feedback in this thread, is now that any confirmation would seem onerous.

i will add, though, that several of fossil's static pages offer no Save option until their corresponding Preview option has been used. i.e. they also require a confirmation. i don't recall whether the static /wikiedit required a preview first, but believe that it did. The forum editor does (and will likely continue to once it's ajaxified).

In any case, the save confirmation has been disabled, so it's now a moot point. i'm not happy about that, but am a fan of democracy.

I suppose it works only because it's a different button after the JS changes it the first time, so the browser delivers two different onClick events to the handler.

It's the same button - only the text gets swapped out.

If I screw up, I've got re-edit, purge, and shun to fix it today, and hopefully "revert" later.

And it all could have avoided had an extra tap been required ;).

I assume part of what's going on here is your frequent use of a tablet. I don't use /fileedit or /wikiedit on a tablet, so to me, it's not like my mouse is going to go wandering off and clicking buttons randomly.

Indeed - scrolling around on a tablet, it's easy to invoke a click somewhere without intending to. If it were only usable via mouse, it wouldn't bother me nearly as much, but an overwhelming percentage of my modern-day computing is tablet-based, largely for the sake of my hands.

Therefore, I wonder if you should make this conditional on mobile.

It's unfortunately not possible to detect that reliably, especially since FF/Chrome offer a "request desktop site" option to mask their identity as desktop versions. The options listed at that link are based on user agent strings (which are uselessly unreliable) and screen sizes (also useless - my phone has a higher resolution than any computer or tablet in the house).

The double-clicking action ... combined with a "random" jump in the scrolling position ...

It scrolls to the top of the next post.

Ah, I see. But shouldn't it scroll to the top of the current post, i.e. the one that was just expanded or collapsed?

Case 1: Collapsed post: you can't be further down than ~40em worth of lines, so there won't be much scrolling back to the top, and context is preserved better.

Case 2: Expanded post: you can be deep down in the post, but ending up at the top again preserves context better, then decide yourself where to scroll next.

Maybe this would work better if posts explicitly collapsed by users were reduced to a smaller height than the initial threshold height of 40em, say for example to ~4-8em, since explicitly collapsed posts have usually been read and are thus no longer interesting, and they should go out of the way of unread posts.

Maybe, maybe, even posts fitting inside the initial threshold height of 40em could have a collapse button to explicitly shrink them to ~4-8em. Like this, diving into a thread and collapsing posts one by one after reading would tidy up even more space for unread posts, while causing only little scrolling.

However, my overall preference would be not to break the web browser's widely conventional default double-/triple-click actions for text, i.e. select word and select line, respectively.

So I would ask for: save exits the editor and displays the saved page ... add a checkbox [ ] keep editing

I won't add such a checkbox defaulted to on, as that would seriously annoy my own usage of the editor. I'll look at adding one defaulted to off, though.

One of the wiki engines I'm using has both "Save" and "Save and continue editing" buttons. Because indeed it would seem more intuitive if the editor went away once the page is saved, and the resulting page were loaded. You know, "wiki wiki" means "quick quick" -- and checkboxes are slow! ;-)

In Windows one has to double-click to open anything, so we could argue that Windows requires confirmation to even open a file.

That's not quite right. Double-clicks are usually a shortcut to hitting ENTER or clicking the OK button, while single-clicks are commonly used to select one or more items, i.e. they have different functionality.

But for many years (since Windows 98?), there's been a global setting to define whether or not single-clicks should act like double-clicks, and this setting is taken into account by most applications.

And, in Windows, you never ever have to double-click a standard button control commonly known for decades by folklore to work with single-clicks.

... File→Save ...

On Windows, you can do everything with the keyboard!

After opening the File→Save menu once, you may realize that usually there's the CTRL+S hotkey to directly invoke the command. And after using Windows for a while, you may realize that even ALT+F,S will do the job (and will work analogously for any menu item). Or, the application may provide a "Save" icon in the toolbar to achieve the same with only one click.

That said, I put up with the fact that /fileedit has a mobile-first design, since nobody might ever use it on desktop systems, where it's easier to work with local check-outs.

However, the wiki editor may in fact be used on desktop systems, where people may prefer to work with the keyboard, and may appreciate the following detail improvements:

• Auto-focus input fields and/or text areas where appropriate.
• Consistent sequential keyboard navigation between form controls.
• Access keys for form controls.
• Direct hotkeys for common / default actions.
• Hotkeys to switch between the in-page tabs ("Preview", etc.).
• ...

Most of the web forms I'm using work like this -- but partly because they're way less complicated than the (somewhat overly?) complex /fileedit and /wikiedit pages. I'm convinced that simplicity can be a good feature.

I know, I know, it's hard work to implement the small usability improvements listed above -- and unfortunately none of the work can be avoided simply by switching to ECMAScript 6 ;-)

Therefore, I wonder if you should make this conditional on mobile.

It's unfortunately not possible to detect that reliably, especially since FF/Chrome offer a "request desktop site" option to mask their identity as desktop versions.

That doesn't look like a problem to me. If a user explicitly disguises their mobile device as a desktop machine, they probably explicitly want to load the desktop version?

... breaks the side-by-side diff scrolling in IE.

That change has been reverted. ... Please report back if it's still broken for you.

Great, thanks for the fix, the synchronized scrolling works, again!

Neither of the AJAX-ified /fileedit nor /wikiedit pages seem to work on Windows ...

I'll need more information than that.

Yes, of course, sorry:

• Windows 10
• Chromium
• Official Fossil preview build (i386)
• fossil ui

Since the XHR for the hamburger menu works fine, I don't believe the problem is related to CSRF countermeasures.

I'm a bit short of time to dive into the issues, right now, but if I manage to find out anything, I'll report back.

Ah, I see. But shouldn't it scroll to the top of the current post, i.e. the one that was just expanded or collapsed?

It could, if that seems more useful. However, we normally collapse a post when we get to the end. That means we're finished reading it. If we scroll up to the top of that post when collapsing then we have to manually scroll to the next post to continue reading. Scrolling to the top of the following post seems like the most generically useful approach, but i'm not against trying other options.

Maybe this would work better if posts explicitly collapsed by users were reduced to a smaller height than the initial threshold height of 40em, say for example to ~4-8em, since explicitly collapsed posts have usually been read and are thus no longer interesting, and they should go out of the way of unread posts.

That's definitely worth a try, and would eliminate the main problem with scrolling to the top of that post when it collapses. i'll try that out and see what happens.

Maybe, maybe, even posts fitting inside the initial threshold height of 40em could have a collapse button to explicitly shrink them to ~4-8em. Like this, diving into a thread and collapsing posts one by one after reading would tidy up even more space for unread posts, while causing only little scrolling.

That's also definitely worth a try.

However, my overall preference would be not to break the web browser's widely conventional default double-/triple-click actions for text, i.e. select word and select line, respectively.

i agree 100%, but if you've scrolled to the middle of a 1000-line paste-bomb post then finding the top/bottom via scrolling is a huge pain in the butt. My initial preference was to use long-press for this, but that interferes with mobile keyboards.

What other mobile-friendly approaches can we use for collapsing from the middle of a post?

One idea is to add a 1em-wide click zone along the right, either "invisible" (same bg color as the post) or very lightly colored. Tapping that would expand/collapse the post. ???

However, the wiki editor may in fact be used on desktop systems, where people may prefer to work with the keyboard, and may appreciate the following detail improvements:

Someone familiar with such accessibility features is more than welcomed to go add them. The tab interface does not currently support such a thing but i will look at what can be done there. Perhaps we can use Ctrl-# to switch to tab #, or similar.

I know, I know, it's hard work to implement the small usability improvements listed above

Patches are welcomed! i have literally zero experience with accessibility-related details, so have no feel for what needs to be/can be improved in that regard beyond the addition of hotkeys. One concern, though, is that hotkeys will interfere with the tabbed interface if the hotkey for a UI element on a non-visible tab is activated. (Tabbed interfaces work by simply hiding all tab elements except for the active one.)

and unfortunately none of the work can be avoided simply by switching to ECMAScript 6 ;-)

Nor will it be made easier by having to support pre-ES6 MSIE ;).

That doesn't look like a problem to me. If a user explicitly disguises their mobile device as a desktop machine, they probably explicitly want to load the desktop version?

Even so, there's no reliable way to detect which browser the client is using, and unreliable approaches to anything cause more work long term by having to continually patch them as new loopholes are found. Sniffing the user agent strings is a lost cause - there are literally thousands of them out in the wild, they can be easily spoofed, and they can change at any time. (That's not just a theory - i was once on a project where management had us try to make use of user agent strings to guide certain steps of a process, and they proved to be far too unreliable.)

Since the XHR for the hamburger menu works fine, I don't believe the problem is related to CSRF countermeasures.

We don't generally check CSRF for GET requests (like the sitemap), but we do for all(?) POST requests (which often, but not always, write to the db).

Chrome sends referral information by default and offers no way of removing it without using a plugin. Presumably Chromium does the same.

I'm a bit short of time to dive into the issues, right now, but if I manage to find out anything, I'll report back.

The first thing to try would be to see if GET requests are working:

• When fileedit starts up it GETs the current list of leaves and the list of files for the first leaf. (TODO (me): pack that data into the page for the initial request, like was recently done for wikiedit.)

• wikiedit's "reload page list" button performs a GET XHR, as does selecting/loading a page.

If GET isn't working then i'm at a complete loss. Those should "just work." POST, however, requires referrer data for CSRF checks to work:

• The preview and diff tabs in both apps use POST.

Look in the dev tools and make sure that the request headers include Referer or HTTP_REFERER. If that header is missing then POST will not work unless we disable CSRF checks, but that seems very unlikely to happen.

If Chromium/Chrome are still failing on your platform, it would be interesting to know whether FF fails in the same way. Most of my own testing is FF, some of it is with either Chrome or Chromium, depending on what machine i'm on, but my browsers are are continually updated by the OS's package manager, so i don't have any older browser versions lying around to test with.

I get interesting results regarding the Windows problem:

With an MSVC debug build (i386), everything works fine, with or without WinDbg attached. With an MSVC release build (i386), the pattern of failures is different from the official Fossil preview version.

I'll summarize my findings, and report back in the next days, but I fear I may not be skilled enough to resolve this ...

Re: Windows problem

• Everything on the /fileedit page works, except for the "commit" action.
• Everything on the /wikiedit page works with my own builds.
• Nothing on the /wikiedit page works with the official preview builds (see below).
• Most of the times, the "commit" XHR results in:
  • Chromium console: net::ERR_EMPTY_RESPONSE (size=0)
  • Chromium network tab (preview response): Failed to load data.
  • Web page status line: DATE/TIME: Exception: Error: HTTP response status 0.
• Sometimes, the "commit" XHR results in:
  • Chromium console: Failed to load resource: the server responded with a status of 400 (Bad Request).
  • Chromium network tab (preview response): Fossil HTML stub page with usual header and footer, containing just the text "out of memory".
  • Web page status line: DATE/TIME: Exception: Error: HTTP response status 400.
• The problem only occurs with the release build, and I can't reproduce it with the debug build.
• For the release build, the test-ci-mini command also fails, without printing any error message.
• As soon as diagnostic code is added to the failing release build, the problem can no longer be reproduced! So I'm sorry I'm out of luck tracking this down.

Steps to reproduce the problems with the official Fossil preview release

Note: my tests are on Windows 10 AMD64 with Chromium.

A. fossil ui → /fileedit → "commit", or fossil test-ci-mini ...

PASS! Fossil 2.12 [19677d7629] / msc-19.00 (64-bit)

FAIL! Fossil 2.12 [19677d7629] / mingw32-3022004L-gcc-5.3.0 (32-bit)

B. fossil ui → /wikiedit

PASS! Fossil 2.12 [19677d7629] / msc-19.00 (64-bit)

• Everything works fine!

FAIL! Fossil 2.12 [19677d7629] / mingw32-3022004L-gcc-5.3.0 (32-bit)

• Any XHR ("load", "preview", "diff", "save", etc.) fails with the web page status line "DATE/TIME: Exception: Error: HTTP response status 404."

Along the way

If either of these three goto branches is taken, a NULL pointer (zNewUuid) will be passed to fossil_free(). (Fixing this does not resolve the problem reported above.)

More on the usability of "Save changes"

In Chromium, the "Save changes" button remains disabled while typing into the textarea, and is only enabled once the input focus has changed, i.e. it's necessary to move the input focus away from the textarea to have the "Save changes" button enabled.

The ideal quicki/wiki workflow is:

• Click "Edit".
• Start typing.
• Click "Save changes".

But instead, we have it slower:

• Click "Edit".
• Click the textarea so is has the input focus.
• Start typing.
• Click the page background, or move the input focus to another enabled control.
• Click "Save changes".

This may be caused by listening to the "onchange" event, which only seems to be fired if the modified control loses the input focus. A better approach may be to listen to another event ("keydown", "keyup", "keypress", "input", ...?) to detect changes earlier, and enable the "Save changes" button. (The event listener could be deactivated after the first event.) This solution would also allow setting an "accesskey" for the "Save changes" button, so that it could be triggered by the keyboard (The "accesskey"s only work for enabled buttons.)

Or, the "Save changes" button could be always enabled, and users could be allowed to save an unmodified page if they want, possibly to "touch" it and have it appear at the top of the timeline? With less "automagical" actions, there's also less potential points of failure.

(All of this is analogous for "Save & Close".)

More on the usability of the "Countdown Confirmation Buttons"

Because the "countdown confirmation message" text is usually much longer than the normal button text, the buttons are resized after the first click.

Depending on the width of the browser window, the page zoom level, etc. the necessary re-layout of the page may cause the insertion of a line break, and have the button jump to the next "line".

This basically means users are required to click the same element twice, but the element can disappear from under their mouse (or fingers)!

I hope you've been convinced now that the "countdown confirmation buttons" should be removed, because any work-arounds to this (disallow the line break → message text may be clipped; set the button to a fixed width enough for the message text → looks ugly) only make this hack worse.

Re: Modern ECMAScript

... and unfortunately none of the work can be avoided simply by switching to ECMAScript 6 ;-)

Nor will it be made easier by having to support pre-ES6 MSIE ;).

Touché! Except, maybe, that I'm able to read and understand pre-ES6 code ... ;-)

Re: access keys

One concern, though, is that hotkeys will interfere with the tabbed interface if the hotkey for a UI element on a non-visible tab is activated. (Tabbed interfaces work by simply hiding all tab elements except for the active one.)

If hidden elements are also disabled, the access keys are muted. However, this may require additional tracking of the "enabled/disabled" state, so that the tab manager knows whether or not to re-enable an element when making it visible.

An alternative may be to move the values of the "accesskey" attributes (if any) to something like custom "data-accesskey-disabled" attributes for hidden elements, from where they can be restored.

Passing a NULL pointer to fossil_free() is a harmless no-op.

... have the button jump to the next "line".

Attempt to illustrate this behavior.

Note: my tests are on Windows 10 AMD64 with Chromium.

i notice that all of the reported failures are on 32-bit builds. i don't have a 32-bit environment to try that on, but will set up a 32-bit VM to test it on Linux. There's no C code difference either way, so this sounds like something compiler- or environment-specific.

In Chromium, the "Save changes" button remains disabled while typing into the textarea, and is only enabled once the input focus has changed, i.e. it's necessary to move the input focus away from the textarea to have the "Save changes" button enabled.

That's by design. Currently we rely completely on the textarea's change event, which is only triggered when focus is lost AND something was modified (but the browser tracks that for us). Monitoring every single button press in the textarea would be very battery-intensive, requiring a callback for every press. We would also have to differentiate between navigation keypresses (pgup/down, arrows, ...) and the rest.

Click "Edit".

Click the textarea so is has the input focus.

Start typing.

Click the page background, or move the input focus to another enabled control.

Click "Save changes".

That's a side effect of relying on the change event, but try this: if you click directly on the disabled button, it will be enabled and the click event will be passed on to it, triggering the save. That wasn't by design, but is a happy accident (at least on Chrome and Firefox). It's a bit non-intuitive, i agree, but it works around that usability quirk. We can't catch that case via a mouseover event on the button because until the textarea fires its change event, we don't know if there are any changes (so we don't know whether to enable the button).

I hope you've been convinced now that the "countdown confirmation buttons" should be removed, because any work-arounds to this (disallow the line break → message text may be clipped;

Until we have an alternative to avoiding potential loss of edits i will not remove them. The save button no longer confirms, by popular demand, but the discard/reload buttons necessarily require confirmation because loss of an arbitrary amount of editing work is simply too easy without it. i'm not averse to making layout-related changes to avoid the UI moving around, but we can't realistically account for every window size/orientation when doing so.

This solution would also allow setting an "accesskey" for the "Save changes" button, so that it could be triggered by the keyboard (The "accesskey"s only work for enabled buttons.)

That could be worked around by tying that access key to some other non-input element (e.g. a zero-width SPAN next to the save button) and triggering the save event through there. That would, however, allow saving even when there are no changes, and i'm not a fan of allowing no-op commits. wikiedit does not currently confirm that saving actually changes anything, but it arguably should (like a checkin or fileedit does). The interface should not make it easy to accidentally make no-op saves, IMO.

set the button to a fixed width enough for the message text → looks ugly)

That's a good idea, but we can't(?) know the size needed for the current skin, unfortunately. Any size we set will be wrong for certain skins/configurations. Maybe (not certain) we can figure that out programmatically at startup by setting a long label and measuring the button's size - i'll take a look at that.

If hidden elements are also disabled, the access keys are muted. However, this may require additional tracking of the "enabled/disabled" state, so that the tab manager knows whether or not to re-enable an element when making it visible.

Disabling elements unfortunately only works on input elements and fieldsets, not arbitrary DOM elements, so we cannot currently disable a whole tab by disabling main tab container element. The tab buttons, for example, are not buttons so they cannot be disabled. (They probably don't need to be, though.) If we globally disable/enable all elements as their tabs are hidden/revealed, there's no simple way of keeping the enable/disable state properly synced when we have a mix of explicitly enabled/disabled elements (e.g. the "local edits" element is disabled until it has contents, and all input elements are disabled whenever there is ajax traffic in transit).

However.... it might be reasonable to replace the main tab body elements with restyled fieldsets for that purpose. i'll try that out, but suspect that it will have a "rat's tail" of side effects because the higher-level code addresses those tab elements directly.

Monitoring every single button press in the textarea would be very battery-intensive ...

So, what about "oninput", and then deactivate it after the first hit?

If you click directly on the disabled button, it will be enabled and the click event will be passed on to it, triggering the save.

Not in my version of Chromium (latest) on Windows, unfortunately ...

And, why would I even try to click on a disabled button? It looks like you're reinventing and/or repurposing every single aspect of the standard UI!

Also, not being able to patch Fossil and simply add accesskey="S" to the "Save changes" button (because it wouldn't work for the disabled button) is a drawback for me.

So, what about "oninput", and then deactivate it after the first hit?

That's a new event for me, but that sounds like a reasonable approach. i'll look at that after i'm done with the fieldset-related change (which does indeed have a rat's tail).

And, why would I even try to click on a disabled button?

i agree that it's silly. i discovered that workaround only by accident.

It looks like you're reinventing and/or repurposing every single aspect of the standard UI!

It's disabled because there are no edits, which makes perfect sense. The app does not get the event that there are edits until the textarea loses focus, which is simply how the "change" event behaves. The "oninput" may resolve that or, possibly even easier, we keep the change event, leave the button always enabled, and then simply show an error if the user tries to save before any changes are made. i.e. we add an "is-dirty" flag which gets set by on-change and re-set when the editor element is (re)populated.

Also, not being able to patch Fossil and simply add accesskey="S" to the "Save changes" button (because it wouldn't work for the disabled button) is a drawback for me.

i'm working on a fix for that now by wrapping the tabs in fieldsets, which should allow us to hinder hotkeys on non-visible tabs (that, in turn, would allow us to use the same hotkeys of different tabs for different purposes, if desired). That requires a rather invasive change to the tab manager, though. Unfortunately, fieldset child element incompatibilities between the major browsers make this more work than it should be. (Firefox handles multiple children in fieldsets just fine but Chrome mis-handles that case badly, and the standard doesn't say anything on the topic so both browsers' behaviours are "correct".)

i'm working on a fix for that now by wrapping the tabs in fieldsets, which should allow us to hinder hotkeys on non-visible tabs (that, in turn, would allow us to use the same hotkeys of different tabs for different purposes, if desired).

That was checkin 33610b04de8fdf56 but it had to be reverted because a subtle and nasty bug in both Chrome and Firefox breaks scrolling of elements which are a descendant, no matter how deeply nested, of a fieldset.

i stumbled across the problem by accident when doing a unified diff in wikiedit and was pulling my hair out for an hour trying unsuccessfully to get horizontal scrolling to work. It turns out it's a known problem in Chrome:

https://stackoverflow.com/questions/31597348/overflow-of-div-inside-fieldset-not-working-in-chrome

And Firefox, curiously, has the exact same bug. The workaround listed at that StackOverflow post works but is fragile (the previous workaround for it worked for a while then suddenly stopped), so i've removed the fieldset wrappers from the tab manager class.

@Richard: this is not critical for the release, so was stuck into a branch for the time being. It doesn't affect anyone until/unless they try to do a unified diff in wikiedit or fileedit on something with really long lines (like a wiki page). SBS diff does not exhibit the problem.

i notice that all of the reported failures are on 32-bit builds. i don't have a 32-bit environment to try that on, but will set up a 32-bit VM to test it on Linux. There's no C code difference either way, so this sounds like something compiler- or environment-specific.

i'm unable to reproduce any of those errors using 32-bit builds of fossil on Linux. Based on your pass/fail report, mingw32 is clearly at fault here, but it's a mystery how/why that build behaves differently than an MSVC build. Are you doing a clean rebuild for each binary? Perhaps mingw is incorrectly using object files built by MSVC, linking the wrong symbols to the wrong functions?

It would interest me to know whether the commit editor (via /info/UUID) or the legacy wiki editor:

https://fossil-scm.org/fossil/info/bf1984428f6eb4c5 (last version with that editor)

works in those builds. They don't use ajax but they use POST to submit their changes. There's no difference, as far as the binary is concerned, whether POST data comes in via ajax or an HTML form, so if ajax POST requests are failing then those should fail as well.

Any XHR ("load", "preview", "diff", "save", etc.) fails with the web page status line "DATE/TIME: Exception: Error: HTTP response status 404."

That error is particularly strange, as those paths are not dependent on the fossil build. Can you post the full URLs those requests are using (for both the pass and fail cases - if they're not identical then something is horribly wrong, and if they are identical but respond differently on mingw then mingw is obviously building a broken binary)?

Re: Windows problem

Are you doing a clean rebuild for each binary? Perhaps mingw is incorrectly using object files built by MSVC, linking the wrong symbols to the wrong functions?

Yes, clean build, but I only have MSVC, that's why I can't create and examine debug versions of the mingw32 builds.

It would interest me to know whether the commit editor (via /info/UUID) or the legacy wiki editor:

They both work fine with the latest official release version downloaded from the Fossil website:

• Fossil 2.11.1 [307d94c549] / mingw32-3022004L-gcc-5.3.0 (32-bit)

And they both work fine for the version you indicated, built with MSVC:

• Fossil 2.12 [bf1984428f] / msc-19.26 (32-bit)

With yesterday's new preview build, the errors on the /wikiedit page no longer appear, but the /fileedit → "commit", or test-ci-mini error persists:

• Fossil 2.12 [98fa23f90b] / mingw32-3022004L-gcc-5.3.0 (32-bit)

The same goes for the current trunk, where I now see an "out of memory" error printed by the test-ci-mini command:

• Fossil 2.12 [e70f2fbc7b] / using msc-19.26 (32-bit)

Re: "Countdown Confirmation Buttons"

... set the button to a fixed width enough for the message text → looks ugly ...

That's a good idea ...

Sigh. At least you didn't set the width to 100% ... Looks like these fancy buttons are your babies, and we can't get rid of them :-(

Re: Wiki editor "Save" button

If the "Save" button is now always enabled, relying on the (formerly) bogus "onchange" event works fine, as the event is fired before the "Save" button can be clicked. And, it also works with access keys (I've just tested it).

But note that this problem is not related to IE, so this comment is wrong! (I wouldn't dare opening /fileedit or /wikiedit with IE, and even less writing about it here ...)

However, by temporarily changing the mimetype, and then setting it back to the initial value, it's still possible to save an unmodified wiki page. So I think all these efforts to prevent empty pages from being saved should simply be dropped, leaving users as much freedom as possible.

All in all, the new wiki editor feels like heavy machinery, like editing a two-line shell script with a full-blown word processor -- except that word processors have keyboard shortcuts.

And, there's still many unnecessary / redundant / lengthy tooltips for buttons that already have text labels to unambiguously indicate their functionality.

The deeper reason for my feelings may be that any text processing that can be achieved in a plain textarea will always be poor, and to seriously work on a text, it has to be copied to a proper text editor, anyway. So any online wiki editor will either just be used for simple spelling corrections, or as a gateway to paste & save text from a text editor. Maybe that's why the new Fossil wiki editor looks somewhat "over-powered" and "over-complicated". The new interface somehow looks like it was intended to be built around a more capable editing component than just a simple textarea, it feels kind of misbalanced. (Note: this is not a feature request!)

My favorite wiki website is: http://lua-users.org/wiki/

Dead simple, fully functional -- a timeless beauty.

The same goes for the current trunk, where I now see an "out of memory" error printed by the test-ci-mini command:

i need to know what inputs you're using, because i'm unable to reproduce that:

$ f test-ci-mini -m 'Testing test-ci-mini.' README.txt 
New version (dry run): 6fe4ce35615d5875c2c04f8beb736571bd1bbdcc
$ f test-ci-mini -m 'Testing test-ci-mini.' README.txt --wet-run
New version: 832efcfb15da1beca24023065ad97fae64de148d
The checkout state is now out of sync with regards to this commit. It needs to be 'update'd or 'close'd and re-'open'ed.

My assumption is that your fileedit commit error and this one have the same cause. i seriously doubt this is the problem, but please try removing these 3 lines:

https://fossil-scm.org/fossil/file?udc=1&ln=369-372&ci=e7c348f1d9d37315&name=src%2Ffileedit.c

and see if you still get the out of memory error? (i don't expect a difference, but that's the only part i can think of which does any "unusual" memory allocation compared to the rest of fossil.)

Looks like these fancy buttons are your babies, and we can't get rid of them :-(

Not until someone implements a better method of confirmation which does not use window.confirm(). Once we have that, i will be happy to switch to it. Confirmation, using a 100% predictable approach (which window.confirm() is demonstrably not), is an absolute must when it comes to cases which can result in loss of data/edits. No method of confirmation is going to please all users. A dialog is, IMO, less useful and more intrusive than the current approach, but i would use it if we had it simply because it's more conventional (so it's less likely to invoke the overwhelmingly negative reactions that this one has).

But note that this problem is not related to IE, so this comment is wrong!

Yes, that comment has a typo ;). Perhaps it's a Windows-related problem, not MSIE-specific. The behaviour i described before - clicking on the disabled button - works in Chromium and Firefox on my platform. We no longer rely on that behaviour, though.

However, by temporarily changing the mimetype, and then setting it back to the initial value, it's still possible to save an unmodified wiki page.

The only way to work around that is to hold the whole contents (or a hash of it) of all being-edited pages/files in memory and compare the contents and mimetype to the originals (or hashes) for every single change event. The only feature that would give us which we don't already have is the ability to detect when a change was made and later edits undo that change, and that CPU/battery cost is completely disproportionate to benefit of that feature for this context.

All in all, the new wiki editor feels like heavy machinery, like editing a two-line shell script with a full-blown word processor

For anyone who does any significant amount of wiki editing, the new editor is a tremendous time-/sanity-saver. For example, you do not lose your editing place or textarea Ctrl-Z history every time you run a preview. Its ability to avoid any loss of edits when switching pages, closing the browser, or a loss of network, is also tremendously useful. New functionality has new costs. That's unavoidable.

-- except that word processors have keyboard shortcuts.

If you want to add access keys to all relevant controls, please feel free to. That's not how i use it, so i have no personal incentive to do so, nor can i predict how other people might want to use it with access keys.

i still need to experiment with tying access keys to switch tabs - that's on my TODO list.

Edit: Mozilla recommends against using access keys due to several portability problems:

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey#Accessibility_concerns

And, there's still many unnecessary / redundant / lengthy tooltips for buttons that already have text labels to unambiguously indicate their functionality.

We can have wordy/descriptive/unambiguous buttons or we can have brief buttons and wordy/descriptive/unambiguous tooltips. If buttons are not 95%+ descriptive of what they do, a tooltip is the conventional way to deal with that.

If you will implement a "bubble help" API, where we have a little "?" the user can click on (or if i eventually get around to doing so), i will gladly switch to that. i dislike using the title-attribute tooltips, but dislike unclear or over-wordy buttons even more. Tooltips are the lesser of two evils.

So any online wiki editor will either just be used for simple spelling corrections, or as a gateway to paste & save text from a text editor.

Indeed, that was necessary with the older editor because undo history and editing cursor got lost on each preview, but it is less so with the new one.

The new interface somehow looks like it was intended to be built around a more capable editing component than just a simple textarea, it feels kind of misbalanced.

The wikiedit/fileedit APIs both support the client plugging in their own editor widget via skin-side additions, but we do not/will not provide one.

Dead simple, fully functional -- a timeless beauty.

It also has the same drawbacks as fossil's legacy wiki editor, like loss of editor cursor and client-local textarea undo. Its preview functionality is also fundamentally wrong: it requires the user to tap the "back" button to go back to editing. Whether or not "back" restores edited form data is browser- and browser-version specific. That is not a standardized HTML feature and cannot be relied upon without using JS's localStorage or sessionStorage to stash/restore any edits.

Warren coined the phrase "do-ocracry," and this particular wiki editor is what someone "did." Like most software, its functionality is based on how that person works and what that person wants from it. Also like most software, its functionality will not please all users, and that's an unavoidable part of the process.

If you prefer the legacy editor and are willing to maintain it and can get Richard's blessing to allow a configuration option or preference cookie to specify which editor is used, then feel free to do so. Personally, i feel that would be taking 3 steps back towards the 1990s, but we all have different preferences.

Feedback for improvement is always welcomed - several of your suggestions have been implemented - but the final decision about how any piece of software works is always made by the ones who end up writing the code :). (Even in organizations where marketing and management ostensibly decides that, it's the ones writing the code who actually implement it.)

i still need to experiment with tying access keys to switch tabs - that's on my TODO list.

The trunk version experimentally adds accesskey values to the tab buttons, using a key equal to the 1-based tab number. However:

• Mozilla recommends against using accesskey because of several portability and usability problems.
• The key combination required to activate them is determined by the browser and its OS. The combination for Chrome and Firefox on Linux (Alt-Shift-#) is literally painful to activate for my fingers.

i don't consider this to be a useful improvement except on MSIE, Edge, and Opera 15+ (non-Mac only), where Alt-# supposedly works (in FF/Chrome that switches the browser's tab).

However, after successfully writing the new commit, the latter now displays the following status message:

DATE/TIME: Exception: SyntaxError: Unexpected token { in JSON at position 5

Silly me -- this error was caused by my (non-JSON) diagnostic output!

Sorry for the noise, all fine from me, now!

That indeed seems to fix the problem, for both test-ci-mini and /fileedit → "commit"! Congratulations!

That's unexpected but fixable. Hmm. i suspect that's a compiler bug, as other 32-bit builds don't do this, but i've no way to prove that so will simply remove the reserve() call - that'll be in the trunk shortly. (It's just a micro-optimization, anyway, not a necessity.)

DATE/TIME: Exception: SyntaxError: Unexpected token { in JSON at position 5

(Not sure when to find the time to look into that one, at the moment, as I don't find my way around in your new Javascript libraries, yet.)

That's being triggered indirectly from something invalid the server is sending back. Can you fish out the response from the server (it's in the browser's dev tools)? Nevermind - i now see your follow-up post which resolves that :).

It's true that the textarea retains the scrolling position when going to "Preview" and back to "Editor", but because the textarea does not automatically receive the input focus, I still have to make another click to where I think the caret position might be to activate the textarea.

That's a fair point. If it were possible to give it focus via keyboard then using the keyboard would return focus where you left it. In the legacy implementation, we lost all context, so if we were scrolled down 200 lines into the wiki when running a preview then we had to scroll down again and find our place after returning from preview, where the new implementation at least keeps the same section of the doc on the screen. When editing is difficult or tedious, it often doesn't happen :/.

Feel free to add an accesskey to that element if you like - that should allow you to bypass the "lost cursor". Maybe "w" for "wiki" or "t" for "text/textarea" or "e" for "editor".

I think users don't need the tooltips any more after the first or second use, and there's still the "Help" tab. If you only do short test runs on desktop systems, the tooltips may not bug you too much, and when you're on your touch device, they are silent -- maybe this is why you don't think they're too much?

i consciously never leave my mouse hovering over an input element - it's a bad habit which can lead to accidental activation when my hand hits the mouse again or the mouse gets nudged towards the keyboard and the keyboard presses the left mouse button (that happens to me every now and then).

Neither my knowledge of ES6 nor of your extensive Javascript libraries are sufficient for this, at the moment, I'm sorry.

And my CSS is too weak to get it working well on both desktop and mobile :/. i looked at a few tutorials for implementing modal dialogs but was not confident that i could get it working reliably on mobile screens before the 2.12 release, so moved that down the TODO list.

Of course, please feel free to ignore my comments! But, you do submit a lot of "RFC" posts to the forum. I don't always find the time to reply quickly, but I see this as a call to invest my time to carefully explore the new features, and summarize my feedback. All the topics in this thread are replies to your RFCs, albeit belatedly, at least some of them.

And your feedback is always appreciated, especially because it most often differs drastically from my own opinions(!), forcing me to see it from a different angle. i'm not complaining about your feedback, i'm just pointing out that, regardless of feedback, the final implementation decision lies with whoever is writing the code.

It also has the same drawbacks as fossil's legacy wiki editor, like loss of editor cursor and client-local textarea undo. Its preview functionality is also fundamentally wrong: it requires the user to tap the "back" button to go back to editing.

I really wish there was the equivalent of a target="_blank" for buttons. That would handle so many issues like this.

There is a formtarget that I think could be used, but you steal control from the user who can choose: open in a new tab/window as an option on links.

The latest trunk "should" address most of your points, other than the inexplicable errors on the 32-bit Windows builds (that could be anything - are we sure that even the legacy wiki editor or the checkin editor works in those builds?).

Summary:

• wikiedit/fileedit buttons which require a confirmation now calculate their highest width and pin their min/max width to that value. This avoids re-flowing of the layout during confirmation but leads to some buttons looking like they're "unusually wide" until they're clicked and the longer text appears. (Edit: for reasons unknown, this doesn't work in the Bootstrap skin, but works in all others.)
• The wikiedit Save button is now always enabled, but tapping it when there are no edits (no "change" event has fired) results in an error message (something like "There are no changes to save"). It tries to avoid allowing the user to perform a no-op save. Doh... i just realized that a change of mimetype, without content change, is not currently recognized there - i'll fix that in a few minutes.
• The wikiedit Save button is no longer relabeled to "Saving..." while a save is in progress because doing so causes the layout to reflow. The status bar shows a saving message, but it's normally too fast to even notice. (All input elements are disabled while ajax requests are in transit, to avoid various race conditions, but that's not a new feature.)
• The tabbed interface API now wraps all tabs in a FIELDSET element and enables only the currently visible one. All others get disabled, with the hope being that triggering hotkeys tied to elements on other tabs will not trigger. This change is invisible to the user - only inspection with the DOM inspector will reveal it. This level of enable/disable does not interfere with our explicit enabling/disabling of other elements, so no extra tracking of that state is needed.

A couple of your forum post expansion ideas are now in a branch:

https://fossil-scm.org/fossil/timeline?r=forum-expand-post-revisited

The changes are:

• When collapsing an expanded post, it is now shrunken to 8em tall and we now scroll that post's header bar into view, rather than scrolling to the next post. That seems to be slightly less confusing than the previous behaviour and also, because of the new shrinking, eliminates the problem of having to scroll far down to the next post. (Anything smaller than about 8em seemed far too small to me.)
• For expandable posts, there is now a narrow (1.25em) tappable zone to the right of the scrollbar. Tapping there will expand/collapse the post. That zone is colored mid-gray and made 30% opaque, so it "should" appear in any skin which has a non-grey background without being too obnoxious.
• Double-click to expand/collapse has been deactivated.

Is this an improvement? Feature or bug?

The proposal to make all posts collapsible would require a larger reworking, so i left that out for now, but we can definitely explore that later.

Sidebar: when first implementing this feature i tries to use CSS animations to animate the size change, but the effect was drastically different depending on how long the post was. Very long posts lead to really weird/jarring animations, so the animations were not checked in.

@Richard: thank you for updating the binary, but it was too quick: i had broken the forumPostBody CSS by accidentally removing an attribute. That's now fixed in the tip. (Edit: resolved - thank you!)

Seems to be working better now. Note that it is important to try out this new feature both on a phone and on a desktop. In particular, there seems to be some issues remaining with grayed-out posts that appear in chronological display which is the default on narrow screens.

If it's the same problem i'm currently seeing it's triggered by plain-text posts, as those have a PRE instead of a DIV, which the new CSS selectors didn't account for. They greyed-out appearance is actually the tap-zones style being incorrectly applied to the post. Working on a solution now.

That problem is now resolved (CSS selectors fixed). We might want to dial the opacity back from 30% to 20%, but that's a minor cosmetic detail. The goals of that particular style are (A) to remain skin-agnostic, in that it should "just work" in most skins, regardless of their color (barring light grey backgrounds, where it will be effectively hidden), (B) to be visible without being obnoxious, and (C) to be large enough to tap but not so large as to be annoying.

https://fossil-scm.org/fossil/timeline?r=forum-expand-post-revisited

If we're happier with this than the current trunk forum-expand feature, i'd like to merge that now. It can still use improvement, e.g. possibly making all non-trivial posts collapsible, like Florian suggested, but IMO it behaves better/more intuitively than before.

Unfortunately, my attempts at animating the collapse/expansion using CSS animation have had very mixed results. The main problem is that for exceedingly long posts the animation takes place mostly off-screen, while the on-screen part appears to do nothing at all, leading to what appears to be a pause/frozen page and then a large jump as the post finally collapses. We could probably get better results doing JS-side animations, but that's left as an exercise for a rainy day (or someone who knows off-hand how to do it).

This is not a request for the new features to support old browsers, but this check-in breaks the side-by-side diff scrolling in IE.

That change has been reverted. The "problem" is that MSIE<=11 do not support NodeList.forEach.

Please report back if it's still broken for you.