Summary: | REGRESSION(r154144): ASSERTION FAILED: m_history->provisionalItem() == m_requestedHistoryItem.get() | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Ryosuke Niwa <rniwa> | ||||||
Component: | Page Loading | Assignee: | Alexey Proskuryakov <ap> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | aestes, ap, beidson, commit-queue, darin | ||||||
Priority: | P2 | Keywords: | Regression | ||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Attachments: |
|
Description
Ryosuke Niwa
2013-08-16 14:52:48 PDT
Tools/Scripts/run-webkit-tests --debug http/tests/navigation/post-frames-goback1.html -2 Committed r154206: <http://trac.webkit.org/changeset/154206> I have this mostly done. NetworkProcess wasn't managing cache model correctly, so it ended up with no CFNetwork cache. Well, and WebProcess too. Created attachment 209112 [details]
proposed fix
Decided to do a simpler fix.
There are two aspects to dynamically changing cache model:
- Real clients should just set it upfront, changing it after some processes are created is a poorly defined operation. WKContextSetCacheModel currently fails to update cache model in Networking process, and it fails to accurately update cache sizes in WebProcess, especially when running in a non-default session.
- There are three regression tests that attempt to change cache model at runtime, and this is broken for multiple reasons, most notably because this is done in injected bundle, and doesn't update Networking process.
Neither appears important enough to address at the moment. Eventually, we should probably change cache model API to explicitly take a storage session (ditto for cookie accept policy).
Comment on attachment 209112 [details] proposed fix View in context: https://bugs.webkit.org/attachment.cgi?id=209112&action=review > Tools/ChangeLog:11 > + the easiest way to get this going to to initialize it to correct value upfront. typo: to to. This assertion failure could also happen in any process that had cache disabled on purpose, or even when cache was enabled, but couldn't hold the item. Tracking that with bug 120028. Created attachment 209124 [details]
patch for landing
Comment on attachment 209124 [details] patch for landing Clearing flags on attachment: 209124 Committed r154301: <http://trac.webkit.org/changeset/154301> All reviewed patches have been landed. Closing bug. |