Closed Bug 334563 Opened 15 years ago Closed 14 years ago

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

Categories

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

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: martijn.martijn, Unassigned)

References

()

Details

(Keywords: crash, testcase)

Crash Data

Attachments

(6 files, 1 obsolete file)

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.
Assignee: mozilla → nobody
Component: MailNews: BiDi Hebrew & Arabic → Layout: BiDi Hebrew & Arabic
QA Contact: giladehven → layout.bidi
I can't reproduce the crash (on Mac), but something wrong is certainly going on here. Taking.
Assignee: nobody → uriber
Attached file 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.
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.
Depends on: 334626
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!
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.
(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.
(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.
(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.
(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.

Attached file testcase2 (obsolete) —
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'.
I managed to crash once in my debug build, but not when I run it under gdb.
(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). 

Attached file 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.
Attachment #221074 - Attachment is obsolete: true
By changing the div width to 360px, I made the testcase look and behave as you describe, on my Mac. Unfortunately, still no crash :(
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.
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.
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.
Attached file 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.
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.
Assignee: uriber → nobody
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.
Attached file 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.
Keywords: testcase
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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: layout.bidi → layout.fonts-and-text
Crash Signature: [@ nsLineIterator::FindLineContaining]
You need to log in before you can comment on or make changes to this bug.