Launchpad has imported 19 comments from the remote bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1679933.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2020-12-01T05:46:55+00:00 Tetsuharu-ohzeki wrote: ## Environment - macOS Big Sur 11.0.1 - I reproduced this bug on macOS Caralina 10.15.7 too. - https://hg.mozilla.org/mozilla-central/rev/b0865ea584621ce9e7f68833565e3d8ae117ce32 ## Steps to reproduce 1. Launch Firefox. 2. Try to open a new window from the context menu on the icon in Dock ## Actual Result - Firefox is not responsible with rainbow cursor. - Firefox does not comeback and I need to quit Firefox forcely. - I reproduce this bug a few days ago. - I does not face this bug rarely on a new profile Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1914147/comments/0 ------------------------------------------------------------------------ On 2020-12-01T23:19:03+00:00 Dtownsend wrote: (In reply to Tetsuharu OHZEKI [:tetsuharu] (UTC+9) from comment #0) > - Firefox is not responsible with rainbow cursor. > - Firefox does not comeback and I need to quit Firefox forcely. > - I reproduce this bug a few days ago. > - I does not face this bug rarely on a new profile Can you clarify whether this means you do not see this with a new profile? Do you know which Nightly this started happening with? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1914147/comments/1 ------------------------------------------------------------------------ On 2020-12-02T13:42:40+00:00 Tetsuharu-ohzeki wrote: > Can you clarify whether this means you do not see this with a new profile? Yes. I face this bug reraly on a new profile. > Do you know which Nightly this started happening with? Sorry, I don't remember the concrete date about which Nightly starts to happen...... I feel that I faced this bug frequently from 11/20 (Fri) ~ 23 (Mon). At least I seem at that time which U.S entered to thanksgiving holiday. --------- Additional Information are: * WIth [yeasterday's Nightly](https://hg.mozilla.org/mozilla-central/rev/abafe6c923eb566ffb94fd6afe0e06766d0c27a6), I have not faced this bug. But I'm not sure about that this bug has been fixed actually. This bug sometimes does not happen. I seem that the step to reproduce is depends on some timing issue. * My main profile enables fission.autostart=true. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1914147/comments/2 ------------------------------------------------------------------------ On 2020-12-04T16:05:52+00:00 Tetsuharu-ohzeki wrote: Created attachment 9191329 stack information This is an information which I got from the macOS' dialog to report the crash shown after force quit Firefox Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1914147/comments/3 ------------------------------------------------------------------------ On 2020-12-04T17:34:21+00:00 Dtownsend wrote: Based on the stack info it looks like maybe Firefox was stuck in a deadlock somewhere in the HTTP code so moving this over there for mre investigation. Is this still occurring? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1914147/comments/4 ------------------------------------------------------------------------ On 2020-12-04T17:56:32+00:00 Tetsuharu-ohzeki wrote: > Is this still occurring? Yes. I seem this was some changed from the before. On the before, this bug is reproducible on launching Firefox every time. But now, - I face this bug on launching Firefox first time after daily update, and it's not always happens. - I feel this bug happens if I open a context window on the dock and opening an window. - But the timing is a bit scatterd. - If this bug does not happen in 10 sec after launching Firefox, then I never face to this bug whilte using Firefox until close. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1914147/comments/5 ------------------------------------------------------------------------ On 2020-12-04T19:20:36+00:00 Dd-mozilla wrote: CacheIO Thread holds mRCWNLock and try to dispatch SyncRunnable on the main thread: 45 mozilla::net::nsHttpChannel::OnCacheEntryCheck(nsICacheEntry*, nsIApplicationCache*, unsigned int*) + 2485 (XUL + 7218629) [0x107e7d5c5] 1-45 45 mozilla::net::nsHttpChannel::OpenCacheInputStream(nsICacheEntry*, bool, bool) + 1539 (XUL + 7225683) [0x107e7f153] 1-45 45 mozilla::net::CacheEntry::GetSecurityInfo(nsISupports**) + 197 (XUL + 41189653) [0x109ee3115] 1-45 45 NS_DeserializeObject(nsTSubstring<char> const&, nsISupports**) + 131 (XUL + 6224003) [0x107d8a883] 1-45 45 nsBinaryInputStream::ReadObject(bool, nsISupports**) + 274 (XUL + 5336850) [0x107cb1f12] 1-45 45 nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper const&, nsID const&) + 44 (XUL + 5114444) [0x107c7ba4c] 1-45 45 nsCreateInstanceByCID::operator()(nsID const&, void**) const + 42 (XUL + 5481626) [0x107cd549a] 1-45 45 nsComponentManagerImpl::CreateInstance(nsID const&, nsISupports*, nsID const&, void**) + 183 (XUL + 5470679) [0x107cd29d7] 1-45 45 nsresult mozilla::psm::NSSConstructor<mozilla::psm::TransportSecurityInfo>(nsISupports*, nsID const&, void**) + 56 (XUL + 84060120) [0x10c7c57d8] 1-45 45 EnsureNSSInitializedChromeOrContent() + 583 (XUL + 21727959) [0x108c53ad7] 1-45 45 mozilla::SyncRunnable::DispatchToThread(nsIEventTarget*, bool) + 156 (XUL + 5904060) [0x107d3c6bc] 1-45 The main Thread is waiting on the mRCWNLock. Kershaw, do I recall correctly that we have this SyncRunnable only because of some test? EnsureNSSInitializedChromeOrContent should always be called on the main thread. Dana, do you know whatt has change recently Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1914147/comments/6 ------------------------------------------------------------------------ On 2020-12-04T19:44:48+00:00 Kershaw-6 wrote: (In reply to Dragana Damjanovic [:dragana] from comment #6) > CacheIO Thread holds mRCWNLock and try to dispatch SyncRunnable on the main > thread: > 45 > mozilla::net::nsHttpChannel::OnCacheEntryCheck(nsICacheEntry*, > nsIApplicationCache*, unsigned int*) + 2485 (XUL + 7218629) [0x107e7d5c5] 1-45 > 45 > mozilla::net::nsHttpChannel::OpenCacheInputStream(nsICacheEntry*, bool, bool) > + 1539 (XUL + 7225683) [0x107e7f153] 1-45 > 45 > mozilla::net::CacheEntry::GetSecurityInfo(nsISupports**) + 197 (XUL + > 41189653) [0x109ee3115] 1-45 > 45 > NS_DeserializeObject(nsTSubstring<char> const&, nsISupports**) + 131 (XUL + > 6224003) [0x107d8a883] 1-45 > 45 > nsBinaryInputStream::ReadObject(bool, nsISupports**) + 274 (XUL + 5336850) > [0x107cb1f12] 1-45 > 45 > nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper const&, nsID const&) + 44 > (XUL + 5114444) [0x107c7ba4c] 1-45 > 45 > nsCreateInstanceByCID::operator()(nsID const&, void**) const + 42 (XUL + > 5481626) [0x107cd549a] 1-45 > 45 > nsComponentManagerImpl::CreateInstance(nsID const&, nsISupports*, nsID > const&, void**) + 183 (XUL + 5470679) [0x107cd29d7] 1-45 > 45 nsresult > mozilla::psm::NSSConstructor<mozilla::psm::TransportSecurityInfo>(nsISupports*, > nsID const&, void**) + 56 (XUL + 84060120) [0x10c7c57d8] 1-45 > 45 > EnsureNSSInitializedChromeOrContent() + 583 (XUL + 21727959) [0x108c53ad7] > 1-45 > 45 > mozilla::SyncRunnable::DispatchToThread(nsIEventTarget*, bool) + 156 (XUL + > 5904060) [0x107d3c6bc] 1-45 > > The main Thread is waiting on the mRCWNLock. > > Kershaw, do I recall correctly that we have this SyncRunnable only because of > some test? EnsureNSSInitializedChromeOrContent should always be called on the > main thread. > No, I think this is a different problem and this bug could be regressed by bug 1634065. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1914147/comments/7 ------------------------------------------------------------------------ On 2020-12-04T21:00:59+00:00 Dkeeler wrote: I'm not sure bug 1634065 would have changed this one way or another. It seems like we have a preexisting issue where if `EnsureNSSInitializedChromeOrContent()` has never been called, it could think it needs to dispatch to the main thread, even if NSS has already been initialized (which causes a problem if the currently running code is holding a lock that the main thread is waiting on). My guess is if we replaced ` nsCOMPtr<nsISupports> psm = do_GetService(PSM_COMPONENT_CONTRACTID, &rv);` with `EnsureNSSInitializedChromeOrContent()` at [0], this wouldn't happen. [0] https://searchfox.org/mozilla- central/rev/6bb59b783b193f06d6744c5ccaac69a992e9ee7b/netwerk/base/nsNetUtil.cpp#2718 Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1914147/comments/8 ------------------------------------------------------------------------ On 2021-01-08T11:01:02+00:00 Kershaw-6 wrote: *** Bug 1684966 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1914147/comments/9 ------------------------------------------------------------------------ On 2021-01-08T11:02:02+00:00 Kershaw-6 wrote: ni myself to take a look. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1914147/comments/10 ------------------------------------------------------------------------ On 2021-01-14T16:33:36+00:00 Kershaw-6 wrote: I agree with Dana. Calling `EnsureNSSInitializedChromeOrContent()` in `net_EnsurePSMInit` seems to be the best way to fix this. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1914147/comments/11 ------------------------------------------------------------------------ On 2021-01-14T16:33:55+00:00 Kershaw-6 wrote: Created attachment 9197123 Bug 1679933 - Call EnsureNSSInitializedChromeOrContent() during nsHttpHandler initialization Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1914147/comments/12 ------------------------------------------------------------------------ On 2021-01-15T11:18:46+00:00 Pulsebot wrote: Pushed by kj...@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5f0a8b3326e7 Call EnsureNSSInitializedChromeOrContent() during nsHttpHandler initialization r=necko-reviewers,dragana Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1914147/comments/13 ------------------------------------------------------------------------ On 2021-01-15T13:22:01+00:00 Kershaw-6 wrote: Could you try to use this [build](https://firefox-ci- tc.services.mozilla.com/api/queue/v1/task/Vz--6YI-TTmIs- l0Tvulvw/runs/0/artifacts/public/build/target.dmg) to verify if this issue is fixed? Thanks. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1914147/comments/14 ------------------------------------------------------------------------ On 2021-01-15T14:07:46+00:00 Apavel-2 wrote: https://hg.mozilla.org/mozilla-central/rev/5f0a8b3326e7 Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1914147/comments/15 ------------------------------------------------------------------------ On 2021-01-15T14:58:17+00:00 Tetsuharu-ohzeki wrote: (In reply to Kershaw Chang [:kershaw] from comment #14) > Could you try to use this > [build](https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Vz--6YI-TTmIs-l0Tvulvw/runs/0/artifacts/public/build/target.dmg) > to verify if this issue is fixed? Thank you for your effort! I seem this build would fix this bug. But I cannot be confident to confirm this bug has been fixed by your patch because this bug is most reproducible on updating Firefox (In other words, it's hard to reproduce this bug on the timing which is not on updating in recent build) .... I'll try to check it again in the next nightly build which will come in the next morning of UTC+9. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1914147/comments/16 ------------------------------------------------------------------------ On 2021-01-16T13:13:05+00:00 Tetsuharu-ohzeki wrote: (In reply to Tetsuharu OHZEKI [:tetsuharu] (UTC+9) from comment #16) > I'll try to check it again in the next nightly build which will come in the > next morning of UTC+9. I think this has been fixed. Thanks! Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1914147/comments/17 ------------------------------------------------------------------------ On 2021-01-26T21:20:58+00:00 Stransky wrote: I do see that but on Linux too, Fedora 33 / Firefox 85. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1914147/comments/18 ** Changed in: firefox Status: Unknown => Fix Released -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1914147 Title: Firefox hangs after upgrade to version 85 Status in Mozilla Firefox: Fix Released Status in firefox package in Ubuntu: Incomplete Bug description: Today I have received a security upgrade for kubuntu 20.04 including firefox 85. Unfortunately, this version of firefox appears to hang at start unless it is started passing an url. Namely: firefox hangs, while firefox lwn.net does not hang. I have quickly tried working with a clean profile and firefox 85 seems to start fine with that. Yet, the profile is not broken: if I downgrade to firefox 84 and restore my profile from a backup, then firefox 84 works just fine. So the issue seems to be that firefox 85 has issues in working with profiles that are totally fine with firefox 84. This breaks migration from firefox 84 to firefox 85. Issue is totally reproducible: downgrade to firefox 84 restore profile from firefox 84 from backup work with firefox 84 (OK) upgrade to firefox 85 try to work with firefox 85 (KO) Please consider that having to reset a profile is a form of data loss. In a modern browser, the profile includes extensions, passwords, data from web apps and more. Because this bug makes it impossible to apply a security update (firefox 85 is marked as such and shipped via the security channel), this bug is particularly serious. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: firefox 84.0.2+build1-0ubuntu0.20.04.1 ProcVersionSignature: Ubuntu 5.8.0-41.46~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-41-generic x86_64 AddonCompatCheckDisabled: False ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: callegar 1454 F.... pulseaudio BuildID: 20210105180113 CasperMD5CheckResult: skip Channel: Unavailable CurrentDesktop: KDE Date: Tue Feb 2 00:52:23 2021 EcryptfsInUse: Yes Extensions: extensions.sqlite corrupt or missing ForcedLayersAccel: False IncompatibleExtensions: Unavailable (corrupt or non-existant compatibility.ini or extensions.sqlite) InstallationDate: Installed on 2020-02-16 (351 days ago) InstallationMedia: Kubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) IpRoute: default via 192.168.10.1 dev wlan0 proto dhcp metric 600 169.254.0.0/16 dev wlan0 scope link metric 1000 192.168.10.0/24 dev wlan0 proto kernel scope link src 192.168.10.116 metric 600 Locales: extensions.sqlite corrupt or missing PrefErrors: Unexpected character ',' before close parenthesis @ /usr/lib/firefox/omni.ja:greprefs.js:354 PrefSources: prefs.js Profiles: Profile0 (Default) - LastVersion=84.0.2/20210105180113 RunningIncompatibleAddons: False SourcePackage: firefox Themes: extensions.sqlite corrupt or missing UpgradeStatus: Upgraded to focal on 2020-05-23 (254 days ago) dmi.bios.date: 10/02/2019 dmi.bios.release: 7.4 dmi.bios.vendor: INSYDE Corp. dmi.bios.version: 1.07.04RTR1 dmi.board.asset.tag: Tag 12345 dmi.board.name: N141CU dmi.board.vendor: SCHENKER dmi.board.version: Not Applicable dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: Notebook dmi.chassis.version: N/A dmi.ec.firmware.release: 7.2 dmi.modalias: dmi:bvnINSYDECorp.:bvr1.07.04RTR1:bd10/02/2019:br7.4:efr7.2:svnSCHENKER:pnSCHENKER_SLIM14_SSL14L19:pvrNotApplicable:rvnSCHENKER:rnN141CU:rvrNotApplicable:cvnNotebook:ct10:cvrN/A: dmi.product.family: Not Applicable dmi.product.name: SCHENKER_SLIM14_SSL14L19 dmi.product.sku: Not Applicable dmi.product.version: Not Applicable dmi.sys.vendor: SCHENKER To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1914147/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
