Bug 151355 - khtml: clicking in multiline text box selects text
Summary: khtml: clicking in multiline text box selects text
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-26 01:09 UTC by esigra
Modified: 2011-02-05 10:08 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot showing the result of the bug. (41.98 KB, image/png)
2008-03-15 17:49 UTC, esigra
Details

Note You need to log in before you can comment on or make changes to this bug.
Description esigra 2007-10-26 01:09:53 UTC
Version:           3.5.7 (using KDE KDE 3.5.7)
Installed from:    Gentoo Packages
OS:                Linux

This happens to me very often (almost always) when writing messages in wiki forums (the server software is called xoops). I click on a certain location in the multiline edit box, move the mouse away and start typing something. But khtml is very sluggish. So after the click, it hangs for a second or so, then selects the text from where I clicked to some place that the mouse has passed over after the click. Then it replaces that selection whit the text I typed. This is very frustrating. I have also observed that the click can select some text outside the multiline text box. I think the sluggishness is caused by spell checking, some java script or possibly something clipboard related.

The cause of the mouse handling problem seems to be one of the classic beginners programming errors. The code processes the mouse button down event in the multiline edit box. This triggers some intensive calculation such as spell checking. When this has been processed, it starts processing the next event, which is the mouse button up event. But now it seems to look at the mouse's current location (at the time of event processing), which may be far away, since the intensive calculation took so long time. Therefore it thinks that the mouse was dragged and selects the text between the mouse down location and the current mouse location. But what it should have done is of course to look at the mouse's location at the time the button was released. This information should be available in the mouse event.
Comment 1 esigra 2008-03-15 16:28:25 UTC
I can no longer reproduce this bug with KDE/Konqueror 3.5.8, so I assume that it has been fixed.
Comment 2 esigra 2008-03-15 16:29:05 UTC
I can no longer reproduce this bug with KDE/Konqueror 3.5.8, so I assume that it has been fixed.
Comment 3 esigra 2008-03-15 17:26:49 UTC
Unfortunately this bug is only fixed inside the multiline edit box. But in the text on the page, outside the edit box, it still happens (Konqueror 3.5.8):
1. Go to [http://en.wikipedia.org/w/index.php?title=Unix&action=edit] (the edit page of a huge wiki page).
2. Click in the edit box.
3. Wait until the caret starts blinking.
4. Move the mouse to some place in the text outside the edit box.
5. Click and quickly move the mouse to another place in the same paragraph.

Now there is a great chance that Konqueror will wait for a while and then select the text between the clicked location and the place where the mouse cursor currently happens to be.
Comment 4 esigra 2008-03-15 17:49:02 UTC
Created attachment 23907 [details]
Screenshot showing the result of the bug.

In this screenshot I have clicked in the edit box, waited until the caret
started to blink, clicked in the paragraph below the edit box (between "that
vi" and "olates any") and moved the mouse cursor the place between "violates a"
and "ny ". As you can see, conqueror selected the text "olates a".

For some reason I could not reproduce the bug with a really tiny Konqueror
window, so I suggest that anyone who tries to reproduce it maximizes the
window.
Comment 5 James Richard Tyrer 2008-03-16 06:04:47 UTC
I am confirming this bug.

HOWEVER, I believe that it is a KWin bug.  Since I no longer have permission to modify bugs, I can NOT change this.
Comment 6 Linus Östberg 2008-05-01 14:13:49 UTC
I am unable to reproduce this in 3.5.9 and 4.0.3, but I may be too slow moving the pointer or my computer might be too fast.
Comment 7 esigra 2011-02-05 10:08:40 UTC
I can no longer reproduce this bug with current versions of software (and newer hardware).