Closed Bug 27124 Opened 25 years ago Closed 25 years ago

crash clicking on text control at www.netaddress.com

Categories

(Core :: Layout, defect, P1)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: buster, Assigned: karnaze)

References

()

Details

(Keywords: top100, Whiteboard: [PDT+]2/24)

Attachments

(2 files)

1) load the url 2) click on the first text control 3) crash. what's going on: in PresShell::ScrollFrameIntoView(), this line: aFrame->GetOffsetFromView(mPresContext, offset, &closestView); is returning an outrageously large value in offset.x. The method blindly continues on, and eventually we blow our stack in gfx scroll frame code. If I add this code just after the call above: static int xxx_outrageousX = 100000; static int xxx_outrageousY = 100000; // if something stupid is going on, just return if (offset.x > xxx_outrageousX || offset.y > xxx_outrageousY) return NS_OK; Then the page lays out at a huge width. There are many errors printed to the console about the block inside a TD returning outrageous width requests. But, the initial layout of the table looks correct.
eric: I cc'd you just in case you were interested in putting assertion code in the gfx scroll frame to catch cases where they'll go balistic. Like: void nsGfxScrollFrameInner::ScrollbarChanged(...) { static int xxx_outrageousX = 10000; static int xxx_outrageousY = 10000; NS_ASSERTION(aX<xxx_outrageousX, "outrageous x input"); NS_ASSERTION(aY<xxx_outrageousY, "outrageous y input"); if (aX > xxx_outrageousX || aY > xxx_outrageousY) return; =============================================== assigned to myself, probably a block problem. But I could sure use some help getting a minimized test case!
Assignee: kmcclusk → buster
Keywords: beta1, helpwanted
Priority: P3 → P1
Whiteboard: [help wanted]
Target Milestone: M14
Putting on PDT+ radar for beta1.
Whiteboard: [help wanted] → [PDT+][TESTCASE NEEDED]
Attached file minimized test case (deleted) —
Not sure this a beta 1 stop ship. Clearing PDT+ status. Also, tried this on today's build with Win98 and couldn't reproduce the crash.
Whiteboard: [PDT+][TESTCASE NEEDED] → [TESTCASE NEEDED]
crash or not, the page is totally unusable. hard problem, I spent most of yesterday on it and made very little progress.
Whiteboard: [TESTCASE NEEDED] → 2/18
Given the low odds of this happening, let's reduce; marking PDT-.
Whiteboard: 2/18 → [PDT-]2/18
I just tested the attached minimized test case on todays versions of both WinNT and linux and it works just fine on both platforms. However I made a minimized test case myself that shows the exact same problem as the original URL, I'll attach that too to this bug.
Attached file New minimized testcase. (deleted) —
Chris: the crash is due to casting a child frame to an nsTableRowGroupFrame without first checking that is really is of the correct type. This occurs in nsTableFrame::RecoverState(). Doing a code review, I notice the same problem lurks in nsTableFrame::AdjustSiblingsAfterReflow(), though I don't have a test case that exploits that bug. The attached test case has an <input> as a child of the table. pdt team: I strongly suggest you reconsider this for PDT+. The fix is trivial (there is already lots of code that does the proper check, the check was just omitted in this case.) The cast is very dangerous, and will crash unpredictably in many cases. The test case attached here is indicative of many similar pages I've seen in the top100.
Assignee: buster → karnaze
Keywords: helpwantedtop100
Whiteboard: [PDT-]2/18 → 2/18
I have a fix locally that also passes the regression tests.
Status: NEW → ASSIGNED
Whiteboard: 2/18 → 2/24
Putting on PDT+ radar for beta1.
Whiteboard: 2/24 → [PDT+]2/24
fixed
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fixed in the Feb 29 build.
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: