Bug 52685

Summary:	japanese kinput2 input method status window doesn't show in javascript focused form page
Product:	[Applications] konqueror	Reporter:	llch
Component:	khtml ecma	Assignee:	Konqueror Developers <konq-bugs>
Status:	RESOLVED NOT A BUG
Severity:	normal	CC:	grundleborg, kaminmat, ktdeeter, takumi, warren
Priority:	NOR
Version:	3.1.3
Target Milestone:	---
Platform:	RedHat Enterprise Linux
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description llch 2003-01-07 01:49:50 UTC

Version:            (using KDE KDE 3.0.99)
Installed from:    RedHat RPMs
OS:          Linux

When accessing a page that has javascript focus() to textbox (like google.com), kinput2 cannot receive the correct position of textbox of window for status window as konqueror executes javascript 'before' the widget is being drawn. However, normally after the widget is drawn and if you refocus (switching 
windows, click, etc). Because it contains the widget already so it can get the correct position hence passing XNSpotLocation to XIM server correctly.

How to Reproduce:
- in jp env with kinput2
- konqueror
- open www.google.com
- shift-space when you see the javascript focused the input to the textbox

Comment 1 warren 2003-09-12 11:05:08 UTC

Still broken in kdebase-3.1.3-7.

Comment 2 warren 2003-09-12 11:07:21 UTC

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62445
Read Red Hat's bug report for deeper analysis about this problem.

llch, please add votes to this bug if you have any available?  I really want
this to get more attention from the KDE developers.

Comment 3 llch 2003-09-16 03:40:26 UTC

Agreed this is pretty important for i18n so I put all my vote to this.

Comment 4 Daisuke Kameda 2003-09-22 16:50:41 UTC

I think that calling QWidget::setMicroFocusHint() when javascript focus() set  
focus to textbox will solve this problem. However, since I am not reading the  
source code, I do not know whether it becomes big changes or ends with small  
changes.

Comment 5 George Goldberg 2007-12-19 04:52:30 UTC

Is this bug still present in a recent version of KDE, such as 3.5.8 or KDE 4.0RC2?

Comment 6 Janek Bevendorff 2012-06-19 17:38:52 UTC

Closing due to lack of feedback.