Firefox crashes when loading youtube.com, others
I'm getting a tab crash any time any multimedia file goes fullscreen. It additionally crashes late in the page loading cycle (after some elements have already rendered) on most youtube pages, even if the media is not set to play. I have attempted using safe mode and incognito mode but that has not helped.
This is Firefox 58.0.2 running on Mac OS 10.13.2 (17C205) logged in as an admin user. Hardware is a Mid-2014 13" Macbook pro. There is plenty of free disk (SSD) space and RAM.
Firefox 58.0.2 Crash Report [@ IPCError-browser | IndexedDB CheckPermission 1 ] https://crash-stats.mozilla.com/report/index/cf11c0d6-938e-48ba-82c4-038210180221
I'd prefer to not wipe Firefox's Application support subdirectory as I have significant state in the URL bar autocomplete, saved passwords, bookmarks, and such that I'd like to continue without having to restore.
I have additional crash reports (many per day) that give me a throttling error, as I guess the crashlog servers are busy right now. 5517E997-D5BC-40BB-85BC-0FCF1119EE6D 2/20/18 2:57 PM 5C7E6DC1-C380-4CBF-929A-0817BE14B58D 2/18/18 2:08 PM 3A0A3B69-2B23-4E80-A925-6AD4C649E47F 2/18/18 2:06 PM 611F6896-3A8F-458A-95A4-B98361E6335E 2/18/18 2:06 PM EB0E4565-B8E8-4010-8F5F-09044776B9C5 2/18/18 2:06 PM 56E3D820-75B1-484A-B74B-825C0B09E716 2/18/18 2:05 PM 501AA5D1-DB63-4FE1-BC04-A09B2B34411F 2/18/18 3:16 AM
The crash log appears to indicate something is wrong with either libxml2.2.dylib, or libarchive.2.dylib.
Both dylibs appear to be in good order, assuming you believe Apple's code signing tool.
$ ls -lh /usr/lib/libxml2.2.dylib -rwxr-xr-x 1 root wheel 2.2M Sep 20 21:35 /usr/lib/libxml2.2.dylib $ codesign -dv --verbose=4 /usr/lib/libxml2.2.dylib Executable=/usr/lib/libxml2.2.dylib Identifier=com.apple.libxml2 Format=Mach-O universal (i386 x86_64) CodeDirectory v=20100 size=9154 flags=0x0(none) hashes=282+2 location=embedded Platform identifier=4 OSPlatform=36 OSSDKVersion=658688 OSVersionMin=658688 Hash type=sha256 size=32 CandidateCDHash sha256=96edeefd12184de750d095d285fd2cbe9e3b2bb4 Hash choices=sha256 Page size=4096 CDHash=96edeefd12184de750d095d285fd2cbe9e3b2bb4 Signature size=4485 Authority=Software Signing Authority=Apple Code Signing Certification Authority Authority=Apple Root CA Info.plist=not bound TeamIdentifier=not set Sealed Resources=none Internal requirements count=1 size=68
$ ls -lh /usr/lib/libarchive.2.dylib -rwxr-xr-x 1 root wheel 430K Sep 20 21:35 /usr/lib/libarchive.2.dylib $ codesign -dv --verbose=4 /usr/lib/libarchive.2.dylib Executable=/usr/lib/libarchive.2.dylib Identifier=libarchive.2 Format=Mach-O universal (i386 x86_64) CodeDirectory v=20100 size=1757 flags=0x0(none) hashes=51+2 location=embedded Platform identifier=4 OSPlatform=36 OSSDKVersion=658688 OSVersionMin=658688 Hash type=sha256 size=32 CandidateCDHash sha256=c980516948d5bf604b58b190c6647e0f01083788 Hash choices=sha256 Page size=4096 CDHash=c980516948d5bf604b58b190c6647e0f01083788 Signature size=4485 Authority=Software Signing Authority=Apple Code Signing Certification Authority Authority=Apple Root CA Info.plist=not bound TeamIdentifier=not set Sealed Resources=none Internal requirements count=1 size=60
Are there any known workarounds to this issue?
All Replies (10)
Bugzilla leads me to believe that I may have this issue? I don't see a good workaround listed there except for wiping out all browser state (by rm -rf .mozilla )
bp-cf11c0d6-938e-48ba-82c4-038210180221 Signature: IPCError-browser | IndexedDB CheckPermission 1
This is for Sumo's Related Bugs 1411253 RESOLVED DUPLICATE dom.indexedDB.enabled=false crashes content process
1320027 NEW --- Crash in IPCError-browser | IndexedDB CheckPermission 1
https://bugzilla.mozilla.org/show_bug.cgi?id=1320027#c7
ernbcaan said ( Comment 7 • a month ago)
I made a bug report which seems to match this error - Firefox about:config option for "dom.indexedDB.enabled" set to False.
However, sites (such as Youtube) are still creating the directory and some files for their sites.. I had to manually disallow write access to the site-data folder for Youtube, which fixed the crashes since now Firefox can't write ANYTHING to that folder.
I don't understand all this and called for more help.
Are you possibly running Firefox in permanent Private Browsing mode (Always use Private Browsing mode; Never Remember History) in case this makes a difference?
Start Firefox in Safe Mode to check if one of the extensions ("3-bar" menu button or Tools -> Add-ons -> Extensions) or if hardware acceleration is causing the problem.
- switch to the DEFAULT theme: "3-bar" menu button or Tools -> Add-ons -> Appearance
- do NOT click the "Refresh Firefox" button on the Safe Mode start window
Muudetud cor-el poolt
I'm not running permanent private browsing mode. I'll try the theme switch next.
I do have dom.indexedDB.enabled set to false in about:config. I seem to remember setting it this way to work around a bug in Firefox's handling of Microsoft's cloud storage html UI.
I've turned dom.indexedDB.enabled back to True and am able to load the pages and use full screen video. Changing this setting back to false causes the error to occur again.
I'll just have to remember to monkey the setting back and forth when using the cloud storage service. I guess I could use safari for the storage service...
This does not seem like a very good solution to me.
I don't see an ETA on the underlying bug. Is this something that is being looked into?
Update to add: I already tried Firefox's safe mode in the original post. It did not have any effect.
Theme change to default did not have an effect either.
It looks like the handling of dom.indexedDB.enabled=False is the culprit.
Do you have indexedDB disabled (dom.indexedDB.enabled = false)?
Our posts have probably crossed. My post a few minutes back indicated that I do indeed have indexedDB disabled.
Does this only happen with IndexedDB disabled and does it disappear when you toggle the pref to true and enable IDB?
Keep in mind that disabling specific features is always at your own risk, there is no guarantee that there won't be issues.
Yes, it only happens when the setting dom.indexedDB.enabled=False. Changing the setting to dom.indexedDB.enabled=True resolves this issue.
I had it set to false to work around an issue with Microsoft's storage cloud service not working in Firefox when dom.indexedDB.enabled is True.