Bug 101395 – Clean up which storage cookie jar functions use

• Component: Platform
• Status: RESOLVED FIXED

[Alexey Proskuryakov]

Some respect private browsing, and some don't. Furthermore, CF counterparts don't match Foundation ones.

[Alexey Proskuryakov]

Created attachment 172654 [details]
proposed patch

[WebKit Review Bot]

Comment on attachment 172654 [details]
proposed patch

Attachment 172654 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/14757165

New failing tests:
inspector-protocol/debugger-terminate-dedicated-worker-while-paused.html

[Alexey Proskuryakov]

Seems super unlikely that this broke Chromium.

[Brady Eidson]

Comment on attachment 172654 [details]
proposed patch

Seems unobjectionable.

[WebKit Review Bot]

Comment on attachment 172654 [details]
proposed patch

Clearing flags on attachment: 172654

Committed r133694: <http://trac.webkit.org/changeset/133694>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Alexey Proskuryakov]

I'm told that this broke Chromium Mac build. I'm not sure why WebKitSystemInterface changes can possibly have such an effect, someone from Chromium land will need to have a look.

Please don't roll out.

[Adam Barth]

I've attempted a build fix in http://trac.webkit.org/changeset/133721

I understand that you don't want the Chromium port using WebKitSystemInterface.  The bug for that change is https://code.google.com/p/chromium/issues/detail?id=101156

[Adam Barth]

That patch appears to have healed the chromium-mac build.  I'm looking for someone to drive http://crbug.com/101156 to completion.

[Alexey Proskuryakov]

Thank you Adam! Not sure why this fix works - does Chromium use an older copy of WKSI? It probably has to, because modern one is Lion+.

[Nico Weber]

(In reply to comment #10)
> Thank you Adam! Not sure why this fix works - does Chromium use an older copy of WKSI? It probably has to, because modern one is Lion+.

Yes, chromium uses an old version (http://crbug.com/101387). From what I understand, that's what weinig suggested on some private thread (that I wasn't on myself) between avi, darin (adler), fishd, msj, and a few others.

[Alexey Proskuryakov]

I was not aware of the setup either. I still don't fully understand it, neither the technical details, nor whether there is any kind of process that should prevent breaking the build.

Does Chromium link to the oldest or the newest WKSI static library? Or are they converted to dynamic libraries, and the one that matches current OS is used?

Looking at this specific build failure, I think that forking WebCoreSupport/WebSystemInterface.mm would have prevented it. There is no reason to try to initialize symbols that are not in your copy of WKSI, and that you do not need at all.

This won't resolve all issues though, as (1) the code in WKSI is not guaranteed to work in future OS versions, (2) we can always add more WKSI dependencies in WebCore, and I'm sure that there are (3), (4) and so on...