30038 - caret disappears after clicking in textfield

Status: VERIFIED DUPLICATE of bug 25930

(Core :: DOM: Editor, defect, P1)

Description

[shrirang khanzode]

I see this only on mac build for today.

1. Install and launch the browser
2. Select File->Open Web Location
3. Observe that a 'Open Web Location' dialog opens up and the cursor is blinking 
   inside the textfield.
4. If I click the mouse in the textfield, the cursor disappears, although I can 
   type.

Comment 1

[Daniel (Leaf) Nunes]

Marking regression, not smoketest blocker.

Comment 2

[Thomas Ruch]

on the win32 build, there is a similar problem.  to reproduce, click in a text
field.  you have a cursor.  now hold the right arror key to move to the end of
your entry.  if your cursor goes past the end of your entry, the cursor
disappears and won't reappear unless you click back into the field.  this
doesn't affect usage, it's just a cosmetic problem.

Comment 3

[shrirang khanzode]

25930 is the bug for the problem u mentioned.

Comment 4

[Shanjian Li]

The problem is not just cosmetic. After the caret disappear, if
you type another character, it will crash the system (at least 
my debug build).

Comment 5

[Shanjian Li]

I spent some time investigating this problem while I get myself
familar with the codebase. Here is what I found. I am not confident
enough to come with a fix, but hope my finding will help others
to fix this bug.

The problem:
In "nsRangeList::MoveCaret", file layout/base/src/nsRangeList.cpp,
line "if (NS_SUCCEEDED(result = frame->PeekOffset(context, &pos)) && 
pos.mResultContent)", the call is sent to nsTextFrame::PeekOffset. 
The result declare the call is successful, but pos.mContentOffset is 
set to a invalid value -1. When this call is used in following line
"result = TakeFocus(pos.mResultContent, pos.mContentOffset, pos.mContentOffset, 
aContinue, PR_FALSE);", the invalid value cause a invalid focus offset 
being set. All behavior after this point then can be easily explained.

"problems" exposed:
This following "problems" might not be real defect, I just listed here 
FYI.
1, in nsRangList::MoveCaret,
   If nsTextFrame::PeekOffset is allowed to set a invalid value while 
   still declare success, this value should be checked before applied 
   to TakeFocus. Since the value is passed as unsigned integer, there 
   seems no way for TakeFocus to find it out.
in nsTextFrame::PeekOffset
2, If the next move is outside current frame, should the movement be 
   continued in next frame, especially inside textFrame?
3, in line "result = aPos->mResultFrame->PeekOffset(aPresContext, aPos);",
   if the call is not successful, normally "aPos" value returned should 
   either be untouched or unuseful after the call. 
4, (Most questionable)In following lines;
  if (NS_FAILED(result)){
    aPos->mResultContent = mContent;
    //aPos->mContentOffset = aPos->mStartOffset;
    result = NS_OK;
  }
  Why it pretends to be successful even we know it does not? Should it 
  return failure?

Comment 6

[Kathleen :Brade]

[e-mail]--thanks for tracking this down!

Mike--can you look into this soon?  It looks like you might be able to fix this 
one pretty easily based on the information shanjian has provided.

Comment 7

[Kathleen :Brade]

use "caret" rather than "cursor" since it is more properly and will be found in 
bugzilla queries

Comment 8

[mjudge]

ok the "search next character" is working. in fact its working too well. it is
finding the end of the text frame then looking for next viable sibling. it has
none then it goes up! up to the block frame. up to the area frame. up to the
root frame then finally to some kind of scroll view. where it FINALLY finds a
sibling (illegal sibling thus all the -1 for content offset). the only REAL way
to stop this is to know when we hit the root frame. do we have a way in layout
to find the root frame easilly? i will investigate

Comment 9

[mjudge]

i think saari just checked in a fix for this first part. the second part should 
be fixed tomorrow.

Comment 10

[mjudge]

sorry didnt get to this yet. m16 early for sure.

Comment 11

[mjudge]

*** This bug has been marked as a duplicate of 25930 ***

Comment 12

[Sebastian Späth]

VERIFY dupe