Should we be clearing cache

[mwpowellhtx]

I seem to be getting a lot of DOM exceptions responding when the application first loads. Do not have my app in a state to report the errors at the moment, but will follow up with that. Should we be clearing the Cache folder between sessions? On shutdown, or during load before the controls are initialized? In our case, for integration, puppeteering, this seems to help, not always, or with on intermittent issue before running fine afterwards, but more often than not. Thanks...

[mwpowellhtx]

To clarify, I can delete the Cache folder, and that seems to clear up the issue in most cases. Note, may also be a function of the upstream site, network latency, being slow to respond, which causes some of these issues being DOM out of sync.

[mwpowellhtx]

The exception:

CefSharp.Dom.EvaluationFailedException: 'Execution context was destroyed, most likely because of a navigation.'
MessageException: Execution context was destroyed, most likely because of a navigation.

Details:

This exception was originally thrown at this call stack:
    CefSharp.Dom.DevToolsConnection.SendAsyncInternal(string, object) in DevToolsConnection.cs
    CefSharp.Dom.DevToolsConnection.SendAsync<T>(string, object) in DevToolsConnection.cs
    CefSharp.Dom.ExecutionContext.ExecuteEvaluationAsync(string, object) in ExecutionContext.cs

In code CefSharp.Dom.ExecutionContext.cs.

private async Task<RemoteObject> ExecuteEvaluationAsync(string method, object args)
{
    // ...
}

[mwpowellhtx]

Seems as though it is possibly more of a DOM thing, but still the Cache question stands.

[amaitland]

Should we be clearing the Cache folder between sessions? On shutdown, or during load before the controls are initialized

I've never seen a case where clearing the cache was required for stability reasons. Suggests there's something else at play.

If you are using CEF's request handler then I'd try disabling it and switching entirely to CDP.

https://github.com/cefsharp/CefSharp.Dom/blob/main/lib/PuppeteerSharp.Tests/DevToolsContextLoaderFixture.cs#L47

[mwpowellhtx]

Well I am curious... here is a test case: https://panel.whalleybot.com/Login. Session over session, whether you find problems loading, or reloading as it were, given standing cache folder.

[mwpowellhtx]

And again it is appears to be a DOM issue, not sure how or why outside of the exceptions being thrown.

[mwpowellhtx]

@amaitland Bit of feedback, I am trying to scan for div elements and such, but they may not exist, and it is okay if they do not, depending on the use case. According to the docs, I should be able to wait for a null in response, but instead exceptions are thrown. I'm not sure how the navigation is happening, but this is the failure point. When I specify somethings like options, timeout, etc, then the exceptions are even more pronounced, and for reasons that seem irrelevant to the actual wait for or query in question.

Again, see use case above. Try with an illegal credential, and just let the page respond with invalid and such. We are scanning for these elements, or trying to, in order to gauge how to respond in our WPF application.

Open to suggestions, not sure exactly how we could possibly good better best resolve and or approach it.

[mwpowellhtx]

Here's the difficult I am having with the assumptions being made... Consider.

var options = new WaitForSelectorOptions { Timeout = 1000, Visible = true };
if (await context.WaitForSelectorAsync(S.DivAuthenticationContent, options) is null)
{
    return;
}

But when we feed timeout behavior options into the algorithm, we are seeing exceptions. In my opinion that's not an exception, necessarily. Timeout may indeed be happening, but we are intentionally patterning around either null or not null accordingly, by design.

In more app specific news, I see what was being done may be a misread on my part, but still, if we are intentionally expecting an element may not be there, that is not an exception, a null is expected, not a timeout exception.

[mwpowellhtx]

Thinking I got a bit better understanding around it, but for the options issue. To reiterate, throwing seems a bit strong given the nature of the API when a simple null not null response is probably quite adequate. But what do I know. Maybe there are good reasons for it besides the aforementioned...

[mwpowellhtx]

...some personal observations... to the point about the handler. Yes, that was part of the issue, but only part. Putting some comprehension around sign in saga into our application, a function of the browser site specific DOM. And better comprehension around certain URLs, which ones to 'handle' as it were, in terms of our internal "state machine", messages, etc. That made a huge difference. Especially toward end of the "loaded" state, when perhaps not all external URLs had been fully processed. So that could definitely lead to some false positives in the DOM, for certain waits, queries, etc.

[mwpowellhtx]

Will close for now. But still I think maybe the exception thing is a bit strong for certain waits or queries, when a simple null or not null return is all that is expected, if required. But again, I do not know what I do not know, re: the background internal workings.