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)
Tracking
()
VERIFIED
FIXED
M14
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]
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.
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 | ||
Comment 10•25 years ago
|
||
I have a fix locally that also passes the regression tests.
Status: NEW → ASSIGNED
Whiteboard: 2/18 → 2/24
Assignee | ||
Comment 12•25 years ago
|
||
fixed
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•