Closed Bug 299188 Opened 19 years ago Closed 19 years ago

[FIX] CSS position:relative on input tag within fieldset tag crashes browser in [@ nsCSSFrameConstructor::GetAbsoluteContainingBlock]

Categories

(Core :: Layout: Form Controls, defect, P1)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: alexkingorg, Assigned: MatsPalmgren_bugz)

References

()

Details

(Keywords: crash, regression, testcase)

Crash Data

Attachments

(4 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050629 Camino/0.9a1+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050629 Camino/0.9a1+

In the Jun. 29th nightly of Camino, loading a page in the WordPress admin
interface causes Camino to crash. I am using the "Tiger" CSS:

http://www.orderedlist.com/articles/wordpress-administration-design-tiger/

I believe the most recent nightly I used before this was the Jun. 27th nightly,
this build did not exhibit this problem.

Reproducible: Always

Steps to Reproduce:
1. Click on bookmark for WP admin interface

Actual Results:  
Camino crashes.

Expected Results:  
Not crash.

Will attach crash log.
Attached file Crash log.
Is this something you can reproduce? Before I try, I want to make sure it's not
a different bug and that it's reproducible.
(In reply to comment #2)
> Is this something you can reproduce? Before I try, I want to make sure it's not
> a different bug and that it's reproducible.

I stopped trying after it crashed twice in a row while loading the page -
loading at the same point in the page I think. Both crash logs are in the
attached .log file.
This looks like a core bug, but I want to confirm it first and see if I can't
figure out exactly what is going on. Is there a particular page you're going to
that causes the crash?

I'm currently testing on opensourcecms.com, but it doesn't have that specific
theme which you're using.

Also: Does this happen when you're *not* logged into the admin interface? As
in... when you click to load the bookmark, it crashes despite the fact that
you're not logged in?
I've saved the page and linked CSS and JS as a test case for you:

http://alexking.org/dev/camino_06-29/crash.html
Attached file Confirmation Crash Log
Confirming with this crash log. Will isolate bug later.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is definitely a regression and also a CSS bug (removing CSS fixes it).
Working on a testcase.
Keywords: regression
This appears to be caused when the position:relative CSS style is defined on an
<input> tag within <fieldset> tags. The following code, combined with
position:relative CSS will crash your browser.

<div class="wrap">
 <fieldset>
  <input name="mn" value="1" size="2" maxlength="2" type="text">
 </fieldset>
</div>
Confirmed on Deer Park 20050629 for Windows.

-> Core
Severity: critical → blocker
Component: General → Layout: Form Controls
OS: MacOS X → All
Priority: -- → P1
Product: Camino → Core
Hardware: Macintosh → All
Version: unspecified → Trunk
Rewriting description, reassigning to nobody, adding QA, and requesting
blocking1.8b3.
Assignee: pinkerton → nobody
Flags: blocking1.8b3?
QA Contact: layout.form-controls
Summary: When loading a page in the WordPress admin interface, Camino crashes → CSS position:relative on input tag within fieldset tag crashes browser
This bug is not present on the Deer Park build from 20050628. It's a recent
regression (as in, the last 48 hours).
Possible causes: bug 294717 (most likely, touched fieldsets specifically), bug
293504, bug 295690. Marking blocking+ for speedy triage, depending on
seriousness we might backout the offending patch or push this to b4.
Flags: blocking1.8b3? → blocking1.8b3+
*** Bug 299227 has been marked as a duplicate of this bug. ***
Assignee: nobody → mats.palmgren
Summary: CSS position:relative on input tag within fieldset tag crashes browser → [FIX] CSS position:relative on input tag within fieldset tag crashes browser
Attached patch Patch rev. 1Splinter Review
What happens here is that nsCSSFrameConstructor::GetAbsoluteContainingBlock is
called before nsFieldSetFrame::SetInitialChildList which means the area frame
does not exist yet (first child is null).
Make GetFieldSetAreaFrame() return nsnull for this case.

(I still think GetAbsoluteContainingBlock() isn't entirely correct in other
cases but I will file a separate bug on that)
Attachment #187834 - Flags: superreview?(dbaron)
Attachment #187834 - Flags: review?(dbaron)
Attachment #187834 - Flags: approval1.8b3?
Blocks: 294717
Attachment #187834 - Flags: superreview?(dbaron)
Attachment #187834 - Flags: superreview+
Attachment #187834 - Flags: review?(dbaron)
Attachment #187834 - Flags: review+
Comment on attachment 187834 [details] [diff] [review]
Patch rev. 1

a=bsmedberg for checkin on 6/30 only
Attachment #187834 - Flags: approval1.8b3? → approval1.8b3+
*** Bug 299243 has been marked as a duplicate of this bug. ***
*** Bug 299289 has been marked as a duplicate of this bug. ***
Checked in to trunk at 2005-06-30 13:31 PDT

-> FIXED
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
*** Bug 299243 has been marked as a duplicate of this bug. ***
Summary: [FIX] CSS position:relative on input tag within fieldset tag crashes browser → [FIX] CSS position:relative on input tag within fieldset tag crashes browser in [ @ nsCSSFrameConstructor::GetAbsoluteContainingBlock]
Summary: [FIX] CSS position:relative on input tag within fieldset tag crashes browser in [ @ nsCSSFrameConstructor::GetAbsoluteContainingBlock] → [FIX] CSS position:relative on input tag within fieldset tag crashes browser in [@ nsCSSFrameConstructor::GetAbsoluteContainingBlock]
Crash Signature: [@ nsCSSFrameConstructor::GetAbsoluteContainingBlock]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: