[prev in list] [next in list] [prev in thread] [next in thread] 

List:       konq-bugs
Subject:    [Bug 151355] New: khtml: clicking in multiline text box selects text
From:       sigra () home ! se
Date:       2007-10-25 23:09:54
Message-ID: 20071026010953.151355.sigra () home ! se
[Download RAW message or body]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=151355         
           Summary: khtml: clicking in multiline text box selects text
           Product: konqueror
           Version: unspecified
          Platform: Gentoo Packages
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: khtml
        AssignedTo: konq-bugs kde org
        ReportedBy: sigra home se


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. \
_______________________________________________ Konq-bugs mailing list
Konq-bugs@mail.kde.org
https://mail.kde.org/mailman/listinfo/konq-bugs


[prev in list] [next in list] [prev in thread] [next in thread]