Closed Bug 52333 Opened 24 years ago Closed 24 years ago

Infinite loop shifting focus due to anonymous content parenting error

Categories

(Core :: Layout, defect, P1)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: mikepinkerton, Assigned: buster)

References

()

Details

(Keywords: crash, Whiteboard: [nsbeta3+][PDTP1])

Attachments

(3 files)

- go to cnn.com (build from 9/12) - select some text on the page - hit tab app locks up, goes into an infinite loop in the ESM::ShiftFocus()
actually, you don't event have to select text, just click in the content area. this is bad, nsbeta3. It's not a crash, but it hangs the machine.
Keywords: crash, nsbeta3
Summary: Infinite loop shifting focus → Infinite loop shifting focus
nsbeta3+, P1 for M18
Priority: P3 → P1
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
The minimum test (I am not kidding). The <HR> makes the whole CNN page go nuts. <HTML> <BODY> <TABLE border> <TR> <TD><A HREF="foo">foo</a></TD> </TR> <TR> <TD><HR></TD> </TR> </TABLE> </BODY> </HTML>
The issue is that the leaf frame iterator is getting confused because a child frame is also a sibling of its parent frame in this case. As I understand it, this should never happen in the frame tree, and falls squarely into layout's domain. frame1--------(sibling) | (child) | frame2 | | (child) | frame3<------| Reassigning to karnaze.
Assignee: saari → karnaze
Attached file test case with some text added (deleted) —
Buster, the infinite loop occurs in nsEventStateManager::GetNextTabbableContent. "dump frames" shows that the Frame<hr> and Inline<hr> are siblings, but the mParent of Inline<hr> is pointing to Frame<hr>. I'm changing the platform and OS from Mac to all.
Assignee: karnaze → buster
OS: Mac System 9.0 → All
Hardware: Macintosh → All
my top priority bug right now. investigating...
Status: NEW → ASSIGNED
WorksForMe. I think this was probably a side-effect of bug 52307. Pink, could you please pull the latest source and verify?
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
nope, still does it, build from 10am 9/19/00. sorry for the bad news.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
btw, i'm on mac if that helps (where the bug was originally reported)
yep, you're right, I just got it to fail too. dang. I was able to click on a control, tab all the way to the end of the document, shift-tab all the way back up, and then it would lock up.
Status: REOPENED → ASSIGNED
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP1]
PDT agrees P1
Pink: you diagnosed this one perfectly. I'm testing a fix now. Thanks for all the help!
saari/karnaze did all the work. i just whined a lot.
changing component to layout. attaching patch. karnaze and waterson, please review. the patch simply passes the correct parent frame to the two CreateGeneratedContentFrame() calls (one for :before, and one for :after.) I was incorrectly passing in the newly created frame, which would have been correct had HR been a proper container. But the anonymous content associated with HR's is set up as siblings of the HR, and therefore children of HR's parent. All this only occurs in quirks mode, triggered from style rules in quirk.css
Component: XP Toolkit/Widgets → Layout
Whiteboard: [nsbeta3+][PDTP1] → [nsbeta3+][PDTP1] [fix in hand]
makes sense. r=waterson
made subject more descriptive
Summary: Infinite loop shifting focus → Infinite loop shifting focus due to anonymous content parenting error
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
Whiteboard: [nsbeta3+][PDTP1] [fix in hand] → [nsbeta3+][PDTP1]
verified fixed mac/linux/win32 20000922nn mac/linux/win32 builds, for cnn.com and the two different testcases. No hang/loop when tabbing.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: