56339 2003-03-24 20:01:11 +0000 DOM::Node::GetCursor() gives weird results in some cases 2003-09-14 20:26:18 +0000 1 1 2 Applications konqueror khtml SVN Compiled Sources Linux RESOLVED WONTFIX NOR normal --- 1 ndeschildre konqueror-bugs-null 21 oldest_to_newest 124896 0 ndeschildre 2003-03-24 20:01:11 +0000 Version: (using KDE 3.1.9) Compiler: gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk) OS: Linux (i686) release 2.4.19-16mdk I'm using KDE CVS 20030316. The function DOM::Node::getCursor() gives some weird results in two specific case : - the cursor position at offset x just before a whitespace and at offset x+1 are always almost the same or totally the same. - the cursor position at offset x just at the beginning of a line (wih or without text before) sometimes give the position of the cursor of the end of the line. This could easily be reproduced by taking any HTML page with a quite long text taking more than one line, and by compiling quanta with kafkapart support ( --with-kafkapart ont the configure script ) and using the WYSIWYG editor. Good luck 132954 1 ndeschildre 2003-05-10 20:12:13 +0000 I've just found out the cause of the second bug listed here: <tag>text blah blah : in this case, the cursor position (given by DOM::Node::getCursor(), i have forgot to mention) given at the offset 0 is OK (it gives the position before the first letter). <tag> text blah blah : whenever whitespaces (including end of line, and tab) are inserted between the tag and the begin of the text, offset 1 now correspond to the position before the first letter and offset 0 correspond to the position at the end of the string. I believe the offset 0 normally correspond to the beginning of the whitespace added before the first letter when this whitespace is needed (e.g. blah<tag> blah</tag>) but when it isn't needed, the offset 0 correspond to the end of the Node. 158322 2 ndeschildre 2003-09-14 20:26:18 +0000 getCursor will become invalid, and kafka use now the khtml caret mode, so let's close the bug.