X
Tap here to go to the mobile version of the site.

Support Forum

"Firefox is already running, but not responding" error

Posted

Hello. I have been using Firefox off-and-on since the version 2.0, and there has been one bug that is plaguing me since 10+ years, and that is this error message that occurs when I close down Firefox and try to immediately reopen it (sometimes I wait 2-3 seconds just to avoid this error to no avail).

I am using version 65.0.2 (x64) now on latest Windows 10 version (on an MSI laptop with a spec of Intel i7 8750H cpu, Kingston SSD, 16 gb dual channel RAM and Nvidia RTX 2070 graphics card) and have been encountering this bug daily, and it really became so annoying that I'm considering reverting back to Chrome (which NEVER had this bug). This problem usually occurs when my previous Firefox session had more than 4 or so tabs, etc. but it also occurs when I just try to close and reopen the Firefox to test if the bug persists and 1 out of 5 times I get this bug and have to wait around 10 seconds for Firefox to realize there is a leftover session and offer me to close it before being able to open a new tab/window.

I have tried removing the .lock file from the profile folder (which DOES NOT remove itself when I end my session and gets recreated each time I restart a session), checking off the read-only mark from the profile folder, creating another profile and disabling hardware accelerating; but none of these made the slightest impact on the frequency I experience this problem. This thread from official Mozilla support also didn't help (https://support.mozilla.org/en-US/kb/firefox-already-running-not-responding ).

Should I just accept that this is the way Firefox works and that I need to wait 5-6 sec or so before attempting to reopen Firefox (as suggested here https://www.howtogeek.com/131004/how-to-fix-the-firefox-is-already-running-error/ (which dates back to 2012 and saddens me deeply that 7 more years of development changed nothing on this front)), or shut the Firefox down each time by killing it from the Task Manager; or could there maybe a fix to this? I had recently ditched Chrome since it froze my computer (a very rare bug related to the newer Windows 10 versions which occured only once to me, but felt serious enough that I uninstalled it), but if I can't find a reliable fix to this problem, I will probably just go back to Chrome where the bugs won't affect my daily usage.

Thank you for your help.

Hello. I have been using Firefox off-and-on since the version 2.0, and there has been one bug that is plaguing me since 10+ years, and that is this error message that occurs when I close down Firefox and try to immediately reopen it (sometimes I wait 2-3 seconds just to avoid this error to no avail). I am using version 65.0.2 (x64) now on latest Windows 10 version (on an MSI laptop with a spec of Intel i7 8750H cpu, Kingston SSD, 16 gb dual channel RAM and Nvidia RTX 2070 graphics card) and have been encountering this bug daily, and it really became so annoying that I'm considering reverting back to Chrome (which NEVER had this bug). This problem usually occurs when my previous Firefox session had more than 4 or so tabs, etc. but it also occurs when I just try to close and reopen the Firefox to test if the bug persists and 1 out of 5 times I get this bug and have to wait around 10 seconds for Firefox to realize there is a leftover session and offer me to close it before being able to open a new tab/window. I have tried removing the .lock file from the profile folder (which DOES NOT remove itself when I end my session and gets recreated each time I restart a session), checking off the read-only mark from the profile folder, creating another profile and disabling hardware accelerating; but none of these made the slightest impact on the frequency I experience this problem. This thread from official Mozilla support also didn't help (https://support.mozilla.org/en-US/kb/firefox-already-running-not-responding ). Should I just accept that this is the way Firefox works and that I need to wait 5-6 sec or so before attempting to reopen Firefox (as suggested here https://www.howtogeek.com/131004/how-to-fix-the-firefox-is-already-running-error/ (which dates back to 2012 and saddens me deeply that 7 more years of development changed nothing on this front)), or shut the Firefox down each time by killing it from the Task Manager; or could there maybe a fix to this? I had recently ditched Chrome since it froze my computer (a very rare bug related to the newer Windows 10 versions which occured only once to me, but felt serious enough that I uninstalled it), but if I can't find a reliable fix to this problem, I will probably just go back to Chrome where the bugs won't affect my daily usage. Thank you for your help.

Modified by Unbeknownst

Quote

Additional System Details

Application

  • Firefox 65.0.2
  • User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0
  • Support URL: https://support.mozilla.org/1/firefox/65.0.2/WINNT/tr/

Extensions

  • Decentraleyes 2.0.10 (jid1-BoFifL9Vbdl2zQ@jetpack)
  • Grammarly for Firefox 8.845.2049 (87677a2c52b84ad3a151a4a72f5bd3c4@jetpack)
  • IDM Integration Module 6.32.6 (mozilla_cc3@internetdownloadmanager.com)
  • LastPass: Free Password Manager 4.25.0.4 (support@lastpass.com)
  • uBlock Origin 1.18.6 (uBlock0@raymondhill.net)

Javascript

  • incrementalGCEnabled: True

Graphics

  • adapterDescription: Intel(R) UHD Graphics 630
  • adapterDescription2: NVIDIA GeForce RTX 2070
  • adapterDeviceID: 0x3e9b
  • adapterDeviceID2: 0x1f10
  • adapterDrivers: igdumdim64 igd10iumd64 igd10iumd64 igd12umd64 igdumdim32 igd10iumd32 igd10iumd32 igd12umd32
  • adapterDrivers2: C:\Windows\System32\DriverStore\FileRepository\nvmii.inf_amd64_06cd8d7e8fa82147\nvldumdx.dll,C:\Windows\System32\DriverStore\FileRepository\nvmii.inf_amd64_06cd8d7e8fa82147\nvldumdx.dll,C:\Windows\System32\DriverStore\FileRepository\nvmii.inf_amd64_06cd8d7e8fa82147\nvldumdx.dll,C:\Windows\System32\DriverStore\FileRepository\nvmii.inf_amd64_06cd8d7e8fa82147\nvldumdx.dll C:\Windows\System32\DriverStore\FileRepository\nvmii.inf_amd64_06cd8d7e8fa82147\nvldumd.dll,C:\Windows\System32\DriverStore\FileRepository\nvmii.inf_amd64_06cd8d7e8fa82147\nvldumd.dll,C:\Windows\System32\DriverStore\FileRepository\nvmii.inf_amd64_06cd8d7e8fa82147\nvldumd.dll,C:\Windows\System32\DriverStore\FileRepository\nvmii.inf_amd64_06cd8d7e8fa82147\nvldumd.dll
  • adapterRAM: Unknown
  • adapterRAM2: 8192
  • adapterSubsysID: 126a1462
  • adapterSubsysID2: 126a1462
  • adapterVendorID: 0x8086
  • adapterVendorID2: 0x10de
  • contentUsesTiling: True
  • crashGuards: []
  • direct2DEnabled: False
  • direct2DEnabledMessage: [u'']
  • directWriteEnabled: True
  • directWriteVersion: 10.0.17763.168
  • driverDate: 2-7-2019
  • driverDate2: 3-1-2019
  • driverVersion: 25.20.100.6577
  • driverVersion2: 25.21.14.1935
  • featureLog: {u'fallbacks': [], u'features': [{u'status': u'disabled', u'log': [{u'status': u'available', u'type': u'default'}, {u'status': u'disabled', u'message': u'Disabled by pref', u'type': u'user'}], u'name': u'HW_COMPOSITING', u'description': u'Compositing'}, {u'status': u'unavailable', u'log': [{u'status': u'unavailable', u'message': u'Hardware compositing is disabled', u'type': u'default'}], u'name': u'D3D11_COMPOSITING', u'description': u'Direct3D11 Compositing'}, {u'status': u'unavailable', u'log': [{u'status': u'unavailable', u'message': u'Direct2D requires Direct3D 11 compositing', u'type': u'default'}], u'name': u'DIRECT2D', u'description': u'Direct2D'}, {u'status': u'disabled', u'log': [{u'status': u'unavailable', u'message': u'D3D11 compositing is disabled', u'type': u'default'}, {u'status': u'disabled', u'message': u'D3D11 compositing is disabled', u'type': u'env'}], u'name': u'D3D11_HW_ANGLE', u'description': u'Direct3D11 hardware ANGLE'}, {u'status': u'available', u'log': [{u'status': u'available', u'type': u'default'}], u'name': u'GPU_PROCESS', u'description': u'GPU Process'}, {u'status': u'unavailable', u'log': [{u'status': u'opt-in', u'message': u'WebRender is an opt-in feature', u'type': u'default'}, {u'status': u'unavailable', u'message': u'ANGLE is disabled', u'type': u'runtime'}], u'name': u'WEBRENDER', u'description': u'WebRender'}, {u'status': u'blocked', u'log': [{u'status': u'available', u'type': u'default'}, {u'status': u'blocked', u'message': u'Has battery', u'type': u'env'}], u'name': u'WEBRENDER_QUALIFIED', u'description': u'WebRender qualified'}, {u'status': u'available', u'log': [{u'status': u'available', u'type': u'default'}], u'name': u'OMTP', u'description': u'Off Main Thread Painting'}]}
  • info: {u'AzureContentBackend (UI Process)': u'skia', u'AzureCanvasBackend (UI Process)': u'skia', u'ApzWheelInput': 1, u'ApzDragInput': 1, u'ApzKeyboardInput': 1, u'AzureFallbackCanvasBackend (UI Process)': u'cairo', u'ApzAutoscrollInput': 1, u'AzureCanvasAccelerated': 0, u'AzureCanvasBackend': u'skia', u'AzureContentBackend': u'skia'}
  • isGPU2Active: False
  • numAcceleratedWindows: 0
  • numAcceleratedWindowsMessage: [u'']
  • numTotalWindows: 1
  • offMainThreadPaintEnabled: True
  • offMainThreadPaintWorkerCount: 4
  • usesTiling: False
  • webgl1DriverExtensions: GL_ANGLE_client_arrays GL_ANGLE_depth_texture GL_ANGLE_explicit_context GL_ANGLE_explicit_context_gles1 GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_lossy_etc_decode GL_ANGLE_pack_reverse_row_order GL_ANGLE_program_cache_control GL_ANGLE_request_extension GL_ANGLE_robust_client_memory GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_CHROMIUM_bind_generates_resource GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_color_buffer_float_rgb GL_CHROMIUM_color_buffer_float_rgba GL_CHROMIUM_copy_compressed_texture GL_CHROMIUM_copy_texture GL_CHROMIUM_sync_query GL_EXT_blend_minmax GL_EXT_color_buffer_half_float GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers GL_EXT_frag_depth GL_EXT_map_buffer_range GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_sRGB GL_EXT_shader_texture_lod GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc_srgb GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_EXT_texture_storage GL_EXT_unpack_subimage GL_KHR_debug GL_KHR_parallel_shader_compile GL_KHR_robust_buffer_access_behavior GL_NV_EGL_stream_consumer_external GL_NV_fence GL_NV_pack_subimage GL_NV_pixel_buffer_object GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth32 GL_OES_element_index_uint GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_surfaceless_context GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_array_object OES_compressed_EAC_R11_signed_texture OES_compressed_EAC_R11_unsigned_texture OES_compressed_EAC_RG11_signed_texture OES_compressed_EAC_RG11_unsigned_texture OES_compressed_ETC2_RGB8_texture OES_compressed_ETC2_RGBA8_texture OES_compressed_ETC2_punchthroughA_RGBA8_texture OES_compressed_ETC2_punchthroughA_sRGB8_alpha_texture OES_compressed_ETC2_sRGB8_alpha8_texture OES_compressed_ETC2_sRGB8_texture
  • webgl1Extensions: ANGLE_instanced_arrays EXT_blend_minmax EXT_color_buffer_half_float EXT_frag_depth EXT_sRGB EXT_shader_texture_lod EXT_texture_filter_anisotropic EXT_disjoint_timer_query OES_element_index_uint OES_standard_derivatives OES_texture_float OES_texture_float_linear OES_texture_half_float OES_texture_half_float_linear OES_vertex_array_object WEBGL_color_buffer_float WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_depth_texture WEBGL_draw_buffers WEBGL_lose_context
  • webgl1Renderer: Google Inc. -- ANGLE (Intel(R) UHD Graphics 630 Direct3D11 vs_5_0 ps_5_0)
  • webgl1Version: OpenGL ES 2.0 (ANGLE 2.1.0.790e8e6b4179)
  • webgl1WSIInfo: EGL_VENDOR: Google Inc. (adapter LUID: 0000000000015e70) EGL_VERSION: 1.4 (ANGLE 2.1.0.790e8e6b4179) EGL_EXTENSIONS: EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_d3d_texture_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size EGL_ANGLE_keyed_mutex EGL_ANGLE_surface_orientation EGL_ANGLE_direct_composition EGL_NV_post_sub_buffer EGL_KHR_create_context EGL_EXT_device_query EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_get_all_proc_addresses EGL_KHR_stream EGL_KHR_stream_consumer_gltexture EGL_NV_stream_consumer_gltexture_yuv EGL_ANGLE_flexible_surface_compatibility EGL_ANGLE_stream_producer_d3d_texture EGL_ANGLE_create_context_webgl_compatibility EGL_CHROMIUM_create_context_bind_generates_resource EGL_CHROMIUM_sync_control EGL_EXT_pixel_format_float EGL_KHR_surfaceless_context EGL_ANGLE_display_texture_share_group EGL_ANGLE_create_context_client_arrays EGL_ANGLE_program_cache_control EGL_ANGLE_robust_resource_initialization EGL_ANGLE_create_context_extensions_enabled EGL_MOZ_create_context_provoking_vertex_dont_care EGL_EXTENSIONS(nullptr): EGL_EXT_client_extensions EGL_EXT_platform_base EGL_EXT_platform_device EGL_ANGLE_platform_angle EGL_ANGLE_platform_angle_d3d EGL_ANGLE_device_creation EGL_ANGLE_device_creation_d3d11 EGL_ANGLE_experimental_present_path EGL_KHR_client_get_all_proc_addresses EGL_KHR_debug EGL_ANGLE_explicit_context
  • webgl2DriverExtensions: GL_ANGLE_client_arrays GL_ANGLE_depth_texture GL_ANGLE_explicit_context GL_ANGLE_explicit_context_gles1 GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_lossy_etc_decode GL_ANGLE_multiview GL_ANGLE_pack_reverse_row_order GL_ANGLE_program_cache_control GL_ANGLE_request_extension GL_ANGLE_robust_client_memory GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_CHROMIUM_bind_generates_resource GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_color_buffer_float_rgb GL_CHROMIUM_color_buffer_float_rgba GL_CHROMIUM_copy_compressed_texture GL_CHROMIUM_copy_texture GL_CHROMIUM_sync_query GL_EXT_blend_minmax GL_EXT_color_buffer_float GL_EXT_color_buffer_half_float GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers GL_EXT_frag_depth GL_EXT_map_buffer_range GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_sRGB GL_EXT_shader_texture_lod GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc_srgb GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_norm16 GL_EXT_texture_rg GL_EXT_texture_storage GL_EXT_unpack_subimage GL_KHR_debug GL_KHR_parallel_shader_compile GL_KHR_robust_buffer_access_behavior GL_NV_EGL_stream_consumer_external GL_NV_fence GL_NV_pack_subimage GL_NV_pixel_buffer_object GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_EGL_image_external_essl3 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth32 GL_OES_element_index_uint GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_surfaceless_context GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_array_object OES_compressed_EAC_R11_signed_texture OES_compressed_EAC_R11_unsigned_texture OES_compressed_EAC_RG11_signed_texture OES_compressed_EAC_RG11_unsigned_texture OES_compressed_ETC2_RGB8_texture OES_compressed_ETC2_RGBA8_texture OES_compressed_ETC2_punchthroughA_RGBA8_texture OES_compressed_ETC2_punchthroughA_sRGB8_alpha_texture OES_compressed_ETC2_sRGB8_alpha8_texture OES_compressed_ETC2_sRGB8_texture
  • webgl2Extensions: EXT_color_buffer_float EXT_texture_filter_anisotropic EXT_disjoint_timer_query OES_texture_float_linear WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_lose_context
  • webgl2Renderer: Google Inc. -- ANGLE (Intel(R) UHD Graphics 630 Direct3D11 vs_5_0 ps_5_0)
  • webgl2Version: OpenGL ES 3.0 (ANGLE 2.1.0.790e8e6b4179)
  • webgl2WSIInfo: EGL_VENDOR: Google Inc. (adapter LUID: 0000000000015e70) EGL_VERSION: 1.4 (ANGLE 2.1.0.790e8e6b4179) EGL_EXTENSIONS: EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_d3d_texture_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size EGL_ANGLE_keyed_mutex EGL_ANGLE_surface_orientation EGL_ANGLE_direct_composition EGL_NV_post_sub_buffer EGL_KHR_create_context EGL_EXT_device_query EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_get_all_proc_addresses EGL_KHR_stream EGL_KHR_stream_consumer_gltexture EGL_NV_stream_consumer_gltexture_yuv EGL_ANGLE_flexible_surface_compatibility EGL_ANGLE_stream_producer_d3d_texture EGL_ANGLE_create_context_webgl_compatibility EGL_CHROMIUM_create_context_bind_generates_resource EGL_CHROMIUM_sync_control EGL_EXT_pixel_format_float EGL_KHR_surfaceless_context EGL_ANGLE_display_texture_share_group EGL_ANGLE_create_context_client_arrays EGL_ANGLE_program_cache_control EGL_ANGLE_robust_resource_initialization EGL_ANGLE_create_context_extensions_enabled EGL_MOZ_create_context_provoking_vertex_dont_care EGL_EXTENSIONS(nullptr): EGL_EXT_client_extensions EGL_EXT_platform_base EGL_EXT_platform_device EGL_ANGLE_platform_angle EGL_ANGLE_platform_angle_d3d EGL_ANGLE_device_creation EGL_ANGLE_device_creation_d3d11 EGL_ANGLE_experimental_present_path EGL_KHR_client_get_all_proc_addresses EGL_KHR_debug EGL_ANGLE_explicit_context
  • windowLayerManagerRemote: True
  • windowLayerManagerType: Basic
  • windowUsingAdvancedLayers: False

Modified Preferences

Misc

  • User JS: No
  • Accessibility: No
FredMcD
  • Top 10 Contributor
4146 solutions 57871 answers

Unbeknownst said

when I close down Firefox and try to immediately reopen it

You should give the browser, in fact any program, time to finish closing. Wait about 10 seconds.

''Unbeknownst [[#question-1253308|said]]'' <blockquote> when I close down Firefox and try to immediately reopen it </blockquote> You should give the browser, in fact any program, time to finish closing. Wait about 10 seconds.
Was this helpful to you? 0
Quote

Question owner

FredMcD said

Unbeknownst said
when I close down Firefox and try to immediately reopen it

You should give the browser, in fact any program, time to finish closing. Wait about 10 seconds.

Well d'oh! I had mentioned I also tried waiting 2-3 seconds to allow it to close down to no avail. I wonder, why of all programs Firefox is the only one with this issue, and when we compare it to Chrome which not only loads blazingly fast, but you can also close and reopen it with miliseconds apart without having any halt, pause or issue whatsoever (and to think Chrome is much more of a RAM and CPU hog(!)).

Thank you for reading this and providing your insight, but it doesn't say anything new to me as I had already linked a link from 2012 to a website recommending to be patient.

''FredMcD [[#answer-1205559|said]]'' <blockquote> ''Unbeknownst [[#question-1253308|said]]'' <blockquote> when I close down Firefox and try to immediately reopen it </blockquote> You should give the browser, in fact any program, time to finish closing. Wait about 10 seconds. </blockquote> Well d'oh! I had mentioned I also tried waiting 2-3 seconds to allow it to close down to no avail. I wonder, why of all programs Firefox is the only one with this issue, and when we compare it to Chrome which not only loads blazingly fast, but you can also close and reopen it with miliseconds apart without having any halt, pause or issue whatsoever (and to think Chrome is much more of a RAM and CPU hog(!)). Thank you for reading this and providing your insight, but it doesn't say anything new to me as I had already linked a link from 2012 to a website recommending to be patient.

Modified by Unbeknownst

Was this helpful to you?
Quote
FredMcD
  • Top 10 Contributor
4146 solutions 57871 answers

Unbeknownst said

Well d'oh! I had mentioned I also tried waiting 2-3 seconds to allow it to close

FredMcD said

10 seconds.
''Unbeknownst [[#answer-1205573|said]]'' <blockquote> Well d'oh! I had mentioned I also tried waiting 2-3 seconds to allow it to close </blockquote> ''FredMcD [[#answer-1205559|said]]'' <blockquote>10 seconds. </blockquote>
Was this helpful to you? 0
Quote

Question owner

FredMcD said

Unbeknownst said
Well d'oh! I had mentioned I also tried waiting 2-3 seconds to allow it to close

FredMcD said

10 seconds.

I don't appreciate you taking the parts you see fit from what I've written to "seemingly" answer my question. It would be much better if you just wouldn't reply so that I can move forward a constructive discussion.

And by the way, I already mentioned that this doesn't happen each time I relaunch Firefox, but only happens in 1 in 3 to 1 in 5 times, so how can this not be a bug when its occurance is completely random (not depending on the number of closed tabs, etc.)? And can you also elaborate on all programs needing 10 seconds of time to finish closing? I have never encountered one except Firefox, and Chrome seems to work perfectly fine even if you close 250 tabs and relaunch it within the same second.

I must say though, I am appalled to see how such a person who ranks amongst the top 10 contributors be so manipulative and have bossy manners that contribute to no fruitful discussion.

Then again, thanks for taking your time on my issues.

''FredMcD [[#answer-1205592|said]]'' <blockquote> ''Unbeknownst [[#answer-1205573|said]]'' <blockquote> Well d'oh! I had mentioned I also tried waiting 2-3 seconds to allow it to close </blockquote> ''FredMcD [[#answer-1205559|said]]'' <blockquote>10 seconds. </blockquote> </blockquote> I don't appreciate you taking the parts you see fit from what I've written to "seemingly" answer my question. It would be much better if you just wouldn't reply so that I can move forward a constructive discussion. And by the way, I already mentioned that this doesn't happen each time I relaunch Firefox, but only happens in 1 in 3 to 1 in 5 times, so how can this not be a bug when its occurance is completely random (not depending on the number of closed tabs, etc.)? And can you also elaborate on all programs needing 10 seconds of time to finish closing? I have never encountered one except Firefox, and Chrome seems to work perfectly fine even if you close 250 tabs and relaunch it within the same second. I must say though, I am appalled to see how such a person who ranks amongst the top 10 contributors be so manipulative and have bossy manners that contribute to no fruitful discussion. Then again, thanks for taking your time on my issues.

Modified by Unbeknownst

Was this helpful to you?
Quote
FredMcD
  • Top 10 Contributor
4146 solutions 57871 answers

I am not being manipulative. I am giving you facts. Many complicated programs run sub-programs. Those need to be shut down before the main can shut itself down. Thus, 10 seconds.

As you don't want my advice, goodbye.

Hailing Frequencies Closed.

I am not being manipulative. I am giving you facts. Many complicated programs run sub-programs. Those need to be shut down before the main can shut itself down. Thus, 10 seconds. As you don't want my advice, goodbye. Hailing Frequencies Closed.
Was this helpful to you? 0
Quote
the-edmeister
  • Top 25 Contributor
  • Moderator
5387 solutions 39986 answers

Helpful Reply

Unbeknownst said

... Should I just accept that this is the way Firefox works and that I need to wait 5-6 sec or so before attempting to reopen Firefox (as suggested here https://www.howtogeek.com/131004/how-to-fix-the-firefox-is-already-running-error/ (which dates back to 2012 and saddens me deeply that 7 more years of development changed nothing on this front)), or shut the Firefox down each time by killing it from the Task Manager; or could there maybe a fix to this? ...

Yes, accept that as the way Firefox works!

As far as that article from 2012 and 7 years more development goes, Firefox can take longer to completely close down than it did 7 years ago it some cases. There are many more files that are kept open while Firefox is running than there were years ago; files that do need time to be closed before Firefox is ready to be re-opened.

And its not like the Mozilla developers have done nothing to speed things up when Firefox is closed down. If you have spent anytime perusing the files in the Profile folder, you would have seen that Firefox has many more files in the Profile folder than were present years ago and with Quantum 57 there was fairly large increase in the number of files added. Most notably and related to this "Firefox is already running ..." topic, with Firefox running see the number of "temporary" *.sqlite-wal and *.sqlite-shm files that will disappear when Firefox is closed. There are 4 pairs of that type of file in use while Firefox is running for temporary storage of user data while Firefox is being used; when Firefox closes down, the data in those files gets written to the "master" .sqlite file during the shutdown process. The developers need to balance the speed of Firefox when it is being used vs. the shutdown time it takes to close those "in use" files.

Start installing extensions and the time for a full closure may increase due to how each extension was written. Many extensions have transitioned away from the Legacy .rdf, .txt, .dat & .xml format for storing their data and are using the modern .sqlite, .json, and .mozlz4 file formats for storing data; that too can lengthen the shutdown time.

Bottom line is that the shutdown time is far less of a concern for developers than the launch time and the speed of Firefox when it is being used.

''Unbeknownst [[#question-1253308|said]]'' <blockquote> ... Should I just accept that this is the way Firefox works and that I need to wait 5-6 sec or so before attempting to reopen Firefox (as suggested here https://www.howtogeek.com/131004/how-to-fix-the-firefox-is-already-running-error/ (which dates back to 2012 and saddens me deeply that 7 more years of development changed nothing on this front)), or shut the Firefox down each time by killing it from the Task Manager; or could there maybe a fix to this? ... </blockquote> Yes, accept that as the way Firefox works! As far as that article from 2012 and 7 years more development goes, Firefox can take longer to completely close down than it did 7 years ago it some cases. There are many more files that are kept open while Firefox is running than there were years ago; files that do need time to be closed before Firefox is ready to be re-opened. And its not like the Mozilla developers have done nothing to speed things up when Firefox is closed down. If you have spent anytime perusing the files in the Profile folder, you would have seen that Firefox has many more files in the Profile folder than were present years ago and with Quantum 57 there was fairly large increase in the number of files added. Most notably and related to this "Firefox is already running ..." topic, with Firefox running see the number of "temporary" '''''*.sqlite-wal''''' and '''''*.sqlite-shm''''' files that will disappear when Firefox is closed. There are 4 pairs of that type of file in use while Firefox is running for temporary storage of user data while Firefox is being used; when Firefox closes down, the data in those files gets written to the "master" '''''.sqlite''''' file during the shutdown process. The developers need to balance the speed of Firefox when it is being used vs. the shutdown time it takes to close those "in use" files. Start installing extensions and the time for a full closure may increase due to how each extension was written. Many extensions have transitioned away from the Legacy .rdf, .txt, .dat & .xml format for storing their data and are using the modern .sqlite, .json, and .mozlz4 file formats for storing data; that too can lengthen the shutdown time. Bottom line is that the shutdown time is far less of a concern for developers than the launch time and the speed of Firefox when it is being used.
Was this helpful to you? 1
Quote

Question owner

the-edmeister said

Unbeknownst said
... Should I just accept that this is the way Firefox works and that I need to wait 5-6 sec or so before attempting to reopen Firefox (as suggested here https://www.howtogeek.com/131004/how-to-fix-the-firefox-is-already-running-error/ (which dates back to 2012 and saddens me deeply that 7 more years of development changed nothing on this front)), or shut the Firefox down each time by killing it from the Task Manager; or could there maybe a fix to this? ...

Yes, accept that as the way Firefox works!

As far as that article from 2012 and 7 years more development goes, Firefox can take longer to completely close down than it did 7 years ago it some cases. There are many more files that are kept open while Firefox is running than there were years ago; files that do need time to be closed before Firefox is ready to be re-opened.

And its not like the Mozilla developers have done nothing to speed things up when Firefox is closed down. If you have spent anytime perusing the files in the Profile folder, you would have seen that Firefox has many more files in the Profile folder than were present years ago and with Quantum 57 there was fairly large increase in the number of files added. Most notably and related to this "Firefox is already running ..." topic, with Firefox running see the number of "temporary" *.sqlite-wal and *.sqlite-shm files that will disappear when Firefox is closed. There are 4 pairs of that type of file in use while Firefox is running for temporary storage of user data while Firefox is being used; when Firefox closes down, the data in those files gets written to the "master" .sqlite file during the shutdown process. The developers need to balance the speed of Firefox when it is being used vs. the shutdown time it takes to close those "in use" files.

Start installing extensions and the time for a full closure may increase due to how each extension was written. Many extensions have transitioned away from the Legacy .rdf, .txt, .dat & .xml format for storing their data and are using the modern .sqlite, .json, and .mozlz4 file formats for storing data; that too can lengthen the shutdown time.

Bottom line is that the shutdown time is far less of a concern for developers than the launch time and the speed of Firefox when it is being used.

Thank you for this detailed and explanatory answer to my question.

You mentioned some changes that have been implemented with Firefox Quantum, and I can say that while Quantum to me was Firefox learning its lesson on launch speed from Chrome and other Chromium-based browsers, those browsers always shut themselves down almost instantly when the user presses shutdown button and then the user can immediately relaunch the browser. My gripe here is that while Firefox now loads really fast and also performs even better than the Chromium browsers while also occupying less CPU and RAM, it still shuts itself down very slowly that the end user encounters this dreaded "Firefox is already running..." error message unacceptably often.

Also, the 2012 article I linked on How-To Geek literally starts with the following sentence: "The “Firefox is already running, but is not responding” error has haunted Firefox users for years." As I mentioned in my original post, I remember encountering this issue Firefox 2 or 3 onwards and as a person who takes Mozilla over Google any day, it just saddens me to see that in 10+ years so little has been done on this front of Firefox, and it also was the reason I switched to Chrome for many years until Chrome started to freeze Windows 10 computers.

I had even started to think maybe I'm one of those very few people that encounters this message because I often close and relaunch Firefox within a short time window; but seeing the threads on support forums, tech blog articles, etc. I realized that this problem is not that rare and lots of users encounter it, so I wanted to post here to maybe get some insight on it. And your post actually gave me insight and suggested me reasons why this is still happening even after the drastic jump to the Quantum and what could be done in future to alleviate this issue; so thank you once again for taking your time to provide your insight on this.

''the-edmeister [[#answer-1205751|said]]'' <blockquote> ''Unbeknownst [[#question-1253308|said]]'' <blockquote> ... Should I just accept that this is the way Firefox works and that I need to wait 5-6 sec or so before attempting to reopen Firefox (as suggested here https://www.howtogeek.com/131004/how-to-fix-the-firefox-is-already-running-error/ (which dates back to 2012 and saddens me deeply that 7 more years of development changed nothing on this front)), or shut the Firefox down each time by killing it from the Task Manager; or could there maybe a fix to this? ... </blockquote> Yes, accept that as the way Firefox works! As far as that article from 2012 and 7 years more development goes, Firefox can take longer to completely close down than it did 7 years ago it some cases. There are many more files that are kept open while Firefox is running than there were years ago; files that do need time to be closed before Firefox is ready to be re-opened. And its not like the Mozilla developers have done nothing to speed things up when Firefox is closed down. If you have spent anytime perusing the files in the Profile folder, you would have seen that Firefox has many more files in the Profile folder than were present years ago and with Quantum 57 there was fairly large increase in the number of files added. Most notably and related to this "Firefox is already running ..." topic, with Firefox running see the number of "temporary" '''''*.sqlite-wal''''' and '''''*.sqlite-shm''''' files that will disappear when Firefox is closed. There are 4 pairs of that type of file in use while Firefox is running for temporary storage of user data while Firefox is being used; when Firefox closes down, the data in those files gets written to the "master" '''''.sqlite''''' file during the shutdown process. The developers need to balance the speed of Firefox when it is being used vs. the shutdown time it takes to close those "in use" files. Start installing extensions and the time for a full closure may increase due to how each extension was written. Many extensions have transitioned away from the Legacy .rdf, .txt, .dat & .xml format for storing their data and are using the modern .sqlite, .json, and .mozlz4 file formats for storing data; that too can lengthen the shutdown time. Bottom line is that the shutdown time is far less of a concern for developers than the launch time and the speed of Firefox when it is being used. </blockquote> Thank you for this detailed and explanatory answer to my question. You mentioned some changes that have been implemented with Firefox Quantum, and I can say that while Quantum to me was Firefox learning its lesson on launch speed from Chrome and other Chromium-based browsers, those browsers always shut themselves down almost instantly when the user presses shutdown button and then the user can immediately relaunch the browser. My gripe here is that while Firefox now loads really fast and also performs even better than the Chromium browsers while also occupying less CPU and RAM, it still shuts itself down very slowly that the end user encounters this dreaded "Firefox is already running..." error message unacceptably often. Also, the 2012 article I linked on How-To Geek literally starts with the following sentence: "The “Firefox is already running, but is not responding” error has haunted Firefox users for years." As I mentioned in my original post, I remember encountering this issue Firefox 2 or 3 onwards and as a person who takes Mozilla over Google any day, it just saddens me to see that in 10+ years so little has been done on this front of Firefox, and it also was the reason I switched to Chrome for many years until Chrome started to freeze Windows 10 computers. I had even started to think maybe I'm one of those very few people that encounters this message because I often close and relaunch Firefox within a short time window; but seeing the threads on support forums, tech blog articles, etc. I realized that this problem is not that rare and lots of users encounter it, so I wanted to post here to maybe get some insight on it. And your post actually gave me insight and suggested me reasons why this is still happening even after the drastic jump to the Quantum and what could be done in future to alleviate this issue; so thank you once again for taking your time to provide your insight on this.

Modified by Unbeknownst

Was this helpful to you?
Quote

Question owner

the-edmeister said

Start installing extensions and the time for a full closure may increase due to how each extension was written. Many extensions have transitioned away from the Legacy .rdf, .txt, .dat & .xml format for storing their data and are using the modern .sqlite, .json, and .mozlz4 file formats for storing data; that too can lengthen the shutdown time.

Today I installed the new version 66 and I have to say, the problem doesn't feel near as bad as before. It isn't completely eradicated, but it became much rarer now and it takes a lot less time for Firefox to be responsive after getting the error message.

I'm contemplating that this has got to do with "Extensions now store their settings in a Firefox database, rather than individual JSON files, making every site you visit faster" (especially considering what you suggested as a probable cause for this delay in shutdown) and "Improved performance and reduced crash rates by doubling web content loading processes from 4 to 8" entries from the changelog.

Either way, I'm happy.

''the-edmeister [[#answer-1205751|said]]'' <blockquote> Start installing extensions and the time for a full closure may increase due to how each extension was written. Many extensions have transitioned away from the Legacy .rdf, .txt, .dat & .xml format for storing their data and are using the modern .sqlite, .json, and .mozlz4 file formats for storing data; that too can lengthen the shutdown time. </blockquote> Today I installed the new version 66 and I have to say, the problem doesn't feel near as bad as before. It isn't completely eradicated, but it became much rarer now and it takes a lot less time for Firefox to be responsive after getting the error message. I'm contemplating that this has got to do with "Extensions now store their settings in a Firefox database, rather than individual JSON files, making every site you visit faster" (especially considering what you suggested as a probable cause for this delay in shutdown) and "Improved performance and reduced crash rates by doubling web content loading processes from 4 to 8" entries from the changelog. Either way, I'm happy.
Was this helpful to you?
Quote
Ask a question

You must log in to your account to reply to posts. Please start a new question, if you do not have an account yet.