lines before i actualy want to use the function SetJSMessageProperties() also but i cannot get it to work cause the JS::RootedValue ret variable is another than the JS::MutableHandleValue from the GuiPollMessage function. if someone get this figured out would be nice. it works in either way now its just to get some doubled code reduced.

is this bad cause i take this from GUIGetPlayerList

Weird that GuiPollMessage and GuiPollAllMessages have a different number of arguments and different return types.

Why isn't scriptInterface.Eval("({})", ret); done in the helper?

Probably ok to not call JSAutoRequest, as we're not registering new variables.
Maybe better to do it anyway for good measure.
Perhaps even best to search the other code and look at docs and old tickets to find out when we need it exactly.

Actually this function should be deleted altogether in a separate patch: #4482.

commented code

reference instead of copy, i.e. missing &

++i

L235 visualreplay.cpp JS_SetElement(cx, replaysWithoutNullEntries, i++, replay); xD

// Display chat messages when returning from a game ?

Correct in all cases called (when registering an account, logging in, logging in + receiving historic messages, returning from a game,), because LobbyGuiPollAllMessages covers all these cases.

Mh, don't we miss a reference here (as in doing an unneeded copy)? Is that the reason why the pop was done after reading from it?

comment unneeded IMO as the code below is self-evident

In the future we might want to extend this, so that people can also follow bans/kicks and error messages.

Perhaps we can just remember all messages, but there was a huge performance problem at the time when processing too many state changes after returning from a long game, which was the introduction of ClearPresenceUpdates.

I wonder how we filter those. Perhaps we should push a <std::pair<std::string, JS::Heap<JS::Value>>, so that the first` element of the pair shows us the type to filter.

I'll never understand whether to use push_back or emplace_back, since everyone says something different on the topic.
push_back is at least used twice, so we can keep it consistent at least.

(Actually this function looks like it should go into GUIScriptConversions.cpp, but deleting it will be better.)

No need to rename ret

ret -> messages?

uint32_t is what JS_SetElement takes: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/JSAPI_reference/JS_SetElement

Then we can start at 0 and are exempt from the CodingConventions and must use i++. (didn't consider it the first time)

(The entire array to JS::Value conversion can be avoided if we would have added it to GUIConversions.cpp, but.... deletion is better)

thats it u want this copy or again some overhead having later SetJSMessageProperties returned

i hope u can help me ther i will now nuke this if

ok i take push_back

actualy it says front() returns reference to front

yes

kick ban are chat messages type

its just game and system network message that are being not saved. these are errors disconnect/connect and update messages for the panel.