334563 - Crash [@ nsLineIterator::FindLineContaining] when browsing in caret mode an moving with left arrow key

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Martijn Wargers (dead)]

Unfortunately, I can't reproduce this constantly, but I suspect this is a recent(ish) regression.

Talkback ID: TB17715744K
nsLineIterator::FindLineContaining   nsSelection::GetPrevNextBidiLevels   nsCaret::GetCaretFrameForNodeOffset   nsCaret::DrawAtPositionWithHint   nsCaret::DrawCaret   nsCaret::StopBlinking   nsEventStateManager::SendFocusBlur   nsQueryInterface::operator()   nsHTMLSelectElement::GetOptions   nsEventStateManager::GetFocusControllerForDocument   kModuleInfo
nsWebShell::AddRef   0x0c7d8b57

Click somewhere in the Firefox 1.5 headline (you can see that in the second column of the page).
Now keep the left arrow key pressed.
It gets stuck at the last link of that section and the anchor of the next section, I think. This is a bug in itself.
But sometimes I also get a crash with current trunk build when doing that.
Not sure how to trigger this reliably, though.

Comment 1

[Uri Bernstein]

I can't reproduce the crash (on Mac), but something wrong is certainly going on here. Taking.

Comment 2

[Uri Bernstein]

Attachment: testcase

Try using the left-arrow to move the caret from the first line to the second.
This testcase crashes for me in Firefox 1.5.0.2 (when pressing left-arrow twice after moving to the left edge of the first line), but this crash is in nsLineIterator::CheckLineOrder and seems unrelated.
In a trunk build this doesn't crash, but the caret never moves to the second line.

Comment 3

[Uri Bernstein]

Attachment: related(?) LTR testcase

This is an LTR-only testcase.
Try moving the caret from the first line to the second using right-arrow. The caret does appear to reach the beginning of the second line, but cannot be moved further to the right. Pressing left arrow reveals that the caret is actually at the end of the second line.

This testcase displays the same behavior in Fx 1.5.0.2, i.e. it does not show a regression.

Comment 4

[Martijn Wargers (dead)]

I can't find a reprocucable way to crash, but with a lot of trying I can make it crash.
But I also think that fixing the weird caret movement with the directional keys could probably fix it.
Thanks for taking this!

Comment 5

[Uri Bernstein]

Did you ever crash with my (first) testcase? Can you try to?
Can you describe exactly what you're doing when you do crash (even if doing so doesn't usually lead to a crash)?

I've spun-off bug 334626 for the strange caret movement issues after I realized that they are (at least mostly) not bidi-related. Fixing that might take time, so if I can reproduce the crash here, I'd like to try fix it regardless of the other issues.

Comment 6

[Martijn Wargers (dead)]

(In reply to comment #5)
> Did you ever crash with my (first) testcase? Can you try to?
> Can you describe exactly what you're doing when you do crash (even if doing so
> doesn't usually lead to a crash)?

No, I didn't crash with your first testcase (yet). I tried it for 5 minutes or so.
But that doesn't necessarely means it won't crash, because I know have trouble getting the crash with the site.

I am just keeping the left arrow key pushed down to let the caret move and then suddenly push the up arrow. This seems to crash sometimes at the spot where the caret is moving so erratically.
I'm sorry that I'm still rather vague here.

Comment 7

[Martijn Wargers (dead)]

(In reply to comment #6)
> I am just keeping the left arrow key pushed down to let the caret move and then
> suddenly push the up arrow. 
Well, I now just got a crash with constantly pressing the left arrow quickly and repeatedly.

Comment 8

[Uri Bernstein]

(In reply to comment #7)
> (In reply to comment #6)
> > I am just keeping the left arrow key pushed down to let the caret move and then
> > suddenly push the up arrow. 
> Well, I now just got a crash with constantly pressing the left arrow quickly
> and repeatedly.
> 

At the point where the caret toggles between the ellipsis and the Mozilla logo, right?
I had no luck so far trying to crash that way.

Comment 9

[Martijn Wargers (dead)]

(In reply to comment #8)
> At the point where the caret toggles between the ellipsis and the Mozilla logo,
> right?
> I had no luck so far trying to crash that way.

Yes.
I'm not surprised you didn't manage to crash. I tried to crash while debugging, but then I didn't succeed in crashing.

Comment 10

[Martijn Wargers (dead)]

Attachment: testcase2

I think I finally found a way to get a semi-reproducable crash.

Steps to reproduce (also included in the testcase):
1 Turn on Caret browsing (F7 key)
2 Position the caret inside 'Mozilla1.7' link, between the letter 'z' and 'i'
3 Press 2 times the up arrow key,
  you should finish inside the 'тег...' link, between the 'т' and the 'е'
4 Press and hold down the left arrow key

Result:
Crash

Note: This way, it doesn't crash always, but I manage to crash it at least 30% of the time or so.
      When it doesn't crash, try in step 2 to position the caret 
      in between the letters 'o' and 'z' or 'M' and 'o'.

Comment 11

[Martijn Wargers (dead)]

I managed to crash once in my debug build, but not when I run it under gdb.

Comment 12

[Uri Bernstein]

(In reply to comment #10)
> Created an attachment (id=221074) [edit]
> testcase2

The instructions here don't work for me on Mac: with the default font size the "Mozilla" link is on the third line of the block, so pressing up-arrow twice just moves into the bold "Mozilla 1.7.13".
When I make the font smaller, I can sort-of follow the steps, but I still don't crash (tried several times). 

Comment 13

[Martijn Wargers (dead)]

Attachment: testcase3

Testcase3, with css:
body {
font-family: sans-serif;
font-size: 16px;
}
This is what I have as computed style, so I hope you now get to see the same on mac.
I'll attach a screenshot too, of what I see on winxp.

Comment 14

[Martijn Wargers (dead)]

Attachment: screenshot of testcase3 under winxp

Comment 15

[Uri Bernstein]

By changing the div width to 360px, I made the testcase look and behave as you describe, on my Mac. Unfortunately, still no crash :(

Comment 16

[Martijn Wargers (dead)]

Ok, I now can see a regression range. Doesn't crash with 2006-03-11 build, crashes with 2006-03-12 build (100% reproducable in this one), talkback ID from a 2006-03-12 build: TB18369271M. That backtrace looks odd, though. I guess bug 303884 might have something to do with it.

Comment 17

[Martijn Wargers (dead)]

And between 2006-03-18 and 2006-06-20 the crash disappears again.
I'm pretty sure that when the caret movement would be fixed, the crash will also disappear, because the caret movement also regressed between 2006-03-11 and 2006-03-12.

Comment 18

[Uri Bernstein]

The crash between 2006-03-12 and 2006-03-19 is similar to bug 330881 (which was indeed a regression from bug 303884, and was fixed between 2006-03-19 and 2006-03-20).
That crash is in nsLineIterator::CheckLineOrder, not in nsLineIterator::FindLineContaining like this one (the rest of the stack trace is also completely different). So I don't think they are directly related.

Comment 19

[Martijn Wargers (dead)]

Attachment: testcase4

Ok, this testcase crashes 100% reproducable for me. Because of the use of enhanced privileges, you need to download the file locally and test it there.
To get the crash, you just need to open the testcase, you should get the crash within 3 seconds.

Comment 20

[Uri Bernstein]

Sorry, not crashing with this testcase either in:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060708 Minefield/3.0a1 ID:2006070808

(Yes - I downloaded it, replied "allow" to the security warning, and watched the caret run from left to right).

So I'm afraid someone else (with a PC?) will have to investigate this.

Comment 21

[Martijn Wargers (dead)]

Very annoying, with the last testcase (testcase4), I can reproduce it in my debug build, but when I've started my debug build up, using gdb, I can't reproduce it anymore.

Comment 22

[Martijn Wargers (dead)]

Attachment: testcase5

Probably the same issue, but with a different stacktrace.
Talkback ID: TB20902436K
nsLineIterator::FindFrameAt  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/generic/nsLineBox.cpp, line 833]
nsFrameSelection::GetPrevNextBidiLevels  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/generic/nsSelection.cpp, line 1864]
nsCaret::GetCaretFrameForNodeOffset  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCaret.cpp, line 653]
nsCaret::PrimeTimer  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCaret.cpp, line 533]
nsCaret::DrawCaret  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCaret.cpp, line 978]
etc.

You need to download the testcase locally to get the crash.
It seems to have the same regression range, and again, I can't reproduce this in my debug build.

Comment 23

[Martijn Wargers (dead)]

I have tested testcase4 and testcase5, and they don't crash anymore, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060831 Minefield/3.0a1

So this is fixed by bug 334626.