Closed
Bug 334563
Opened 18 years ago
Closed 18 years ago
Crash [@ nsLineIterator::FindLineContaining] when browsing in caret mode an moving with left arrow key
Categories
(Core :: Layout: Text and Fonts, defect)
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.
Updated•18 years ago
|
Assignee: mozilla → nobody
Component: MailNews: BiDi Hebrew & Arabic → Layout: BiDi Hebrew & Arabic
QA Contact: giladehven → layout.bidi
Comment 1•18 years ago
|
||
I can't reproduce the crash (on Mac), but something wrong is certainly going on here. Taking.
Assignee: nobody → uriber
Comment 2•18 years ago
|
||
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•18 years ago
|
||
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.
Reporter | ||
Comment 4•18 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!
Comment 5•18 years ago
|
||
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•18 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•18 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.
Comment 8•18 years ago
|
||
(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•18 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•18 years ago
|
||
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•18 years ago
|
||
I managed to crash once in my debug build, but not when I run it under gdb.
Comment 12•18 years ago
|
||
(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•18 years ago
|
||
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•18 years ago
|
||
Comment 15•18 years ago
|
||
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•18 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•18 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.
Comment 18•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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•18 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•18 years ago
|
||
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.
Reporter | ||
Comment 23•18 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
Closed: 18 years ago
Resolution: --- → FIXED
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: layout.bidi → layout.fonts-and-text
Assignee | ||
Updated•13 years ago
|
Crash Signature: [@ nsLineIterator::FindLineContaining]
You need to log in
before you can comment on or make changes to this bug.
Description
•