Bug 155352
| Summary: | Copy&paste error in WKPreferencesSetMetaRefreshEnabled() and ...Get... | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Milan Crha <mcrha> |
| Component: | WebKit2 | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | beidson, cgarcia, sam |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Milan Crha
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 | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Carlos Garcia Campos
Good catch. That seems to be a private setting that is currently unused, though.
Carlos Garcia Campos
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
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
(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.