Each new tab leaks memory?

[d97RHM]

On a fresh install, with a fresh profile, I'm seeing an apparent misbehaviour of Basilisk where every time a tab is opened(even if nothing is loaded in it other than the default new tab content) an inProcessTabChildGlobal entry is added to about:memory(be sure to check the "verbose" checkbox, then press the "Measure" button, then CTRL-F for "inProcessTabChildGlobal" to see it in the "explicit" and "js-main-runtime-compartments" sections. In "explicit" the count is only visible on lines like "gc-heap" that are under inProcessTabChildGlobal in the tree.) and the count never decreases even if the tabs are closed and I mash the "Minimize memory usage" button in about:memory. I've also graphed private bytes in Process Explorer while opening and closing tabs for a second opinion and it does seem that the "floor" reached after all but one tab is closed increases without practical limit. This is on Windows 10 and Basilisk Version: 52.9.2020.04.17 (64-bit).

I'm hoping other users can verify whether this happens for them or not as I'm doubtful something this blatant is affecting everyone and I'd actually be the first to notice.

For background: I became aware of this because in my normal profile with plenty of weird add-ons I was noticing that scrolling got jerky after the browser had been open a few days and there seemed to be a correlation with the private bytes figure in Process Explorer getting to high values even when only a single empty tab was open so I started attempting to blame the memory on some of my add-ons and then discovered the subject.

[therube]

If I was looking correctly, if I understand your steps correctly, if I understand what I think I'm looking for, then I only saw two instances of "inProcessTabChildGlobal" mentioned.

Basically...

open B
about:memory -> verbose -> Measure
Ctrl+F, inProcessTabChildGlobal, found = 2

open a few tabs
about:memory -> verbose -> Measure
Ctrl+F, inProcessTabChildGlobal, found = 2

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.9) Gecko/20100101 Goanna/4.4 Firefox/68.9 Basilisk/20200206
(so I'm on an older, non-current version then you)

[d97RHM]

open a few tabs
about:memory -> verbose -> Measure
Ctrl+F, inProcessTabChildGlobal, found = 2

Almost what I had in mind except counting the number of times the string is found doesn't work for this purpose. For the entry under "js-main-runtime-compartments" look at either the far right(this one will be in square brackets) or left(unbracketed) of the line for the number of interest. To find the same number for the entry under "explicit"(not strictly necessary since I expect it to always be the same exact number but confirmation doesn't hurt.) look for "gc-heap"(which is the topmost entry of interest in my about:memory) or other non-expandable entries(nearly all of them will have the same number) that are descendants of the inProcessTabChildGlobal entry and look at the far right of the line for a number in brackets. If in doubt about what's a descendant you can click on the inProcessTabChildGlobal entry to collapse or expand all the descendants which should make it clear which they are.

[d97RHM]

Also for the purposes of this the experimental tabs ought to be opened and then closed again and then the "Minimize memory usage" button ought to pressed(to make sure anything that ever will naturally get removed from memory gets removed promptly) before the memory measurement is taken.

[Moonchild]

The number of inProcessTabChildGlobal compartments should be equal to the number of total tabs you have opened. These compartments are cycle-collected as normal and don't leak, unless some extension is (incorrectly) keeping the compartments alive. This container count includes "unloaded"/"suspended" tabs and tabs not yet loaded from sessionrestore when the option is to not load tab until activated. Each of these contains a few system scripts necessary for each tab, but should not take much memory each. Of course if you are a tab hoarder you will see considerably more memory use in total as a result, but it's assumed if you hoard tabs that you have more than some memory to play with that the small amount of memory per tab instance isn't much of a problem and insignificant overall.

I just verified in my days-old session that the number of globals is indeed equal to the number of active+unloaded tabs (39 in this case), and that they reduce (albeit not instantaneously or with forced CC because that's not how these containers work) if tabs are closed. There is no spoon leak.

[d97RHM]

I just verified in my days-old session that the number of globals is indeed equal to the number of active+unloaded tabs (39 in this case), and that they reduce (albeit not instantaneously or with forced CC because that's not how these containers work) if tabs are closed. There is no spoon leak.

Thank you very much for taking a look at this. This confirms for me that at the very least something is wrong with my normal profile(as no matter how much I use it the number never goes down) and I'll be attempting more long term testing with the fresh install, fresh profile to see whether there's anything I can do to actually get the number to go down just in case something about my system independent of the profile that is causing it to not work as intended. I had tried using the cc/gc analysis python scripts at https://github.com/amccreight/heapgraph on the exported logs from my normal profile to figure out whether it was an add-on issue but that seemed to dead end at a "preserved wrapper" without ever crossing any add-on code which got me wondering about the un-customized scenario. I'll refrain from posting more on this topic unless I find something very persuasive.

Thanks again!

[therube]

Could you post the about:support... type of information that is typically requested in these parts.

Any ideas as to what may be causing the situation on your end? Extensions?

[therube]

Oh I've probably got it wrong again, but FWIW...

(something like...)

5. i closed 237 /more/ tabs, 57 tabs remaining
6. closed 50 /more/ tabs, 6 tabs remaining
7. closed 2nd window with final 6 tabs in it
8. open a new window & a bunch of new tabs, 163 of them, it seems
9. close that window
10. GC
11. CC
12. Minimize

[d97RHM]

Could you post the about:support... type of information that is typically requested in these parts.

Surprised I never noticed that existed before. I suppose this is the first time I ever asked anybody but google about browser issues.

As suggested at the end of my last post I had actually given up on getting help on this until such time as I had a stronger case based on experimentation that it wasn't just my own fault somehow(I'm awful about tweaking things then forgetting I did it or just not realizing the full implications until much later) but if anyone can spot a red flag in this that would be great. I'm assuming the result of the 'copy text to clipboard' button is the extent of your request? This is from the clean-room profile since it seems to be showing off the issue just fine and is certainly a less wild target than my normal one for anyone including me to prognosticate about.

Application Basics
------------------

Name: Basilisk
Version: 52.9.2020.04.17 (64-bit)
Build ID: 20200417135357
Update Channel: release
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.9) Gecko/20100101 Goanna/4.5 Firefox/68.9 Basilisk/20200417
OS: Windows_NT 10.0
Safe Mode: false

Extensions
----------

Graphics
--------

Features
Compositing: Direct3D 11
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Asynchronous Pan/Zoom: none
WebGL 1 Driver WSI Info: EGL_VENDOR: Google Inc. (adapter LUID: 000000000000b112) EGL_VERSION: 1.4 (ANGLE 2.1.0.) EGL_EXTENSIONS: EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_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_nv12 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
WebGL 1 Driver Renderer: Google Inc. -- ANGLE (NVIDIA GeForce GTX 1080 Ti Direct3D11 vs_5_0 ps_5_0)
WebGL 1 Driver Version: OpenGL ES 2.0 (ANGLE 2.1.0.)
WebGL 1 Driver Extensions: GL_OES_element_index_uint GL_OES_packed_depth_stencil GL_OES_get_program_binary GL_OES_rgb8_rgba8 GL_EXT_texture_format_BGRA8888 GL_EXT_read_format_bgra GL_NV_pixel_buffer_object GL_OES_mapbuffer GL_EXT_map_buffer_range GL_EXT_color_buffer_half_float GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_float GL_OES_texture_float_linear GL_EXT_texture_rg GL_EXT_texture_compression_dxt1 GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_OES_compressed_ETC1_RGB8_texture GL_EXT_sRGB GL_ANGLE_depth_texture GL_OES_depth32 GL_EXT_texture_storage GL_OES_texture_npot GL_EXT_draw_buffers GL_EXT_texture_filter_anisotropic GL_EXT_occlusion_query_boolean GL_NV_fence GL_EXT_disjoint_timer_query GL_EXT_robustness GL_EXT_blend_minmax GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_pack_reverse_row_order GL_OES_standard_derivatives GL_EXT_shader_texture_lod GL_EXT_frag_depth GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_EXT_discard_framebuffer GL_EXT_debug_marker GL_OES_EGL_image GL_OES_EGL_image_external GL_NV_EGL_stream_consumer_external GL_EXT_unpack_subimage GL_NV_pack_subimage GL_OES_vertex_array_object GL_KHR_debug GL_ANGLE_lossy_etc_decode GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_sync_query GL_CHROMIUM_copy_texture
WebGL 1 Extensions: ANGLE_instanced_arrays EXT_blend_minmax EXT_color_buffer_half_float EXT_frag_depth EXT_shader_texture_lod EXT_texture_filter_anisotropic EXT_disjoint_timer_query MOZ_debug_get 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_etc1 WEBGL_compressed_texture_s3tc WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_depth_texture WEBGL_draw_buffers WEBGL_lose_context MOZ_WEBGL_lose_context MOZ_WEBGL_compressed_texture_s3tc MOZ_WEBGL_depth_texture
WebGL 2 Driver WSI Info: EGL_VENDOR: Google Inc. (adapter LUID: 000000000000b112) EGL_VERSION: 1.4 (ANGLE 2.1.0.) EGL_EXTENSIONS: EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_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_nv12 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
WebGL 2 Driver Renderer: Google Inc. -- ANGLE (NVIDIA GeForce GTX 1080 Ti Direct3D11 vs_5_0 ps_5_0)
WebGL 2 Driver Version: OpenGL ES 3.0 (ANGLE 2.1.0.)
WebGL 2 Driver Extensions: GL_OES_element_index_uint GL_OES_packed_depth_stencil GL_OES_get_program_binary GL_OES_rgb8_rgba8 GL_EXT_texture_format_BGRA8888 GL_EXT_read_format_bgra GL_NV_pixel_buffer_object GL_OES_mapbuffer GL_EXT_map_buffer_range GL_EXT_color_buffer_half_float GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_float GL_OES_texture_float_linear GL_EXT_texture_rg GL_EXT_texture_compression_dxt1 GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_OES_compressed_ETC1_RGB8_texture GL_EXT_sRGB GL_ANGLE_depth_texture GL_OES_depth32 GL_EXT_texture_storage GL_OES_texture_npot GL_EXT_draw_buffers GL_EXT_texture_filter_anisotropic GL_EXT_occlusion_query_boolean GL_NV_fence GL_EXT_disjoint_timer_query GL_EXT_robustness GL_EXT_blend_minmax GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_pack_reverse_row_order GL_OES_standard_derivatives GL_EXT_shader_texture_lod GL_EXT_frag_depth GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_EXT_discard_framebuffer GL_EXT_debug_marker GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_EGL_image_external_essl3 GL_NV_EGL_stream_consumer_external GL_EXT_unpack_subimage GL_NV_pack_subimage GL_EXT_color_buffer_float GL_OES_vertex_array_object GL_KHR_debug GL_ANGLE_lossy_etc_decode GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_sync_query GL_CHROMIUM_copy_texture GL_EXT_texture_norm16
WebGL 2 Extensions: EXT_color_buffer_float EXT_texture_filter_anisotropic EXT_disjoint_timer_query MOZ_debug_get OES_texture_float_linear WEBGL_compressed_texture_etc WEBGL_compressed_texture_etc1 WEBGL_compressed_texture_s3tc WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_lose_context MOZ_WEBGL_lose_context MOZ_WEBGL_compressed_texture_s3tc
Hardware H264 Decoding: Yes; Using D3D11 API
Audio Backend: wasapi
Direct2D: true
DirectWrite: true (10.0.17134.1)
GPU #1
Active: Yes
Description: NVIDIA GeForce GTX 1080 Ti
Vendor ID: 0x10de
Device ID: 0x1b06
Driver Version: 24.21.14.1170
Driver Date: 9-25-2018
Drivers: C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_2607ccebc5b08aba\nvldumdx.dll,C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_2607ccebc5b08aba\nvldumdx.dll,C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_2607ccebc5b08aba\nvldumdx.dll,C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_2607ccebc5b08aba\nvldumdx.dll C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_2607ccebc5b08aba\nvldumd.dll,C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_2607ccebc5b08aba\nvldumd.dll,C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_2607ccebc5b08aba\nvldumd.dll,C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_2607ccebc5b08aba\nvldumd.dll
Subsys ID: 36071462
RAM: 11264

Diagnostics
ClearType Parameters: Gamma: 2.2 Pixel Structure: RGB ClearType Level: 100 Enhanced Contrast: 100
AzureCanvasAccelerated: 0
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
ClearType Parameters: Gamma: 2.2 Pixel Structure: RGB ClearType Level: 100 Enhanced Contrast: 100





Important Modified Preferences
------------------------------

accessibility.typeaheadfind.flashBar: 0
browser.cache.disk.capacity: 358400
browser.cache.disk.smart_size.first_run: false
browser.cache.frecency_experiment: 1
browser.download.importedFromSqlite: true
browser.places.smartBookmarksVersion: 8
browser.sessionstore.upgradeBackup.latestBuildID: 20200417135357
browser.startup.homepage_override.buildID: 20200417135357
browser.startup.homepage_override.mstone: 4.5.9
browser.urlbar.daysBeforeHidingSuggestionsPrompt: 2
browser.urlbar.lastSuggestionsPromptDate: 20200427
extensions.lastAppVersion: 52.9.2020.04.17
gfx.crash-guard.d3d11layers.appVersion: 52.9.2020.04.17
gfx.crash-guard.d3d11layers.deviceID: 0x1b06
gfx.crash-guard.d3d11layers.driverVersion: 24.21.14.1170
gfx.crash-guard.d3d11layers.feature-d2d: true
gfx.crash-guard.d3d11layers.feature-d3d11: true
gfx.crash-guard.status.d3d11layers: 2
gfx.crash-guard.status.d3d11video: 2
media.gmp-gmpopenh264.lastUpdate: 1587910023
media.gmp-gmpopenh264.version: 1.7.1
media.gmp-manager.buildID: 20200417135357
media.gmp-manager.lastCheck: 1587910023
media.gmp.storage.version.observed: 1
media.hardware-video-decoding.failed: false
network.cookie.prefsMigrated: true
network.predictor.cleaned-up: true
places.database.lastMaintenance: 1587949395
places.history.expiration.transient_current_max_pages: 122334
plugin.disable_full_page_plugin_for_types: application/pdf
storage.vacuum.last.index: 0
storage.vacuum.last.places.sqlite: 1587949395
ui.osk.debug.keyboardDisplayReason: IKPOS: Touch screen not found.

Important Locked Preferences
----------------------------

Places Database
---------------

JavaScript
----------

Incremental GC: true

Accessibility
-------------

Activated: false
Prevent Accessibility: 0

Library Versions
----------------

NSPR
Expected minimum version: 4.24
Version in use: 4.24

NSS
Expected minimum version: 3.48
Version in use: 3.48

NSSSMIME
Expected minimum version: 3.48
Version in use: 3.48

NSSSSL
Expected minimum version: 3.48
Version in use: 3.48

NSSUTIL
Expected minimum version: 3.48
Version in use: 3.48

Any ideas as to what may be causing the situation on your end? Extensions?

Other than my bad habit of tweaking things and forgetting/never really understanding them to begin with(main reason I went with a fresh install in addition to a fresh profile before posting this since I know in the remote past I actually would edit files in the program files instead of overriding them with add-ons as I now do), I really don't have a clue since this is a recent but not nearly bleeding edge system and I generally don't have any weird issues with Basilisk like this that I can't just google my way out of. If there are any extensions or non-vanilla things in the clean-room profile it's spooky NSA stuff I can't see .

On my normal profile I have extensions nobody ever even heard of because I just wrote them myself or modded them seriously from published ones(absolutely the primary reason I use Basilisk since I didn't want to deal with trying to re-implement them, if the crippled Nu-Firefox API could even theoretically do that which I'm pretty sure for some of them it cannot and I'd have to get into compiling my own version which I hope to avoid as long as I live.) so not going to bother with listing those.

Since my last post the only experiment I've done is using the 'clean-room' profile and letting it sit for periods of up to an hour, opening a new window and closing the old one, minimizing it and letting it sit, letting it go through a sleep/wake cycle, none of which resulted in the about:memory numbers for inProcessTabChildGlobal decreasing whatsoever. Incidentally if anybody can tell me more specifically about what the expected time-frame/scenario for inProcessTabChildGlobal leaving memory is I'm very interested.

I still intend to do some more experiments and only perturb anybody about them if they seem persuasive that I'm not the sole problem here but if more info is requested I'll probably post it.

P.S.: just saw therube's screenshots while previewing this post and he absolutely does have a lot of inProcessTabChildGlobals on display(740 is the max shown for anybody in doubt) but based on Moonchild's reply my initial methods of checking for whether this is happening to somebody or not seem unsound so what 740 inProcessTabChildGlobals really means when there aren't nearly that many tabs of any kind apparently open I can't say at this time.

[Moonchild]

therube... I told you these will not be collected immediately or when forcing CC. Your exercise was rather pointless.

Incidentally if anybody can tell me more specifically about what the expected time-frame/scenario for inProcessTabChildGlobal leaving memory is I'm very interested.

It depends on many factors. idle time, memory pressure, whether something holds a lock on it, dependent network and shared style and script containers, etc. so no, nobody can tell you with certainty when they are expected to be cleaned up except for "when you restart the browser". The garbace and cycle collectors are very complex pieces of machinery, so is the browser.

Now the real question is aside from looking at number of containers in administration by the browser in about:memory, is there a real issue?

P.S.: i suggest you install updated video drivers. Yours are from 2018, which may contribute to memory leakage.

[d97RHM]

P.S.: i suggest you install updated video drivers. Yours are from 2018, which may contribute to memory leakage.

That's a reasonable suggestion, thank you.

Having completed the last of the experiments I intended to on multiple Windows 10 systems from rather different hardware generations and circumstantially reinforced by therube's screenshots, I have concluded that there is a great difference between the behaviour of Pale Moon and of Basilisk concerning how long useless inProcessTabChildGlobal instances are preserved and it is independent of extensions or hardware at least within Windows 10 computers.

The behaviour of Pale Moon is very much as Moonchild described in his first reply. inProcessTabChildGlobal instances are removed until they match the visibly open number of tabs in a prompt but not instantaneous way, in my experiments never exceeding 2 minutes after the tab closes without any special conditions required. That reply of Moonchild was presumptively about Basilisk being in the Basilisk forum in a thread explicitly naming Basilisk in the OP but it does not at all match the behaviour now seen on multiple Windows 10 computers. I have great respect for Moonchild's efforts and don't wish to speculate about why this mismatch exists except that it may have been an innocent over generalization of the commonalities between Pale Moon and Basilisk.

The behaviour of Basilisk is not at all like that of Pale Moon under any circumstance I tested. It is as I have already stated above, holding on to inProcessTabChildGlobal instances seemingly forever, which does constitute an effective memory leak. It could be that under some really extreme scenario they would be released making it not technically a leak but the buildup that occurs without that happening is excessive and at least sometimes problematic. In no case I experimented with were any instances of inProcessTabChildGlobal ever removed from memory. In processes that have had large numbers of tabs opened by seemingly any means such as opening a blank tab or opening a link in a new tab this causes pointless and ever increasing memory use and even when this memory use is not close to any physical limit of available hardware it causes problems such as jerky scrolling. The threshold where this seems to become noticeable is not well defined but for me it seems to occur around 800 tabs opened or 2 GB of private bytes as shown near the bottom of about:memory or Process Explorer when only one empty tab has been open for a while. which usually takes me a day or 2 from when I start a given process under normal circumstances. I'm sure many things might confound the private bytes measurement but for me it doesn't vary much.

I cite therube's post as circumstantial support for the difference between the browsers since it would be hard(though not impossible with certain tools) to close that many tabs and press the indicated buttons fast enough to see 740 inProcessTabChildGlobal instances if Basilisk were behaving as Pale Moon does.

Is this a real problem? Restarting Basilisk every few days doesn't seem like that big a deal to me except that it seems to be very unnecessary in light of how Pale moon behaves.

I wish the best to all involved.

[Moonchild]

Since Pale Moon is my main browser, I performed my tests with Pale Moon, not Basilisk. Primarily because I didn't expect the behaviour of Pale Moon and Basilisk to be significantly different here, as management of script containers and their release is handled purely in the platform code. It is interesting at least that it seems it is different. It would mean that there is something in the front-end code that prevents the proper release of tab frame containers. If that's the case, then Basilisk has most likely inherited that behaviour from Mozilla Firefox ESR 52 which it is a very close twin to.
Either way, it would require trying to pinpoint what is holding these containers alive; and aside from trial and error testing (which I don't think any of the core devs have time for) I don't really know where to start narrowing down this quirk.