256835 - [crash]ctrl+left cause crash in bugzilla [@ nsTextFrame::PeekOffset ][@ ntdll.dll - nsFrame::GetFrameFromDirection ]

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Ginn Chen]

go to any bug report.
e.g. http://bugzilla.mozilla.org/show_bug.cgi?id=241023

use F7 to turn on caret browsing.

put caret in "Requestee:" of "Flags: (Help!)  Requestee: "
press ctrl+left, caret goes to "^Requestee:"
press ctrl+left again, caret goes to "^(Help!)"
press ctrl+left again, caret goes to "^Flags:"
press ctrl+left again, mozilla crash.

Comment 1

[Ginn Chen]

I'm testing my patch. I will post it tommorrow.

Comment 2

[Ginn Chen]

Attachment: patch

1. change "do ... while(isBidiGhostFrame || !selectable)" to "for(;;)"
because before isBidiGhostFrame's value is set, there's "continue;"

2. we should get out earlier, if we get (!isBidiGhostFrame && selectable)
our "newFrame" may get changed by following code, we should just break out of
the loop now.

Comment 3

[Ginn Chen]

This patch also fixed bug 256268, bug 241034, and bug 130889
(the second testcase of bug 130889 has a <hr> issue filed as bug 256833)

Comment 4

[Adam Hauner]

Bug 242835 should be also related.
Adding crash signatures from Trunk (TB664701E) and FF093 (TB664717W, TB664692G).

Comment 5

[Ginn Chen]

confirmed, this patch will also fix bug 144610, bug 242835

Comment 6

[Ginn Chen]

*** Bug 144610 has been marked as a duplicate of this bug. ***

Comment 7

[Ginn Chen]

*** Bug 242835 has been marked as a duplicate of this bug. ***

Comment 8

[Johnny Stenback (:jst)]

Comment on attachment 157021 [details] [diff] [review]
patch

This changes this loop to not break out of the loop if we're at a bidi ghost
frame, and I'm not sure that's the right thing to do... As this isn't code I
normally work with I'm pushing this sr request over to dbaron.

Comment 9

[Ginn Chen]

The change brings "while condition" ahead.

Origin code uses "continue;", but "isBidiGhostFrame" isn't set yet.
So we can't get loop as we need.
4027     if (nsLayoutAtoms::textFrame != newFrame->GetType())
4028       continue;  //we should NOT be getting stuck on the same piece of 
content on the same line. skip to next line.
4029   }
4030   isBidiGhostFrame = (newFrame->GetRect().IsEmpty() &&
4031                       (newFrame->GetStateBits() & NS_FRAME_IS_BIDI));

Comment 10

[Neb Radivojevic]

similar problem

win xp home, firefox 0.97 - (sp 1 installed)

using the yahoo mail web portal. create a message, select attachment, in the
window (OS) select a file, prest ctrl c (copy) - mozila crashes.

- neb radivojevic - 
QA Analyst

Comment 11

[Ginn Chen]

Neb, 
I can't reproduce your crash with Firefox 1.0PR 0.10.1.
And I don't think it relates to this bug.

Comment 12

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Comment on attachment 157021 [details] [diff] [review]
patch

sr=dbaron, although this code is a mystery to me (I'm assuming it's not a
mystery to you), if you make the following changes:

 * move the declaration of isBidiGhostFrame to where it's first assigned
(inside the loop)
 * move the declaration of selectable to the line before it's first used
(inside the loop)

Comment 13

[Ginn Chen]

Attachment: patch addressing dbaron's comment

Comment 14

[Ginn Chen]

Checking in nsFrame.cpp;
/cvsroot/mozilla/layout/html/base/src/nsFrame.cpp,v  <--  nsFrame.cpp
new revision: 3.529; previous revision: 3.528
done

Comment 15

[Ginn Chen]

*** Bug 256268 has been marked as a duplicate of this bug. ***

Comment 16

[Ginn Chen]

*** Bug 241034 has been marked as a duplicate of this bug. ***

Comment 17

[Ginn Chen]

*** Bug 130889 has been marked as a duplicate of this bug. ***

Comment 18

[Uri Bernstein]

The patch for this bug caused bug 288789.

Comment 19

[Frank Wein [:mcsmurf]]

*** Bug 298316 has been marked as a duplicate of this bug. ***

Comment 20

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381