I just noticed that void WKPreferencesSetMetaRefreshEnabled(WKPreferencesRef preferencesRef, bool enabled) and bool WKPreferencesGetMetaRefreshEnabled(WKPreferencesRef preferencesRef) are working with httpEquiv, not with refresh. Looks like an easy fix after a copy&paste error. https://trac.webkit.org/browser/trunk/Source/WebKit2/UIProcess/API/C/WKPreferences.cpp#L1440 @198001
Good catch. That seems to be a private setting that is currently unused, though.
hmm, it seems it's not a copy-paste error, but that was done on purpose, see https://bugs.webkit.org/show_bug.cgi?id=146553. However, since that's private setting, we can probably remove it.
Yup, it's weird. I was looking for a way to disable http-equiv processing as such (my concern was about Content-Type with charset specified), when I noticed this "incompatibility". The name doesn't reflect what the function does, especially when there is another setting where one can do the same, with correct naming. I'd prefer to have this http-equiv disablement as a public option, easily accessible, ideally from the WebKitSettings or similar place. If you think it makes sense, I'll be happy to file a feature request for it.
(In reply to comment #3) > Yup, it's weird. I was looking for a way to disable http-equiv processing as > such (my concern was about Content-Type with charset specified), when I > noticed this "incompatibility". The name doesn't reflect what the function > does, especially when there is another setting where one can do the same, > with correct naming. My guess is that the old method was kept to not break the API. > I'd prefer to have this http-equiv disablement as a public option, easily > accessible, ideally from the WebKitSettings or similar place. If you think > it makes sense, I'll be happy to file a feature request for it. Yes, we don't use the WebKit2 C API in the GTK+ port, so if you need that setting (or any other) that is not exposed in WebKitSettings, just file a bug report explaining your use case to the GTK+ port.