Bug 1133283

Summary:	initially wrong layout
Product:	[Fedora] Fedora	Reporter:	Stas Sergeev <stsp2>
Component:	ibus	Assignee:	fujiwara <tfujiwar>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	i18n-bugs, petersen, shawn.p.huang, tfujiwar
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-12-01 04:08:55 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Stas Sergeev 2014-08-24 08:49:12 UTC

Description of problem:
When you just started the session, after the
first switch from EN to RU layout, the initial
typing will be latinic. After some time it will
become cyrillic. The subsequent switches do not
have such a problem: the layout is correct immediately
after the switch. But with "ibus restart" the bug
can be repeated again.

Version-Release number of selected component (if applicable):
ibus-1.5.7-6.fc19.x86_64

How reproducible:
easily

Steps to Reproduce:
1. ibus restart
2. switch layout
3. type quickly

Actual results:
Initial typing has old layout, eventually
changing to the correct one. The delay is
2-3 seconds, you can type quite enough to
get annoyed.

Expected results:
Correct layout immediately. No single char
should be typed with old layout after the switch.

Additional info:

Comment 1 fujiwara 2014-08-25 02:30:53 UTC

ibus restart launches the target engine so it would take some time.
I'd think it's an expected result.

When you start the session, if the engine does not launch soon, I think it's GNOME only and a known issue.

Comment 2 Stas Sergeev 2014-08-25 06:27:07 UTC

It doesn't matter how long have you waited
BEFORE first switch. It only matters how long
have you waited AFTER.
And I don't see a difference between "ibus restart"
and gnome start here. If I do "ibus restart" and then
wait a while, the problem is still there. It matters
only to wait after the first switch.

Comment 3 Stas Sergeev 2014-08-25 06:57:33 UTC

How abouot suspending an output while the
engines are not loaded? Delays are acceptable
and can always be optimized later. Wrong typing
is never acceptable.

Comment 4 fujiwara 2014-08-25 07:15:14 UTC

But normally you don't have to run ibus restart.
When you upgrade ibus, you need to run ibus restart.
It would be still not important for me.

Comment 5 Stas Sergeev 2014-08-25 07:33:34 UTC

(In reply to fujiwara from comment #1)
> When you start the session, if the engine does not launch soon, I think it's
> GNOME only and a known issue.
But why is this not important?
GNOME is still a default in fedora.

Comment 6 fujiwara 2014-08-25 08:51:06 UTC

(In reply to Stas Sergeev from comment #5)
> (In reply to fujiwara from comment #1)
> > When you start the session, if the engine does not launch soon, I think it's
> > GNOME only and a known issue.
> But why is this not important?
> GNOME is still a default in fedora.

The starting issue is different from ibus start. Comment #4 is for ibus start.

Comment 7 Stas Sergeev 2014-08-25 09:39:19 UTC

Yes, "ibus restart" is just to help reproducing
the problem. It is not an original problem, for sure.
Still, since "ibus restart" happens at run-time (after
yum update), it may be worth fixing even this one.
Of course my original thinking was that it is the
same, single bug. Maybe I was wrong.

Comment 8 fujiwara 2014-08-25 10:24:58 UTC

*** Bug 838734 has been marked as a duplicate of this bug. ***

Comment 9 fujiwara 2014-08-25 10:26:31 UTC

https://bugzilla.gnome.org/show_bug.cgi?id=695428

Comment 10 Jens Petersen 2014-08-26 10:06:20 UTC

Is it possible to get the gnome patch reviewed upstream?

Comment 11 fujiwara 2014-12-01 04:08:55 UTC

This will be fixed in Fedora 22.
https://git.gnome.org/browse/gnome-shell/commit/?id=e467a734a1140bbcc35d828c1dab33d66a55d306