Firstly, I was inexplicably hit last night (with no apparent Android updates) with what seems to be a a widespread issue of the
WebView component of some apps causing crash-outs, and as it took a while to find out
why, I thought I'd post this info. (Horrible website, as it tries to work on my Android browser, but the content when get past the Cookie popover stuff summarises nicer than other places I checked.)
Oddly, it does
not appear to stop my Chrome browser, as advertised (and Firefox is OK) but it has rendered most of the entertainments on here (a couple of Idle-type games, Hill Climb Racing, etc) unusable. I imagine others may still be stumped, though, so in case they're currently reading this... Here you are.
And now a long bit with an apology at the end, on a¿n unrelated? problem that I also want to get off my chest...On Android issues, though, I'm also getting today a
lot of editing problems in places such as this here Post Reply textbox. Does not generally seem to be restricted to Firefox (though so far today I haven't had it happen in Chrome yet), nor this site (I can't find page-script reasons for it going wrong, either) and I've only ever encountered it on Android platforms, infrequently, but today it seems that every other textbox editing seems subject to it. I'm mostly blaming it on the interface with the on-screen keyboard (I've changed it in the past, but not conclusively ruled out ot happens on others... and it takes so long to get used to a subtly different implementation as well).
The most common (prior) symptom hasn't happened today, but seems related to some internal buffer-pointer value going wrong. If editing away, appending further characters, I decide to backspace a few characters (error or changed mind) very occasionally those few characters - or something similar - seem to be 'remembered' and then after every space I type as I continue this 'strange buffer' (it's not the paste-buffer) is
appended to the stream of text, post-cursor. It can be deleted or not, it matters neither way, but further examples are further postpended to the cursor position whilst I'm still (nominally) tapping in to the end of my regular text. Thus if "end" is the rogue text I might end up with "A sentence with rogue text at the.|endendendendend" with "|" being the cursor position. Moving the edit-cursor away from the (intended, non-rogue) end-of-text position negates this, so one solution is to forget the last (proper) word, for now, insert it anew in front of itself and continue, then delete out the old last word and whatever "endendend"s I'd left for the duration. Another 'solution', available in this forum, is to Preview (reloads the page) which resets the behaviour to forget the 'autoappending strange-buffer', and might convince me it's a forum-code error if it weren't happening elsewhere (and never happening under Windows). In this instance I can also avoid it by
never backspacing, at least not from the end-of-text position, but editing just the bit I would have backspaced to, despite being sometimes more fiddly.
It smells of an error in the cursor-position offset vs text-memory, a clash of secondary storage with buffer underflow/overflow mismatching that
something is trying to reconcile by taking the 'missing' text from the buffer/character-array that did not remember the backspacing and concatenating to the character-array currently being used in the visible textbox. But only when a spacebar (perhaps certain other non-letter characters, maybe LF too?) is tapped, which
implies it is closely tied to some embedded subsystem that like to recognise word-boundaries, such as a spill-chucker, or maybe Google's thing that spies on what I type to 'facilitate' future ad/search results.
The other related fault, which is actually the only one experienced today, but at a significantly greater rate than before, is interaction with the markup buttons (
B I U S, etc, above)... in fact it happened on both B and I examples just there, and I switched to keyboard markup to do U and S (annoyingly, backslash is a long-press, but forward-slash needs a keyboard-change to reach!) rather than havs to Preview the error away. Operationally, if I have selected text and click the Italics or other tag, it encloses the selected text with said tag. Without selected text it surrounds the cursor. And both ways should allow normal edjting beyond the tagged area (on moving the cursor, as required).
Not today, though (or
rarely, but still annoyingly, in the past). Highlight a pre-typed word-or-words and tag, make sure the cursor is beyond the tags, continue typing and... tagged elements vanish (as if under a Selection at the time). Start a blank tag, type within, send cursor to beyond the tag (end-of-text) and type, the cursor flashes to back within the tags and you're still italicising/whatever the new text. As well as using Preview-resetting, sometimes it seems possible to move the cursor position to pre-tag, do something there (random character, then backspace it away), move the cursor to end-of-text and continue as intended, but it may have more subtleties to it as it still does not always seem to work.
In fact, because it is happening
every time I use the tag-buttons, right now, I also had it where the random-char was being inserted into the end of the tag (as was backspace, if I tried the "backspace + retypechar" variant) and nothing
but the Preview-reload method nullified the strange cursor-tying phenomenon. Which, again, seems likely to be something to do with conflicting ideas of text-pointer positions in various character-arrays involved. Though hard to test in Chrome as I don't have an equivalent place with tag-insertion buttons on any site I visit in that browser, and it's this feature that seems most relevent here.
I have an idea that speed of 'typing' might be the issue. For corrective backspacing away the end-of-text I may multi-hammer the backspace 'key' (of the on-screen keyboard) fast enough to cause some event.message or other to be lost between subsystems that are 'keeping count'. The tag-buttons
immediately insert seven, nine, etc, characters into the (apparent) text (edit: and Horizontal Rule puts in four, leaving + /forcing/ the cursor at the very next position) and - again - this could conceivably overwhelm some message-passing, though I don't know why it is a 100% issue this morning compared to ultra-rare before last night. (In looking to investigate the page-top problem of my Idle-clicker 'fun' being aborted, I had totally restarted the tablet, so its not obviously because it needs a restart to freshen up the active memory, something I may do very occasionally otherwise, and I'm more likely to restart due to very low battery.)
Addendum: I just discovered that doing a blank-tag (the bold 'separator' now inserted between the WebView info and these later issues), typing its contents and then trying to re-edit the contents *also* sends cursor to just within the end of that tag again. Again, solved by Preview, but I'd obviously not tried that variation of editing. Annoying. I may even start to revert to /italic/, *bold* and _underline_ conventions more in the foreseeable future, where I think it won't confuse people!
Not sure, if you're even still reading, I'm hoping for a solution to this 'problem' of mine. I know I've been unable to Google-Fu any reasons (or confirmation of my suspicions) posted anywhere, in the past. Apparently nobody else has documented anything similar, that I can find. So I thought that maybe *I* should, however an obscure locale this may be to general web-traffic around these issues. At least until I find that another change (or even this initially mentioned WebView one itself?)
has now made it a notable plight amongst the Android community and suddenly it is creating chaos across a very wide spread of people...
(Sorry, yes, long. There's no easy TL;DR; explanation. Though I sincerely tried!)
Author
Topic: The Generic Computer Advice Thread (Read 572613 times)