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

RESOLVED FIXED

Status

()

--
critical
RESOLVED FIXED
13 years ago
8 years ago

People

(Reporter: martijn.martijn, Unassigned)

Tracking

({crash, testcase})

Trunk
x86
Windows XP
crash, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(6 attachments, 1 obsolete attachment)

(Reporter)

Description

13 years ago
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
Created attachment 218958 [details]
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.
Created attachment 218959 [details]
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.
Depends on: 334626
(Reporter)

Comment 4

13 years ago
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.
(Reporter)

Comment 6

13 years ago
(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.
(Reporter)

Comment 7

13 years ago
(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.
(Reporter)

Comment 9

13 years ago
(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.

(Reporter)

Comment 10

13 years ago
Created attachment 221074 [details]
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'.
(Reporter)

Comment 11

13 years ago
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). 

(Reporter)

Comment 13

13 years ago
Created attachment 221080 [details]
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
(Reporter)

Comment 14

13 years ago
Created attachment 221081 [details]
screenshot of testcase3 under winxp
By changing the div width to 360px, I made the testcase look and behave as you describe, on my Mac. Unfortunately, still no crash :(
(Reporter)

Comment 16

13 years ago
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.
(Reporter)

Comment 17

13 years ago
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.
(Reporter)

Comment 19

13 years ago
Created attachment 228702 [details]
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
(Reporter)

Comment 21

13 years ago
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.
(Reporter)

Comment 22

13 years ago
Created attachment 229084 [details]
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.

Updated

13 years ago
Keywords: testcase
(Reporter)

Comment 23

12 years ago
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
Last Resolved: 12 years ago
Resolution: --- → FIXED

Updated

11 years ago
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.