Is the "remove qtwebkit" approach because it's causing an actual problem, or is it just that it's old? Can we switch to qtwebengine where possible but still keep qtwebkit for things where it's still needed for certain software to work properly? Rendering local HTML files isn't a particularly high security risk.
Regarding qgis, it seems they _can't_ use qtwebengine: https://github.com/qgis/QGIS/issues/49512#issuecomment-1244676849 On 2024/02/09 08:44, Landry Breuil wrote: > Le Fri, Feb 09, 2024 at 08:19:12AM +0100, Landry Breuil a écrit : > > Le Thu, Feb 08, 2024 at 09:06:44PM +0100, Rafael Sadowski a écrit : > > > On Thu Feb 08, 2024 at 07:54:26PM +0100, Landry Breuil wrote: > > > > Le Thu, Feb 08, 2024 at 03:12:17PM +0100, Rafael Sadowski a écrit : > > > > > Here is a simple diff to remove qtwebkit from. I modified configure.py > > > > > to make sure it will not picked up even it is present. > > > > > > > > > > OK? > > > > > > > > obvious question, but all the runtime consumers of py-qt5 been checked > > > > for not actually relying on qtwebkit ? > > > > > > > > > > I have prep'ed for webkit in all ports that use py-qt5. > > > > > > What I see with my 99 years python experience: > > > > > > - lots of "webkit" in qutebrowser, but it runs with py-qtwebengine and > > > that's all css -webkit hacks. > > > - calibre and everything else looks good to me. > > > - I don't know if qgis parts are relevant > > > > the qgis bits look to be for a bundled copy of it.. i havent tried > > runtime yet with qtwebkit disabled, but from what i've understood from > > some gh issues/PR identifying objects on layers with html format should > > still work. > > now that i've tested 3.34.3p1, HTML query on features is rendered as > plaintext, so i guess there's some kind of fallback > mechanism/conversion.. not great, but i can live with that. > > after some time i'll see what other features might be degraded. >
