298016 2025-08-28 00:01:09 -0700 REGRESSION(2.49.4): [GTK] Array with named members not passed properly to the UI process 2025-08-29 07:10:21 -0700 1 1 1 Unclassified WebKit WebKitGTK Other Unspecified Linux RESOLVED WONTFIX P2 Normal --- 1 mcrha webkit-unassigned achristensen bugs-noreply cgarcia mcatanzaro yaneti oldest_to_newest 2139275 0 mcrha 2025-08-28 00:01:09 -0700 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 2139277 1 mcrha 2025-08-28 00:04:58 -0700 For the record, the client side expects the first four members to be strings and the last four members to be integers. 2139331 2 mcatanzaro 2025-08-28 05:07:52 -0700 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"... 2139424 3 achristensen 2025-08-28 11:54:33 -0700 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. 2139429 4 mcrha 2025-08-28 12:02:19 -0700 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. 2139480 5 mcatanzaro 2025-08-28 14:07:02 -0700 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. :( 2139594 6 mcrha 2025-08-28 22:37:57 -0700 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). 2139595 7 mcrha 2025-08-28 22:47:25 -0700 For the reference, a fix for the upstream bug is https://gitlab.gnome.org/GNOME/evolution/-/commit/811a6df1f990855e49ecc0ba7b1a7f7a5ec251e6