Crash in libmozglue.dylib@0x2164a - MOZ_CRASH Reason: XBL compat hack matched, please file a bug blocking bug 1374247.

RESOLVED FIXED in Firefox 58

Status

()

defect
--
critical
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: Paenglab, Assigned: emilio)

Tracking

({crash})

unspecified
mozilla58
Unspecified
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox56 unaffected, firefox57 unaffected, firefox58blocking fixed)

Details

(crash signature)

Attachments

(1 attachment)

This bug was filed from the Socorro interface and is 
report bp-c1459882-dd96-4acb-b3f9-d4c570171104.
=============================================================

XBL compat hack matched, please file a bug blocking bug 1374247. Selector: #profiles > listitem > listcell

Crash appears when using ProfileManager.
Flags: needinfo?(emilio)
Summary: Crash in libmozglue.dylib@0x2164a → Crash in libmozglue.dylib@0x2164a - MOZ_CRASH Reason: XBL compat hack matched, please file a bug blocking bug 1374247.
Assignee: nobody → emilio
Flags: needinfo?(emilio)
Duplicate of this bug: 1414525
Richard, are there CSS changes required in TB? You mentioned
  XBL compat hack matched, please file a bug blocking bug 1374247. Selector: caption
in a private message. If so, we should file a bug in TB.
Flags: needinfo?(richard.marti)
With the patch here, TB starts via the profile manager. So how did you get to the crash in comment #3?
(In reply to Jorg K (GMT+2) from comment #3)
> Richard, are there CSS changes required in TB? You mentioned
>   XBL compat hack matched, please file a bug blocking bug 1374247. Selector:
> caption
> in a private message. If so, we should file a bug in TB.

No CSS changes required in TB. The changes here are in toolkit and automatically used by TB too.

The "XBL compat hack matched, please file a bug blocking bug 1374247. Selector: caption" is when opening the in-content prefs in TB. The normal prefs window in TB isn't affected. And yes, this will then be a TB bug.
Flags: needinfo?(richard.marti)
(In reply to Richard Marti (:Paenglab) from comment #5)
> The "XBL compat hack matched, please file a bug blocking bug 1374247.
> Selector: caption" is when opening the in-content prefs in TB. The normal
> prefs window in TB isn't affected. And yes, this will then be a TB bug.
Please file (and fix) a TB bug then.
For the record: When opening TBs in-content prefs I get:
[3300, Main Thread] ###!!! ASSERTION: How did we get this namespace?: 'mNameSpace == kNameSpaceID_Unknown || mNameSpace == kNameSpaceID_None', file c:/mozilla-source/comm-central/mozilla/layout/style/StyleRule.cpp, line 713
Hit MOZ_CRASH(XBL compat hack matched, please file a bug blocking bug 1374247. Selector: caption) at c:/mozilla-source/comm-central/mozilla/layout/style/nsCSSRuleProcessor.cpp:2475
(In reply to Jorg K (GMT+2) from comment #7)
> For the record: When opening TBs in-content prefs I get:
> [3300, Main Thread] ###!!! ASSERTION: How did we get this namespace?:
> 'mNameSpace == kNameSpaceID_Unknown || mNameSpace == kNameSpaceID_None',
> file c:/mozilla-source/comm-central/mozilla/layout/style/StyleRule.cpp, line
> 713
> Hit MOZ_CRASH(XBL compat hack matched, please file a bug blocking bug
> 1374247. Selector: caption) at
> c:/mozilla-source/comm-central/mozilla/layout/style/nsCSSRuleProcessor.cpp:
> 2475

Yeah, that's expected, to get the selector text namespaces correctly we should usually get the namespace map from the stylesheet, but since this is an assertion and the selector without the namespaces is enough to track it down, I decided to not bother passing the sheet around.

FWIW that probably means that the selector starts by "xul|caption >", so it's probably one of the rules at:

  http://searchfox.org/mozilla-central/source/toolkit/themes/shared/in-content/common.inc.css#80
(In reply to Emilio Cobos Álvarez [:emilio] from comment #8)
> 
> Yeah, that's expected, to get the selector text namespaces correctly we
> should usually get the namespace map from the stylesheet, but since this is
> an assertion and the selector without the namespaces is enough to track it
> down, I decided to not bother passing the sheet around.
> 
> FWIW that probably means that the selector starts by "xul|caption >", so
> it's probably one of the rules at:
> 
>  
> http://searchfox.org/mozilla-central/source/toolkit/themes/shared/in-content/
> common.inc.css#80

And why doesn't it assert in FX which uses this too?
Duplicate of this bug: 1414553
(In reply to Richard Marti (:Paenglab) from comment #9)
> (In reply to Emilio Cobos Álvarez [:emilio] from comment #8)
> > 
> > Yeah, that's expected, to get the selector text namespaces correctly we
> > should usually get the namespace map from the stylesheet, but since this is
> > an assertion and the selector without the namespaces is enough to track it
> > down, I decided to not bother passing the sheet around.
> > 
> > FWIW that probably means that the selector starts by "xul|caption >", so
> > it's probably one of the rules at:
> > 
> >  
> > http://searchfox.org/mozilla-central/source/toolkit/themes/shared/in-content/
> > common.inc.css#80
> 
> And why doesn't it assert in FX which uses this too?

Because that needs to match an element in order to assert, we don't assert because of the selector, but because of the selector matching differently on an element. Chances are firefox doesn't use empty <xul:caption>s, which is what would trigger this.
Comment on attachment 8925248 [details]
Bug 1414513: Make the profile manager image selector a bit dumber.

https://reviewboard.mozilla.org/r/196454/#review201690

Seems good, thank you.
Attachment #8925248 - Flags: review?(jhofmann) → review+
Comment on attachment 8925248 [details]
Bug 1414513: Make the profile manager image selector a bit dumber.

https://reviewboard.mozilla.org/r/196454/#review201690

Thank you for the Saturday review Johann! :)
Pushed by ecoal95@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/7183dce1b218
Make the profile manager image selector a bit dumber. r=johannh
Duplicate of this bug: 1414556
Duplicate of this bug: 1414539
Crash Signature: [@ libmozglue.dylib@0x2164a] → [@ libmozglue.dylib@0x2164a] [@ SelectorMatchesTree]
Pushed by dbaron@mozilla.com:
https://hg.mozilla.org/mozilla-central/rev/55562f81645e
Make the profile manager image selector a bit dumber. r=johannh a=dbaron a=nightly-crashes
Given reports of nightly startup crashes, I landed this directly on mozilla-central:
https://hg.mozilla.org/mozilla-central/rev/55562f81645e7636a1cf6afbb6d28d65a9e5c3a3
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
Also, should there be an automated test somewhere that ensures that the profile manager doesn't crash?
Desktop FF Nightly updates are disabled until further notice.

New Nightlies will continue to build, but not served, at their usual times, twice a day based on tip m-c
Duplicate of this bug: 1414570
I've verified the 20171104220420 nightly (rev e7fee7042d971d73c0e5caafba3b8d15da1bc8ca) doesn't crash when opening the profile manager on Mac, and have re-enabled nightly updates.
There still are some crashes in nightlies starting with buildid 20171104220420 (see [1]).
The moz_crash_reason is always starting with "XBL compat hack matched, please file a bug blocking bug 1374247. Selector:".

[1] http://bit.ly/2AmG16a
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
user comments in those crashes mentioned by calixte say they were enabling the master password option in about:preferences
Let's open another bug for that one. I filed bug 1414786.
Status: REOPENED → RESOLVED
Closed: 2 years ago2 years ago
Resolution: --- → FIXED
Sounds like the main (blocking) crash was fixed.
You need to log in before you can comment on or make changes to this bug.