Closed Bug 237957 Opened 20 years ago Closed 20 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: 20 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: 20 years ago20 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: