Summary: | Clean up which storage cookie jar functions use | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Alexey Proskuryakov <ap> | ||||
Component: | Platform | Assignee: | Alexey Proskuryakov <ap> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | abarth, beidson, dglazkov, jberlin, thakis, webkit.review.bot | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
Alexey Proskuryakov
2012-11-06 14:19:26 PST
Created attachment 172654 [details]
proposed patch
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 Seems super unlikely that this broke Chromium. Comment on attachment 172654 [details]
proposed patch
Seems unobjectionable.
Comment on attachment 172654 [details] proposed patch Clearing flags on attachment: 172654 Committed r133694: <http://trac.webkit.org/changeset/133694> All reviewed patches have been landed. Closing bug. 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. 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 That patch appears to have healed the chromium-mac build. I'm looking for someone to drive http://crbug.com/101156 to completion. 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+. (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. 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... |