Bug 298016 – REGRESSION(2.49.4): [GTK] Array with named members not passed properly to the UI process

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKitGTK

[Milan Crha]

Coming from downstream bug:
https://gitlab.gnome.org/GNOME/evolution/-/issues/3124

Evolution creates an object with named members like this in the JavaScript code and passes it to the UI process through the messages:

	var res = [];

	res["iframe-id"] = parent_iframe_id;
	res["elem-id"] = elem.id;
	res["elem-class"] = elem.className;
	res["elem-value"] = elem.getAttribute("value");
	res["left"] = with_parents_left - scroll_x;
	res["top"] = with_parents_top - scroll_y;
	res["width"] = elem.offsetWidth;
	res["height"] = elem.offsetHeight;

	window.webkit.messageHandlers.elementClicked.postMessage(res);

This worked up until 2.49.4, which reports on the UI side that the member's value is `undefined`, instead of the value. I tried with "elem-class" and with index 0.

Michael pointed to [1] in the downstream bug report.

[1] https://github.com/WebKit/WebKit/pull/47851

[Milan Crha]

For the record, the client side expects the first four members to be strings and the last four members to be integers.

[Michael Catanzaro]

I'm guessing either "Make JavaScriptEvaluationResult platform independent" or one of Alex's other recent commits to APISerializedScriptValue/JSEvaluationResult.

So we can't send objects anymore, but we can send "dictionaries"...

[Alex Christensen]

That is an array being used as a dictionary.  I think the cleanest solution would be to change "var res = [];" to "var res = {};" downstream.  If you really want to continue supporting things like that, we could but it would be a strange platform-specific thing because other platforms don't expose such properties on array results.

[Milan Crha]

The problem might be that this worked for years and suddenly does not. I can patch the Evolution code (hoping I'd not miss anything), but the WebkitGTK is updated in distros down to the Evolution versions which are obsolete for the upstream, thus any such potential fix won't get there and users with old Evolution will face the crash only because the distros do update WebKitGTK, but not Evolution (and other users of it, most likely). That does not feel great - not that it did not happen in the past though.

[Michael Catanzaro]

Honestly if this is the only regression from all this work, then I'm pretty happy. I wasn't sure what to expect.

It's probably best to just patch Evolution and carry the patches for as long as needed. Sorry Milan. :(

[Milan Crha]

It might be best for you, but not for package/distro maintainers. That's a pita. I know the WebKitGTK developers do not care of these silly things, but still.

I understood this is actually a bug in the Evolution JavaScript code, the arrays do not have named indexes, they have numbered indexes. That it worked before was just a matter of luck, right? I do not recall where I've got that code from, it's a long time since I created it. I will fix it for the upcoming release (3.57.3), I see it's used on multiple places, interestingly not on all.

That you for the hint how to correct it (I'm not a JavaScript person, it's odd I could generate so much code in it).

[Milan Crha]

For the reference, a fix for the upstream bug is https://gitlab.gnome.org/GNOME/evolution/-/commit/811a6df1f990855e49ecc0ba7b1a7f7a5ec251e6