#8502 closed bug (no change required)
BTextView sometimes refuses diacritics (says ":inline_only")
Reported by: | ttcoder | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Kits/Interface Kit | Version: | R1/Development |
Keywords: | :inline_only BTextView | Cc: | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
Sometimes Haiku boots into a state where BTextView won't accept to type (among others) french diacritics like ê or ä. Rebooting generally fixes the problem.
Attachments (1)
Change History (9)
by , 13 years ago
Attachment: | StyledEdit_refuses_diacritic.png added |
---|
comment:2 by , 12 years ago
FWIW, still there in hrev45325 .
Out of curiosity I used the haiku.it.su.se search engine and found two instances of ":inline_only":
- http://haiku.it.su.se:8180/source/xref/src/servers/input/InputServer.cpp
- http://haiku.it.su.se:8180/source/xref/src/add-ons/input_server/devices/keyboard/KeyboardInputDevice.cpp
(namely, message->AddBool("be:inline_only", true);
)
So I'm still leaning to this theory: there is a race condition in the bootup-time initialization of the i18ln code, which makes it sometime look up data in the wrong place, i.e. in the BMessage above (or in the TEXT data segment/area of the code ?? that's where the "be:inline_only" text originates, before being written to a BMessage field of course).
As to the difference between Pe and BTextView, maybe it's because InputServer/KbdInputDevice processes things differently depending on whether the BView is "input method aware " or not (?)
EDIT: also attempted to run Debugger on StyledEdit to catch it "in the act", but gave up quickly (since when you click anywhere in Debugger it de-activates StyledEdit and thus the chevron is deactivated anyway).
comment:3 by , 11 years ago
Didn't see that one in months. Suggest closing, I'll re-open if this mem corruption(?) starts occuring again in newer hrevs.
comment:6 by , 11 years ago
Resolution: | → no change required |
---|---|
Status: | new → closed |
comment:7 by , 10 years ago
Noticed for a few weeks that this is back/still there, but this time the string is "e" instead of ":inlineonly..". I'm going to upgrade from 47991 to hrev48117 soon, leaving this ticket closed on the off chance that the aforementionned tough-ass kernel fix ends up fixing this ticket too :-) (noted ticket:11377#comment:3)
EDIT: seeing the bug (first time in a long time) today, still with string "e", on this old hrev48168 install; that's close enough to begeistert that I can't remember if it's pre-fixes or post-fixes, so leaving this ticket closed still, until I'm able to upgrade this install later.
comment:8 by , 10 years ago
For the record, looks like this was actually fixed in hrev49019, for which one can make a quite plausible scenario that fits the observed behavior: one of the delete[] string
prematurely frees the character being typed after the dead key, which thus could randomly (depending on heap layout) get clobbered by the string "be:inline_only" in method _EnqueueInlineInputMethod().
Another one that was not detected by Coverity, but caught by the guarded heap, go mmlr! 8-)
Steps to reproduce, once Haiku is booted into a "hosed" state:
Bug properties I've found so far:
UPDATE:
Grabbo: