Just putting this out there, in case anybody else has noted this. If I can cross-correlate with some other sufferer's experience I can maybe either accept it or go further in reporting it to the developer(s) concerned.
Warning: Long and dense. You could just skip past it, as it's not a response to anyone else's problem. 
Setup is...
Browser: Firefox for Android (does not happen on Chrome, ditto)
On-screen keyboard: Default Gboard, with long-standing visual/etc changes that predate this issue (since then, have done limited testing with other on-screen keyboards, but they behave differently in everyday use so not stuck with long)
Sites: Various places with textbox input, but notably Bay12Fourms under SMF because it's by far the biggest usage case.
Since the Firefox update this sumner that junked the page-tabs (horrible design decision, it also forced Android's native header and footer 'bars' to always be on, so the screen-space it saved got more than used up again for net loss) I've been having recurring niggles that I'm inclined to believe is a Firefox issue (not keyboard or SMF's javascript handlers, for example).
Typing away, as I am now, I
might get a recurring word/string of characters in some buffer or other. Typically, it seems to have been something I typed then backspaced back to the prior spacebar (easier than repositioning the cursor on a touchscreen, when I want to insert a word so recently, or head up a different direction of sentence). From then on, until some arbitrary point up to the posting of a message being so typed (occasionally before that, during actual cursor-moving editing, but not always) whenever I re-spacebar while at the 'end' of the text I'm typing, that mysteriously buffered string gets appended. Each. Time. After the cursor (you can edit the 'paste' out) so that if it struck after "The quick brown fox jump over" is edited to "The quick brown fox jumps over" the final (uncorrected) text would be something like "The quick brown fox jumps over the lazy dog. overoverover" by the time the "." and the next space is typed.
These days, I tend to linefeed the 'spare' repeated text away down a line or two, so the cursor can be placed not at the very end of the regular text (which the repeated rebuffered word does not count for, so I suspect it's an issue involving the effective cursor position moving back upon a deletion event, but the memory-structure holding the usually expanding text-string has a misaligned pointer position. Having done so, I can do a final edit to remove the 'overflow', although I have at times posted text forgetting to do this, leaving (something like) "overoveroverover" as a final nonsensical line, until I realised and re-edited it out (sometimes quick enough to have SMF not even mark as an edited post).
I was prompted to post this when I had a sightly different variant that has some of the same effects but
not quite. I wished to italicise a word in a post, so highlit the last word typed in and went up to the "
I" button[1], to markup with the [i
][/i] surrounds. But accidentally (bounced my finger?) activated the URL-tag button too, for a nested tagging I didn't want. Not sure which way I edited it down again (instinctively), but I did. But then whatever I typed onward (appended after the closing [/i]) would immediately relocaten (dragging the text cursor position back) to just before the end-italics tag after each new space. I tried several things to unmunge it[2], but the first that worked was to Preview the post and continue the editing in the new (prepopulated) instance of the textbox now visited.
So whatever the memory-mangle involved, that aspect got chucked while refreshing to the new page (site back-end code or browser page-session data applying) rather than linked somehow to the exact string of lead-up text activating some form of auto-correct aspect, when I don't have much more than "after a ./?/! and space, default back to upper for the next character"[3] active.
It is, of course, a bit of a Heisenbug. I can't command it to happen. Sometimes I manage to
un-happen it, before finishing with the exiting, without even my identified getaround (put some other whitespace in there, then edit at a position prior to that whitespace), though the rare de-happening occasionally then
re-happens later in the current missive. Either with the original recurring string (popping back up, without any re-use, so 'remembered') or a new one (a novel string drawn from what was typed just before it 're'happened, which might just be a new and independent bug-bit flipping, or whatever prompts it).
So, anyway... I doubt that too many others get this form of electronic-Tourettes. For one thing, I blame the updated Firefox for Android (in the early days of this incarnation I scanned their bug-report pages, but there were
so many bugs/niggles/requests/suggestions/complaints upon the major version change that it was impossible to identify anything that related to this, and I never got round to signing on myself to place a competent set of bug-reports of my own) even after several further bugfix/operability updates, but I imagine that this isn't a setup (or platform) relevent to almost all those who would read this. If it was SMF's internal javascript handling that somehow changed last summer (though the sitecode surely has not, for much much longer!) I'd expect many would have mentioned it without me needing to ramble on about it like this...
But putting it here, in sight of various (other?) clever people, just in case it rings bells for anyone. If it doesn't now, maybe it'll do so at a later date. Until 'sorted" I shall continue to deal with it, of course. Or eventually stop using this particular setup altogether.
[1] Gboard doesn't have the slash key on the 'front' keyboard I use, except when editing something like an address. In cases like this I'd have to switch to the (primary) punctuation keyboard, even though I've got all kinds of other common punctuation (including square, curly and regular brackets, the pipe symbol and even the
backslash as easy long-press characters available, as configured. Very strange that it gives the backslash but not the foward one. That's not an issue I'm bothered about, but I still find it remarkable, hence this remark about it.
[2] Including inserting new bare open/close-italics tags within the old 'filled' open/close then editing out the new (second) opener and old (second) closer, thinking that might de-confuse whatever character-handler was being confused, during edit. It didn't, which reinforces my "*something something something* memory text array pointer" idea, as the 'false' ending will be incremented and decremented normally to keep it just as 'wrong'.
[3] Of course, the "a" in "and" in that sentence had to be forced back to lower. As does anything where other punctuation only (like these parenthises!) Feature in and so made that 'f' uppercase, that I didn't force lower. Again, a quirk of (at least) Gboard, but at least one that
always happens.
Author
Topic: The Generic Computer Advice Thread (Read 494264 times)