[Webkit-unassigned] [Bug 251808] New: Many unimplemented storage paths in WebsiteDataStore.cpp

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Feb 6 11:06:22 PST 2023


https://bugs.webkit.org/show_bug.cgi?id=251808

            Bug ID: 251808
           Summary: Many unimplemented storage paths in
                    WebsiteDataStore.cpp
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: PC
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mcatanzaro at gnome.org
                CC: bugs-noreply at webkitgtk.org, sihui_liu at apple.com
            Blocks: 210100

We have in WebsiteDataStore.cpp:

#if !PLATFORM(COCOA)
String WebsiteDataStore::defaultMediaCacheDirectory(const String&)
{
    // FIXME: Implement. https://bugs.webkit.org/show_bug.cgi?id=156369 and https://bugs.webkit.org/show_bug.cgi?id=156370
    return String();
}
String WebsiteDataStore::defaultAlternativeServicesDirectory(const String&)
{
    // FIXME: Implement.
    return String();
}
String WebsiteDataStore::defaultJavaScriptConfigurationDirectory(const String&)
{
    // FIXME: Implement.
    return String();
}

And also:

#if !USE(GLIB) && !PLATFORM(COCOA)
String WebsiteDataStore::defaultDeviceIdHashSaltsStorageDirectory(const String&)
{
    // Not implemented.
    return String();
}
#endif

Since these are in a cross-platform file, port maintainers will never know that they need to be implemented. :(

I wonder what has happened due to lack of default values for these data types? Hopefully the data is just not stored at all, and is not being stored outside permitted storage locations?

Implementing should be easy enough except for JavaScript configuration. Media cache is surely cache. I have no clue what "alternative services" are, but I guess that goes under data? Device ID hash salts is data. But then we have JavaScript configuration, which is unfortunate because this is our first data type that is neither data nor cache, but config. I wonder precisely what configuration is stored; perhaps we could pretend it's close enough to data? More likely, we might need to expose a base config dir if WebKit will be storing configuration in addition to data and cache. If so, should decide ASAP before stabilizing the new GTK/WPE API.


Referenced Bugs:

https://bugs.webkit.org/show_bug.cgi?id=210100
[Bug 210100] [META][GTK][GTK4] Support GTK4
-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230206/c2007292/attachment-0001.htm>


More information about the webkit-unassigned mailing list