Jackett search page often presents without section and search button does not work

[garfield69]

Have you checked our Troubleshooting page for your issue?

• I have checked the Troubleshooting page

Is there already an issue for your problem?

• I have checked older issues, open and closed

Have you read our Contributing Guidelines?

• I have read the Contributing Guidelines

Environment

2023-05-26 09:28:33	Info	Using HTTP Client: HttpWebClient2
2023-05-26 09:28:33	Info	Using FlareSolverr: http://127.0.0.1:8191
2023-05-26 09:28:33	Info	Using proxy: Disabled
2023-05-26 09:28:33	Info	App config/log directory: C:\ProgramData\Jackett
2023-05-26 09:28:33	Info	ThreadPool MaxThreads: 1023 workerThreads, 1000 completionPortThreads
2023-05-26 09:28:33	Info	Running in Docker: No
2023-05-26 09:28:33	Info	Jackett variant: CoreWindows
2023-05-26 09:28:33	Info	OS version: Microsoft Windows NT 10.0.19045.0 (64bit OS)
2023-05-26 09:28:33	Info	Environment version: 6.0.16 (C:\ProgramData\Jackett\)
2023-05-26 09:28:33	Info	Starting Jackett v0.21.34

Description

When I do several searches in a row by selecting indexers from the active page and performing a search, I regularly (every second or third search) get presented with a searcvh page that is not complete, and the search button does not work.
To recover I have to close that page, click on the browser refresh, and then the search page is complete again.
See the screenshot for how the search page looks when this happens.

windows 10 with Chrome browser 113

Logged Error Messages

there are not error message in the log, this is a GUI issue or some kind.

Screenshots

[ilike2burnthing]

This occasionally happens to me as well, has done probably since I first started using Jackett:

• Jackett running on Docker, accessed in Edge on Windows
• Windows 10 VM or Sandbox, Edge

[mynameisbogdan]

The console log in browser should say something.

[ilike2burnthing]

Ah the joy of intermittent issues... 🙄 eventually got it to happen:

2023-05-26 00:02:15.7203 Debug Connection id "0HMQSTHP4HSFD" accepted. 
2023-05-26 00:02:15.7232 Debug Connection id "0HMQSTHP4HSFD" started. 
2023-05-26 00:02:15.7240 Info Request starting HTTP/1.1 GET http://127.0.0.1:9117/api/v2.0/server/logs?_=1685054634469 - - 
2023-05-26 00:02:15.7240 Debug Request is continuing in applying rules. Current url is http://127.0.0.1:9117/api/v2.0/server/logs?_=1685054634469 
2023-05-26 00:02:15.7251 Debug Request is continuing in applying rules. Current url is http://127.0.0.1:9117/api/v2.0/server/logs?_=1685054634469 
2023-05-26 00:02:15.7251 Debug Request is continuing in applying rules. Current url is http://127.0.0.1:9117/api/v2.0/server/logs?_=1685054634469 
2023-05-26 00:02:15.7274 Debug The request path /api/v2.0/server/logs does not match a supported file type 
2023-05-26 00:02:15.7395 Debug AuthenticationScheme: Cookies was successfully authenticated. 
2023-05-26 00:02:15.7402 Debug 1 candidate(s) found for the request path '/api/v2.0/server/logs' 
2023-05-26 00:02:15.7402 Debug Endpoint 'Jackett.Server.Controllers.ServerConfigurationController.Logs (jackett)' with route pattern 'api/v2.0/server/Logs' is valid for the request path '/api/v2.0/server/logs' 
2023-05-26 00:02:15.7411 Debug Request matched endpoint 'Jackett.Server.Controllers.ServerConfigurationController.Logs (jackett)' 
2023-05-26 00:02:15.7411 Info Executing endpoint 'Jackett.Server.Controllers.ServerConfigurationController.Logs (jackett)' 
2023-05-26 00:02:15.7556 Info Route matched with {action = "Logs", controller = "ServerConfiguration"}. Executing controller action with signature System.Collections.Generic.List`1[Jackett.Common.Models.CachedLog] Logs() on controller Jackett.Server.Controllers.ServerConfigurationController (jackett). 
2023-05-26 00:02:15.7605 Debug Execution plan of authorization filters (in the following order): Microsoft.AspNetCore.Mvc.Authorization.AuthorizeFilter 
2023-05-26 00:02:15.7610 Debug Execution plan of resource filters (in the following order): None 
2023-05-26 00:02:15.7610 Debug Execution plan of action filters (in the following order): Microsoft.AspNetCore.Mvc.Filters.ControllerActionFilter (Order: -2147483648), Microsoft.AspNetCore.Mvc.ModelBinding.UnsupportedContentTypeFilter (Order: -3000), Microsoft.AspNetCore.Mvc.Filters.ResponseCacheFilter 
2023-05-26 00:02:15.7610 Debug Execution plan of exception filters (in the following order): None 
2023-05-26 00:02:15.7621 Debug Execution plan of result filters (in the following order): None 
2023-05-26 00:02:15.7862 Debug Authorization was successful. 
2023-05-26 00:02:15.7862 Debug Executing controller factory for controller Jackett.Server.Controllers.ServerConfigurationController (jackett) 
2023-05-26 00:02:15.7875 Debug Executed controller factory for controller Jackett.Server.Controllers.ServerConfigurationController (jackett) 
2023-05-26 00:02:15.7920 Debug List of registered output formatters, in the following order: Microsoft.AspNetCore.Mvc.Formatters.HttpNoContentOutputFormatter, Microsoft.AspNetCore.Mvc.Formatters.StringOutputFormatter, Microsoft.AspNetCore.Mvc.Formatters.StreamOutputFormatter, Microsoft.AspNetCore.Mvc.Formatters.NewtonsoftJsonOutputFormatter 
2023-05-26 00:02:15.7920 Debug No information found on request to perform content negotiation. 
2023-05-26 00:02:15.7920 Debug Attempting to select an output formatter without using a content type as no explicit content types were specified for the response. 
2023-05-26 00:02:15.7941 Debug Attempting to select the first formatter in the output formatters list which can write the result. 
2023-05-26 00:02:15.7941 Debug Selected output formatter 'Microsoft.AspNetCore.Mvc.Formatters.NewtonsoftJsonOutputFormatter' and content type 'application/json' to write the response. 
2023-05-26 00:02:15.7951 Info Executing ObjectResult, writing value of type 'System.Collections.Generic.List`1[[Jackett.Common.Models.CachedLog, Jackett.Common, Version=0.21.34.0, Culture=neutral, PublicKeyToken=null]]'. 
2023-05-26 00:02:15.8113 Debug The response will be compressed with 'br'. 
2023-05-26 00:02:15.8219 Info Executed action Jackett.Server.Controllers.ServerConfigurationController.Logs (jackett) in 38.0671ms 
2023-05-26 00:02:15.8222 Info Executed endpoint 'Jackett.Server.Controllers.ServerConfigurationController.Logs (jackett)' 
2023-05-26 00:02:15.8222 Info Request finished HTTP/1.1 GET http://127.0.0.1:9117/api/v2.0/server/logs?_=1685054634469 - - - 200 - application/json;+charset=utf-8 98.8517ms 
2023-05-26 00:02:15.8232 Debug Connection id "0HMQSTHP4HSFD" disconnecting. 
2023-05-26 00:02:15.8232 Debug Connection id "0HMQSTHP4HSFD" stopped. 
2023-05-26 00:02:15.8252 Debug Connection id "0HMQSTHP4HSFD" sending FIN because: "The Socket transport's send loop completed gracefully."

[garfield69]

custom.js has a function called showSearch which does a remove of the section with the id select-indexer-modal
before building a replacement section using a template.
I added a console.log to trace what calls this function and found that despite this function being called in all instances (of clicking the search icon on the active indexers page), for some reason the section is not always removed before the new template is added, which results in a duplicate section with the same id being inserted into the index.html

This causes an error which prevents the browser displaying either section with the same id.

I do not know enough about GUI stuff to figure out why the remove command in the showSearch does not work in some instances.

[garfield69]

Oh, as for replicating the error, I find that clicking on an indexer search, closing it, clicking on the view log, closing it, and repeating this sequence [edit] with another indexer, reliably generates the partial search page, within a 2 to 4 cycle.

[garfield69]

As a test, I brute forced the issue by making the showSearch function perform the remove command twice to ensure all versions of that html block were removed.
This seems to have solved the problem, I've not been able to replicate the issue.
I'll sub a PR for peer review