Bug 242883

Created attachment 460993 [details] Patch

for EWS. will also remove tests.

Created attachment 461011 [details] Patch

Created attachment 461017 [details] Patch

Created attachment 461029 [details] Patch

Committed 252632@main (37224f042c17): <https://commits.webkit.org/252632@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 461029 [details].

<rdar://problem/97298966>

I guess there's no hope to revert this change, is there? Even you do not use it, the frame flattening is used (and is relied on) in the GNOME Evolution. The removal had been noticed only in the 2.37.90 release of the WebKitGTK [1] and I've got to it only two days before the hard code freeze, which is really not much time to change the core of the app without breaking user experience heavily. The GNOME (and Evolution) code is in the UI freeze already, if it changes anything. [1] https://gitlab.gnome.org/GNOME/evolution/-/issues/2001

Hi Milan, at your request we going to revert this for 2.38. This is actually public API (WebKitSettings:enable-frame-flattening, webkit_settings_get_enable_frame_flattening(), webkit_settings_set_enable_frame_flattening()), and it's not unused. Apps in Debian that are using it: asteroidmail evolution gnome-feeds remmina surf Ideally we support public APIs forever unless there is a very strong reason not to do so; however, in the case of settings that modify web content display like this one, we need to accept that settings will occasionally stop working as WebKit changes. The commit here deleted nearly 5000 lines of code, and I don't think Zalan is going to want to bring that back. So affected apps will need to stop depending on this setting for WebKitGTK 2.40. WebKitGTK 2.40 will reach stable and LTS Linux distributions around March next year, so affected apps will need to be updated before then ***even in older distributions that would not ordinarily take such updates***. To give application maintainers some chance to notice that these APIs will break, I will: * Deprecate them * Backport the deprecation to 2.38 * Attempt to reach out to the app maintainers

Created heads-up issues: https://github.com/astroidmail/astroid/issues/720 https://gitlab.com/Remmina/Remmina/-/issues/2780 https://gitlab.gnome.org/World/gfeeds/-/issues/124 Also sent a direct mail to the a Surf developer. Bug to deprecate this setting: bug #244624

Also note this is exposed via public API on Apple platforms too, see WebKitLegacy/mac/WebView/WebPreferences.mm and WebKitLegacy/mac/WebView/WebView.mm.

> ***even in older distributions that would not ordinarily take such updates*** Well, any such change is against common policies used in such older distributions with or without long term support. If you are going to remove public API, you are required to bump soname version. Everything else comes naturally out of it. The original change did not bump the soname version, or at least I do not see it in the attached patch, but it's possible I overlooked it.

(In reply to Milan Crha from comment #12) > > ***even in older distributions that would not ordinarily take such updates*** > > Well, any such change is against common policies used in such older > distributions with or without long term support. If you are going to remove > public API, you are required to bump soname version. Everything else comes > naturally out of it. If we do that, then there's massive breakage and all operating systems will give up on providing our security updates. Keeping the API around as a no-op confines the breakage only to the few apps that are affected by it and allows distros to keep updating WebKitGTK. I doubt we'll *ever* bump the soname for WebKitGTK for GTK 3.

*** Bug 256266 has been marked as a duplicate of this bug. ***