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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1914147 Title: Firefox hangs after upgrade to version 85 To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1914147/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
