Web+: github floods console (Unhandled Promise Rejection), pegs a core

[humdinger]

When going to ​https://github.com a core pegs and the console is filled with:

MESSAGE https://github.githubassets.com/assets/vendors-node_modules_stacktrace-parser_dist_stack-trace-parser_esm_js-node_modules_github_bro-327bbf-0aaeb22dd2a5.js:1:8116: Unhandled Promise Rejection: TypeError: undefined is not an object (evaluating 'navigator.clipboard.read')

[nephele]

I've investigated it a bit and my naive understanding is that this is caused by a BMessage spam from webkit to webpositive for those log messages.

(as for the underlying thing that it complains about, no idea honestly, not too sure what the promises do :)

The Webkit code is rather simple: ​https://github.com/haiku/haikuwebkit/blob/haiku/Source/WebKitLegacy/haiku/API/WebPage.cpp#L949

void BWebPage::addMessageToConsole(const BString& source, int lineNumber,
    int columnNumber, const BString& text)
{
    BMessage message(ADD_CONSOLE_MESSAGE);
    message.AddString("source", source);
    message.AddInt32("line", lineNumber);
    message.AddInt32("column", columnNumber);
    message.AddString("string", text);
	dispatchMessage(message);
}

Perhaps we can add a de-duplication on the other side too? I saw you added it to the console itself recently.

I.e save (per source?) what the last message was, send it the first time and for repeated times count up until a different message is received, and then send it again to WebPositive with a count attribute in the message.

[nephele]

Backtrace of main thread of HaikuLauncher

[humdinger]

I.e save (per source?) what the last message was, send it the first time and for repeated times count up until a different message is received, and then send it again to WebPositive with a count attribute in the message.

But in a case like this Promise-spamming, we may not notice it, because only the first of those messages gets sent. Then only the counter increases and if there's no different error the message with the counter is never sent.

[nephele]

The error would still get delivered, i think thus would still be better than the other way around.

Anyhow, you could likely also flush this on a timer basis. But no idea yet how that could be done in webkit.

[nephele]

@madmax Do you have an idea how to solve this properly? maybe with a timer in webkit somewhere to flush this, or maybe know what the promise message is complaining about?

[pulkomandy]

Just merge more changes from WebKit and the issue will go away, as usual. GitHub tends to test only on the very latest browsers, and have issues on older ones.

Does it happen also with the current WebKit branch? Or is it already solved there?

[nephele]

merging more changes will probably not fix the underlying problem that websites can spam the console so much that it pegs the cpu to full.

Perhaps we can also just batch the logs or have a different delivery method? (or maybe only request the logs once the console is opened)

I will check on the current branch if this specific spam is resolved.

[nephele]

I've checked, it does indeed happen on the latest haiku branch commit

[madmax]

not too sure what the promises do

Promises are a way of asynchronous programming in JS. They take a handler for success and another one for failure. When they fail and there's no failure callback, a rejection event is sent to the window (or the Worker, if that's the context).

I guess (but haven't checked) that's the cause of those console messages. In this case the error seems to be due to not having something in 'navigator.clipboard.read'. Maybe we don't provide clipboard? Or WebKit itself doesn't, if it also happens in other implementations.

Sending these messages to console seems to be configurable: ​Source/WebCore/page/Settings.yaml, ​WebCore/dom/ScriptExecutionContext.cpp.

merging more changes will probably not fix the underlying problem that websites can spam the console so much that it pegs the cpu to full.

They can peg the CPU by many different methods. Batching log messages won't solve that. The only way may be to measure the CPU (memory, responsiveness, whatever) of each page and stop it if it misbehaves. Something like the message I used to see in some sites with an older computer when running Firefox.

[madmax]

Maybe we don't provide clipboard? Or WebKit itself doesn't

Or it is disabled. Enabling AsyncClipboardAPIEnabled for WebKitLegacy gets rid of the messages, though I have not tested the functionality (or any other thing, frankly; I just changed the setting and loaded github):

--- a/Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
+++ b/Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
@@ -571,6 +571,7 @@ AsyncClipboardAPIEnabled:
   humanReadableDescription: "Enable the async clipboard API"
   defaultValue:
     WebKitLegacy:
+      "PLATFORM(HAIKU)": true
       default: false
     WebKit:
       "PLATFORM(COCOA)" : true

[nephele]

I've also enabled intersectionobserver for github in the same file anyhow, we can do the same for this feature.

I've looked a bit at the clipboard api, not sure if I like that. Should websites be able to request the clipboard? The current way with it just getting it when the user does a paste seems better, maybe i'm overthinking this.

They can peg the CPU by many different methods. Batching log messages won't solve that.

Yes, that is true. But in this case it looks to me like our implementation is a bit inefficient and could likely be improved so this isn't a problem.

We can of course later on (with webkit2) check if we can do something like linux process control groups to set memory/cpu limits for specific processes or process groups and notify the user about which websites are beeing a bit invasive.

[pulkomandy]

We can optimize as much as we want, if a website does an infinite loop in javascript, it will peg the CPU. In this specific case it will just emit even more log messages.

The issue should be fixed on Github side...

[humdinger]

I just updated to This is hrev56578+77, 64bit. (HaikuWebKit 1.9.4) and the github site plays nice again. No more flooding, pegging and fan-overdrive. Thank you, thank you, thank you!!

[pulkomandy]

However, the "copy" buttons for example in Gerrit "download" menu don't work anymore, so some functions may need to be implemented.

[humdinger]

However, the "copy" buttons for example in Gerrit "download" menu don't work anymore...

Are you sure that is related? I've booted into the state before my update, HaikuWbKit 1.9.3, and the copy icon at Gerrit's didn't work back then either. Id did work at one time, I reember that, but don't know when it broke.

[pulkomandy]

Maybe it's not related and I didn't notice it before, yes.