Join the AMA (Ask Me Anything) with the Firefox leadership team to celebrate Firefox 20th anniversary and discuss Firefox’s future on Mozilla Connect. Mark your calendar on Thursday, November 14, 18:00 - 20:00 UTC!

Този сайт ще има ограничена функционалност, докато се извършва тече неговата поддръжка. Ако дадена статия не може реши проблема ви и искате да зададете въпрос, нашата общност е готова да ви помогне на @firefox в Twitter и /r/firefox в Reddit.

Търсене в помощните статии

Избягвайте измамите при поддръжката. Никога няма да ви помолим да се обадите или изпратите SMS на телефонен номер или да споделите лична информация. Моля, докладвайте подозрителна активност на "Докладване за злоупотреба".

Научете повече

Firefox crashes when loading youtube.com, others

  • 10 отговора
  • 1 има този проблем
  • 1 изглед
  • Последен отговор от unusedusername

more options

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?

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?

Всички отговори (10)

more options

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 )

https://bugzilla.mozilla.org/show_bug.cgi?id=1320027

more options

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.

more options

I don't understand all this and called for more help.

more options

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

Променено на от cor-el

more options

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?

more options

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.

more options

Do you have indexedDB disabled (dom.indexedDB.enabled = false)?

more options

Our posts have probably crossed. My post a few minutes back indicated that I do indeed have indexedDB disabled.

more options

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.

more options

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.