Closed
Bug 1414513
Opened 8 years ago
Closed 8 years ago
Crash in libmozglue.dylib@0x2164a - MOZ_CRASH Reason: XBL compat hack matched, please file a bug blocking bug 1374247.
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
RESOLVED
FIXED
mozilla58
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox56 | --- | unaffected |
firefox57 | --- | unaffected |
firefox58 | blocking | fixed |
People
(Reporter: Paenglab, Assigned: emilio)
References
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
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.
Updated•8 years ago
|
Flags: needinfo?(emilio)
Updated•8 years ago
|
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 | ||
Updated•8 years ago
|
Assignee: nobody → emilio
Flags: needinfo?(emilio)
Comment hidden (mozreview-request) |
Comment 3•8 years ago
|
||
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)
Comment 4•8 years ago
|
||
With the patch here, TB starts via the profile manager. So how did you get to the crash in comment #3?
Reporter | ||
Comment 5•8 years ago
|
||
(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)
Comment 6•8 years ago
|
||
(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.
Comment 7•8 years ago
|
||
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
Assignee | ||
Comment 8•8 years ago
|
||
(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
Reporter | ||
Comment 9•8 years ago
|
||
(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?
Assignee | ||
Comment 11•8 years ago
|
||
(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 12•8 years ago
|
||
mozreview-review |
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+
Assignee | ||
Comment 13•8 years ago
|
||
mozreview-review-reply |
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! :)
Comment 14•8 years ago
|
||
Pushed by ecoal95@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/7183dce1b218
Make the profile manager image selector a bit dumber. r=johannh
Crash Signature: [@ libmozglue.dylib@0x2164a] → [@ libmozglue.dylib@0x2164a]
[@ SelectorMatchesTree]
Comment 17•8 years ago
|
||
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: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
Also, should there be an automated test somewhere that ensures that the profile manager doesn't crash?
Comment 20•8 years ago
|
||
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
I filed bug 1414571 on the lack of tests.
![]() |
||
Comment 23•8 years ago
|
||
bugherder |
status-firefox58:
--- → fixed
tracking-firefox58:
--- → blocking
Comment 24•8 years ago
|
||
I've verified the 20171104220420 nightly (rev e7fee7042d971d73c0e5caafba3b8d15da1bc8ca) doesn't crash when opening the profile manager on Mac, and have re-enabled nightly updates.
Comment 25•8 years ago
|
||
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
Comment 26•8 years ago
|
||
user comments in those crashes mentioned by calixte say they were enabling the master password option in about:preferences
Assignee | ||
Comment 27•8 years ago
|
||
Let's open another bug for that one. I filed bug 1414786.
Assignee | ||
Updated•8 years ago
|
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → FIXED
Comment 28•8 years ago
|
||
Sounds like the main (blocking) crash was fixed.
Updated•8 years ago
|
status-firefox56:
--- → unaffected
status-firefox57:
--- → unaffected
status-firefox-esr52:
--- → unaffected
You need to log in
before you can comment on or make changes to this bug.
Description
•