Closed
Bug 973322
Opened 10 years ago
Closed 10 years ago
Crash [@ nsMathMLChar::PaintForeground]
Categories
(Core :: MathML, defect)
Core
MathML
Tracking
()
RESOLVED
FIXED
mozilla30
People
(Reporter: jruderman, Assigned: fredw)
References
(Depends on 1 open bug)
Details
(Keywords: crash, testcase)
Crash Data
Attachments
(3 files, 2 obsolete files)
305 bytes,
application/xhtml+xml
|
Details | |
8.58 KB,
text/plain
|
Details | |
2.32 KB,
patch
|
Details | Diff | Splinter Review |
No description provided.
Reporter | ||
Comment 1•10 years ago
|
||
Assignee | ||
Comment 3•10 years ago
|
||
Here is a quick patch to set the mGlyphs[0] text run and prevent the crash. I'll need to check more carefully how <mfenced> handles the nsMathMLChar.
Assignee: nobody → fred.wang
Assignee | ||
Comment 4•10 years ago
|
||
I just tried to debug a bit and after the setAttribute, the "overflow: scroll; position: sticky;" frame is calling PresShell::FrameNeedsReflow which is causing a "can't mark frame dirty during reflow" assertion. Note that this happens if you replace the MathML by a <p id="f"/>, so that seems to be the real root of the problem... Unfortunately, this seems to confuse the nsMathMLmfencedFrame. After the setAttribute, the nsMathMLChar's are destroyed and created again. But after the sticky frame tries to reflow things, the nsMathMLChar is painted again, without any call to Stretch/MaxWidth. I guess until the bug with the sticky frame is fixed, we can just verify whether mGlyphs[0] is null before drawing it in nsMathMLChar::PaintForeground. Note that my previous patch fixed the crash but the rendering was still not good (intrinsic widths and parenthesis size) and this is consistent with the fact that Stretch/maxWidth was never called after the reflow caused by the sticky frame.
Assignee | ||
Comment 5•10 years ago
|
||
Attachment #8378290 -
Flags: review?(karlt)
Comment 6•10 years ago
|
||
Comment on attachment 8378290 [details] [diff] [review] Workaround the crash Thanks for investigating.
Attachment #8378290 -
Flags: review?(karlt) → review+
Comment 7•10 years ago
|
||
427017-1.xhtml looks a bit different but perhaps its related.
Depends on: 457400
Assignee | ||
Updated•10 years ago
|
Attachment #8376816 -
Attachment is obsolete: true
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Assignee | ||
Comment 9•10 years ago
|
||
Attachment #8378290 -
Attachment is obsolete: true
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 10•10 years ago
|
||
Thanks :) https://hg.mozilla.org/integration/mozilla-inbound/rev/739971fe2acf
Flags: in-testsuite+
Keywords: checkin-needed
Comment 11•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/739971fe2acf
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Comment 12•10 years ago
|
||
Pushed http://hg.mozilla.org/integration/mozilla-inbound/rev/ee35d0128be9 as a followup, because the sticky pref gets unset when we merge to beta, so not only would the test become permaorange from not having the expected assertion, it would also lose the ability to test for the crash. I'll push it to aurora if releng ever manages to reopen it.
You need to log in
before you can comment on or make changes to this bug.
Description
•