crash in nsINode::GetBoolFlag(nsINode::BooleanFlag)

RESOLVED FIXED in mozilla28

Status

()

Core
Layout
--
critical
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: Guilherme Lima, Assigned: heycam)

Tracking

({crash})

Trunk
mozilla28
x86
Windows NT
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
This bug was filed from the Socorro interface and is 
report bp-a903b6d3-9ab6-461e-ad58-14d592131201.
=============================================================
I'm constantly crashing trying to load any lyrics page on http://letras.mus.br/

other crash reports:
https://crash-stats.mozilla.com/report/index/b09821dd-2816-441c-8c43-6a40b2131201
https://crash-stats.mozilla.com/report/index/32c314fe-2ca8-4faa-84f4-ec02a2131201
https://crash-stats.mozilla.com/report/index/ef658389-ce29-4135-a19b-e1a462131130

It started crashing for me with the build from Oct 29th. I don't have the exactly data because I don't visit the site very often.
I see this starting in regression range http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6ecf0c4dfcbe&tochange=3c44c1f43a67. There is pseudo-element stuff in the crash-stats stack, so I suspect bug 922669 or one of its friends and relations.
Component: General → Layout
Flags: needinfo?(cam)
Product: Firefox → Core
(Reporter)

Comment 2

4 years ago
Ah, yeah, I meant Nov 29th of course.
(Assignee)

Updated

4 years ago
Assignee: nobody → cam
Status: NEW → ASSIGNED
Flags: needinfo?(cam)
Fwiw, all three of those crashes look like null-derefs.
Blocks: 922669
(Assignee)

Comment 4

4 years ago
It looks like the issue is that the page has a style rule with a |button::-moz-focus-inner:active| selector, and in nsButtonFrameRenderer::ReResolveStyle, we don't pass in a content node for the pseudo-element to ProbePseudoStyle, since there isn't one (these are extra style contexts just used for rendering).  Then in ContentEnumFunc, we pass the null pseudo-element into StateSelectorMatches.  I think we should just assume that the state never matches here by returning if pdata->mPseudoElement is null.
Wait, why did "button::-moz-focus-inner:active" parse at all?
(Assignee)

Comment 7

4 years ago
Oh, great question.  The flag I added in nsCSSPseudoElementList.h must not be working?
(Assignee)

Comment 8

4 years ago
I'm not calling nsCSSPseudoElements::PseudoElementSupportsUserActionState anywhere in nsCSSParser.cpp. :/
(Assignee)

Comment 9

4 years ago
Created attachment 8340830 [details] [diff] [review]
patch
Attachment #8340830 - Flags: review?(bzbarsky)
Comment on attachment 8340830 [details] [diff] [review]
patch

>+      if (!pdata->mPseudoElement ||

Do we still need this now that we've fixed the parser bug?

>+  if (!aData->mPseudoElement) {

Likewise.

r=me modulo those.
Attachment #8340830 - Flags: review?(bzbarsky) → review+
(Assignee)

Comment 12

4 years ago
No we shouldn't strictly need those; all of the times we're calling ProbePseudoElementStyle or ResolvePseudoElementStyle for pseudo-elements with the flag allowing the pseudo-classes after them we're passing in an element.
(Assignee)

Comment 14

4 years ago
Thanks Guilherme for the prompt bug report!
https://hg.mozilla.org/mozilla-central/rev/54a8c5aae115
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
(Assignee)

Updated

4 years ago
Duplicate of this bug: 946312
You need to log in before you can comment on or make changes to this bug.