[Webkit-unassigned] [Bug 141154] [EFL] REGRESSION (r178685): ASSERTION FAILED: !parameters.mediaKeyStorageDirectory.isEmpty()

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Feb 18 00:54:26 PST 2015


Grzegorz Czajkowski <g.czajkowski at samsung.com> changed:

           What    |Removed                     |Added
                 CC|                            |g.czajkowski at samsung.com

--- Comment #8 from Grzegorz Czajkowski <g.czajkowski at samsung.com> ---
(In reply to comment #3)
> Well the patch uploaded was just a quick workaround to be honest.
> I don't know if it is just EFL specific but GTK port 
> does not seem to be affected.

Probably because of they always create legacy options when context is constructed. See their webkitWebContextConstructed(GObject* object) in "Source/WebKit2/UIProcess/API/gtk/WebKitWebContext.cpp"

> (In reply to comment #2)
> > Could you explain why is it a regression of r178685 and why
> It started to occur after that commit, i bisected it and reverting that
> change
> would prevent the assertion.
> > do you think if it is the proper fix?
> > 
> No. That was a quick workaround. I will attach a different patch, seems like
> a more proper solution but I'm still unsure.
> > It's not clear for me why is it EFL specific. I haven't found 
> > any EFL specific thing near mediaKeyStorageDirectory.
> Don't know if it is just EFL specific but it does not occur on GTK port,
> they use slighly different codepaths when setting things up. Seems like GTK
> port somehow creates those folders when initialising Web process whlie EFL
> does not it seems. If I miss something obvious please tell me.

I think it's good idea to implement WebsiteDataStore::websiteDataDirectoryFileSystemRepresentation for EFL and have it WebKitTestRunner specific only. It looks like Mac already does, see Source/WebKit2/UIProcess/API/Cocoa/APIWebsiteDataStoreCocoa.mm

After that, we will have separate paths for testing and potential applications.

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/20150218/2c2dafcb/attachment-0002.html>

More information about the webkit-unassigned mailing list