NEW 155352
Copy&paste error in WKPreferencesSetMetaRefreshEnabled() and ...Get...
https://bugs.webkit.org/show_bug.cgi?id=155352
Summary Copy&paste error in WKPreferencesSetMetaRefreshEnabled() and ...Get...
Milan Crha
Reported 2016-03-11 01:21:41 PST
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
Attachments
Carlos Garcia Campos
Comment 1 2016-03-11 02:33:27 PST
Good catch. That seems to be a private setting that is currently unused, though.
Carlos Garcia Campos
Comment 2 2016-03-11 02:41:16 PST
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.
Milan Crha
Comment 3 2016-03-11 03:25:38 PST
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.
Carlos Garcia Campos
Comment 4 2016-03-11 05:08:59 PST
(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.
Note You need to log in before you can comment on or make changes to this bug.