Closed Bug 237957 Opened 21 years ago Closed 21 years ago

M17beta crash [@ nsAccessibleHyperText::nsAccessibleHyperText ]

Categories

(Core :: Disability Access APIs, defect)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: Louie.Zhao, Assigned: Louie.Zhao)

References

()

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

Set GNOME_ACCESSIBILITY=1, start mozilla and visit http://house.sinoi.com/, mozilla will crash. If you don't set GNOME_ACCESSIBILITY, this website can display correctly.
Attached patch patch v1Splinter Review
Attachment #144298 - Flags: review?(kyle.yuan)
Attachment #144298 - Flags: review?(kyle.yuan) → review+
Summary: Set GNOME_ACCESSIBILITY=1, start mozilla and visit http://house.sinoi.com/, Mozilla crash when visiting some http://house.sinoi.com/ → Set GNOME_ACCESSIBILITY=1, start mozilla and visit http://house.sinoi.com/
Attachment #144298 - Flags: superreview?(Henry.Jia)
Comment on attachment 144298 [details] [diff] [review] patch v1 sr=Henry
Attachment #144298 - Flags: superreview?(Henry.Jia) → superreview+
Thanks for r and sr. Patch checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
This bug is not fixed - the patch was checked in but later backed out.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment on attachment 144298 [details] [diff] [review] patch v1 This is a simple crash fix which is triggered when running Mozilla with GNOME accessibility enabled.
Attachment #144298 - Flags: approval1.7?
Changing summary, adding crash keyword, -> Louie
Assignee: aaronleventhal → Louie.Zhao
Status: REOPENED → NEW
Keywords: crash
Summary: Set GNOME_ACCESSIBILITY=1, start mozilla and visit http://house.sinoi.com/ → crash @ nsAccessibleHyperText
*** Bug 238993 has been marked as a duplicate of this bug. ***
So what is the underlying bug here? The NS_ASSERTION makes me think this is an unexpected condition, yet it's hit on a number of web sites.
nsAccessible::GetParentBlockFrame is to find the first Block Frame from the current DOMNode. The code assumes there is always one block frame in the parent chain, but unfortuately this is not always true in some cases (especially the page is constructed using table). Since there are some other important a11y bugs to solve, I made the workaround to avoid crash and will find the real reason later.
*** Bug 239417 has been marked as a duplicate of this bug. ***
Blocks: aix-access
Comment on attachment 144298 [details] [diff] [review] patch v1 a=mkaply Are we going to keep this bug open to find the real problem?
Attachment #144298 - Flags: approval1.7? → approval1.7+
Since this is a crash bug, it's better to fix it in 1.7. Using this workaround patch for now, we can find the real problem in a new bug.
Fixed. A new bug should be opened to track down the real cause of this problem. Checking in nsAccessibleHyperText.cpp; /cvsroot/mozilla/accessible/src/atk/nsAccessibleHyperText.cpp,v <-- nsAccessibleHyperText.cpp new revision: 1.18; previous revision: 1.17 done
Status: NEW → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
Severity: normal → critical
Summary: crash @ nsAccessibleHyperText → M17beta crash [@ nsAccessibleHyperText::nsAccessibleHyperText ] [@ _ZN21nsAccessibleHyperTextC2EP10nsIDOMNodeP16nsIWeakReference]
Summary: M17beta crash [@ nsAccessibleHyperText::nsAccessibleHyperText ] [@ _ZN21nsAccessibleHyperTextC2EP10nsIDOMNodeP16nsIWeakReference] → M17beta crash [@ nsAccessibleHyperText::nsAccessibleHyperText ]
Crash Signature: [@ nsAccessibleHyperText::nsAccessibleHyperText ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: