Yep; known issue. It's because iOS declares that Shift is being held in this mode, which the editor interprets as you suggest. We need someone irritated enough by this to fix it. I use iOS, but I rarely use the /*edit pages with it, so I merely growl a bit each time it bites me, but I don't go in and fix it.

I might be irritated enough 😅. I'll take a look tomorrow.

This seemed to work for me in my admittedly brief testing. Folks with iPad+keyboard might not like it, though. We could take the check down to iPhone/iPod, perhaps.

From 70cae0a9

--- src/fossil.page.wikiedit.js
+++ src/fossil.page.wikiedit.js
@@ -914,11 +914,13 @@
     );
     ////////////////////////////////////////////////////////////
     // Trigger preview on Ctrl-Enter. This only works on the built-in
     // editor widget, not a client-provided one.
     P.e.taEditor.addEventListener('keydown',function(ev){
-      if(ev.shiftKey && 13 === ev.keyCode){
+      const isIOS = /iPad|iPhone|iPod/.test(navigator.userAgent);
+
+      if(ev.shiftKey && 13 === ev.keyCode && !isIOS){
         ev.preventDefault();
         ev.stopPropagation();
         P.e.taEditor.blur(/*force change event, if needed*/);
         P.tabs.switchToTab(P.e.tabs.preview);
         if(!P.e.cbAutoPreview.checked){/* If NOT in auto-preview mode, trigger an update. */

const isIOS = /iPad|iPhone|iPod/.test(navigator.userAgent);

FWIW...

We've made every effort to avoid any and all browser-specific quirk checks in any of the JS code and it would pain me greatly to see so much as a single exception added because it's a slippery slope with no end in sight and gives me vivid flashbacks of late-90s/early-2000's JS (where every 3rd block of code had to check for Netscape vs. MSIE... shudder).

If there's a way to reformulate that check so that it does a feature check, rather than a string-based user agent check (which are notoriously fragile), i'd grumble a whole lot less about it.

I guess we need to use the autocapitalize=off attribute ?

I guess we need to use the autocapitalize=off attribute ?

That sounds like it would do the job. It would penalize Chrome/FF users (e.g. me ;), forcing them to manually capitalize as needed, but it would make the behavior consistent across browsers.

@Jim are you able to try out this patch?

Index: src/wiki.c
==================================================================
--- src/wiki.c
+++ src/wiki.c
@@ -1375,11 +1375,11 @@
        "</div>");
 
     CX("</div>");
     CX("<div class='flex-container flex-column stretch'>");
     CX("<textarea name='content' id='wikiedit-content-editor' "
-       "class='wikiedit' rows='25'>");
+       "class='wikiedit' rows='25' autocapitalize='off'>");
     CX("</textarea>");
     CX("</div>"/*textarea wrapper*/);
     CX("</div>"/*#tab-file-content*/);
   }
   /****** Preview tab ******/

It would penalize Chrome/FF users (e.g. me ;), forcing them to manually capitalize as needed

It penalizes iOS, too! I tested it out. And while it does fix the tab-switching issue, the result doesn’t feel good. I constantly have to correct capitalization since this is the only text/prose area on my phone with different behavior. This IMO would be a net negative.

Here are my thoughts on options in my preferred order:

1. Pick a new hotkey. This fixes what I feel is the root cause: the selected key combo doesn’t work well across platforms. While it would be a change for everyone, it would be relatively minor to relearn, and I think folks would understand the justification. (Maybe ctrl-shift-enter, or cmd-enter?)
2. Mobile detection. I also don’t love this, though we can perhaps do it better. For example, MDN suggests detecting touchscreen, or if using user-agent is a must then just search for Mobi. Code littering aspects aside, the robustness of browser detection isn’t bad in this case. If we fail to identify a mobile device correctly, then the behavior is simply what it is today.
3. Do Nothing.
4. Turn off autocapitalization. As I mentioned, this is the one I feel strongly about since it would introduce unexpected and inconvenient behavior for everyone.

BTW, I was very pleasantly surprised at how quick and simple it was to build Fossil! While this conversation takes place, I can quite easily run a fork :)

Pick a new hotkey. ... (Maybe ctrl-shift-enter, or cmd-enter?)

Finding ctrl- and alt-key combos which work portably has proven challenging. e.g. every Linux window manager has its own set of ctr-/alt-based combos which trump app-level combos and they've proven to be unreliable for (re)use in browsers.

How about: rather than try to account for this one keyboard¹, we instead add a checkbox to the editor which allows the user to explicitly opt in to shift-enter=preview, defaulting to the current behavior? We can store than in preference in localStorage so that it's persistent for a given browser/site.

Mobile detection.

Any sort of client-specific detection is a slippery slope with no end in sight. Feature detection is fine, but trying to figure out "is this client X" or "is this mobile" is fundamentally fragile.

Do Nothing.

That's my preference :), but i'll admit to having an especially low tolerance for platforms which behave differently just to behave differently. Granted, its behavior is not wrong, per se, and makes sense on some level, but it is different from all other combinations of browser and keyboard reported so far, making it the odd one out.

Turn off autocapitalization.

i agree 100% that that's annoying and best avoided.

i will work on the above-proposed checkbox approach but it might not be done until tomorrow.

---

1. ^{^} Noting that i assume that the software keyboard, rather than the browser, is the real culprit.

I half wrote a settings suggestion but decided against it since it seems like while I prefer lots of settings, I'm maybe in the minority. But I'd happily test it if you're game for that approach. I've now cloned (not just zip-snapshotted) the repo, so if/when there is a test branch, just let me know.

Jim

But I'd happily test it if you're game for that approach. I've now cloned (not just zip-snapshotted) the repo, so if/when there is a test branch, just let me know.

@Jim,

A new checkbox is now in the shift-enter-preview branch. It appears along the top of the editor tab, is persistent (via localStorage or sessionStorage, whichever is available), and is shared by both /wikiedit and /fileedit.

If you would please try that out and opine as to whether or not this is a horrible way to work around this, it would be appreciated.

@Mark,

Re. this also happening in /chat: it's funny you say that because i was asking myself an hour ago, "why hasn't this ever come up in the context of /chat?" as that app is most definitely used more frequently than /wikiedit or /fileedit and is known to be used on iDevices. To the best of my recollection, nobody's pointed that particular quirk out to me before (or my goldfish-like memory managed to completely suppress it, which is also a possibility). /chat has a more refined config option mini-framework than both /wikiedit and /fileedit, and it would be no hassle at all to add that flag there.

Edit: re.

... and it would be no hassle at all to add that flag there.

i spoke too soon. That particular preview mode is considerably more intricate and works differently depending on several factors, so this one will require a closer look after some sleep.

Edit: no, it wasn't that bad. /chat now has the same toggle, using the same persistent key as /wikiedit and /fileedit.

If you would please try that out and opine as to whether or not this is a horrible way to work around this, it would be appreciated.

It seems to work OK, and I'm fine with another setting. If we land on a brilliant alternative later, then said setting can always go away.

Note that I mainly tried the Wiki. I've never used Chat until now. It looks to work there, too, though I noticed that somewhat odd behavior of it taking two Enter presses to drop down one line. (First press takes the keyboard out of caps mode, the second one drops down a line, and this pattern continues.)

Verdict: 🚢 🇮🇹

It looks to work there, too, though I noticed that somewhat odd behavior of it taking two Enter presses to drop down one line. (First press takes the keyboard out of caps mode, the second one drops down a line, and this pattern continues.)

Weird. That might be related to the "contenteditable" setting - several browsers have a quirk or two when that's enabled.

In practice, multi-line editing seems to be pretty rare in /chat from mobile devices. It's definitely used a lot in desktop browsers.

Verdict: 🚢 🇮🇹

A wonderful "aha" moment as i asked myself, "what does Italy have to do with... Aha!"

Verdict: 🚢 🇮🇹

If that's the general consensus then i'll get that merged in the coming days. If there are objections, please voice them.

we instead add a checkbox to the editor

Each mode checkbox you add takes a multi-platform testing problem and doubles the number of combinations you now must test.

Turn off autocapitalization…annoying and best avoided.

I don't think it's a terrible solution, but I'll willingly rank it second or third behind others.

i assume that the software keyboard, rather than the browser, is the real culprit.

I tested it three separate ways, and you're right. With a USB keyboard hard-wired in, Enter-Enter doesn't toggle you into Preview mode from /wikiedit. When I put that same keyboard into Bluetooth mode, it behaved the same way when talking to the iPad. Finally, I reattached the keyboard to my desktop Mac and retested with macOS's Universal Control feature, which lets me treat the iPad as a secondary display for the Mac, such that moving the pointer to it also moves the keyboard focus; that also let me hit Enter-Enter without toggling into Preview mode.

Now, that having been resolved, let us not fall into a "It's just this one oddball software keyboard" characterization. If you count all of Android as one unified platform (ha-ha) iOS's on-screen keyboard has to count as the second most popular, worth addressing as a key development target on its ~2 billion user base size alone. If instead you count each Android platform that ships the AOSP keyboard as stock as one target platform, then each of the Android flavors that ship something else as the default keyboard, then I'd expect the iOS default to count as the single most popular mobile keyboard on the planet, there being only one source of that default.

i assume that the software keyboard, rather than the browser, is the real culprit.

I tested it three separate ways, and you're right.

Which leaves me even less inclined to want to work around it ;).

Now, that having been resolved, let us not fall into a "It's just this one oddball software keyboard" characterization.

In terms of worldwide clients, very possibly not, but in terms of users using it for /wikiedit and /fileedit, it's demonstrably the oddball :). In my occasional use of /wikiedit on Android (with Microsoft's SwiftKey software keyboard, of all things), it's always behaved intuitively.

Sidebar: the iOS keyboard behavior does make some degree of sense, but considering that it's the only (known) keyboard which behaves that way, and that doing so misinteracts with heuristics such as "is the shift key pressed?" it arguably qualifies more as a bug than a feature.

In any case, i'll throw a "shift-enter to preview" toggle in there, defaulting to "on," as a workaround and we can see if that's sensible (if not, we just close that branch).

I agree with all takes in a sense.

I seldom use fossil on my iP{ad,hone} except for /chat where I've been bitten by
the unintended preview launch enough times that I instinctively hit the caps
button after hitting return if I plan on adding another new line. So in that
sense it is no longer a pain point for me.

I don't think user agents or mobile detection is the right workaround, but I
also don't think disabling autocapitalisation is the right answer either.

I agree with Jim Kalafut that searching the keyspace for a viable alternative
would be my preferred solution, but IIRC, Stephan has already done this more
than once during /chat development as that gets quite complicated when, as
he already noted, you consider the keymaps already used by window managers and
browser hotkeys. Still, if you could come up with a viable alternative, that
would get my vote.

OTOH, Stephan's proposed solution to add another knob definitely solves the
immediate problem, and he's coding the fix so that always wins.

I know Stephan is not exactly an Apple fan, and while I agree with Warren that
the iPhone keyboard is most likely the most widely used given his breakdown,
I think Stephan may be right insofar as it being among a smaller subset of
fossilers. That said, I still think it makes sense to consider its quirks
where reasonable as it will always have a dominant market share, so the odds
that new fossilers are using an iPhone are pretty good.