Bug 56339 - DOM::Node::GetCursor() gives weird results in some cases
Summary: DOM::Node::GetCursor() gives weird results in some cases
Status: RESOLVED INTENTIONAL
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: SVN
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-03-24 20:01 UTC by Nicolas Deschildre
Modified: 2003-09-14 20:26 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas Deschildre 2003-03-24 20:01:11 UTC
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
Comment 1 Nicolas Deschildre 2003-05-10 20:12:13 UTC
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. 
Comment 2 Nicolas Deschildre 2003-09-14 20:26:18 UTC
getCursor will become invalid, and kafka use now the khtml caret mode, so let's close 
the bug.