[webkit-reviews] review denied: [Bug 76270] implement offline web applications abort API : [Attachment 122437] patch to fix compile error
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Fri Jan 13 11:19:05 PST 2012
Alexey Proskuryakov <ap at webkit.org> has denied huangxueqing
<huangxueqing at baidu.com>'s request for review:
Bug 76270: implement offline web applications abort API
https://bugs.webkit.org/show_bug.cgi?id=76270
Attachment 122437: patch to fix compile error
https://bugs.webkit.org/attachment.cgi?id=122437&action=review
------- Additional Comments from Alexey Proskuryakov <ap at webkit.org>
View in context: https://bugs.webkit.org/attachment.cgi?id=122437&action=review
We need more tests for this feature. Anything that didn't work at first in your
implementation, or anything that you suspect a future careless refactoring
could potentially break should be tested.
Don't be shy to add multiple test files if needed - this often works better
than cramming multiple tests into one HTML file.
> Source/WebCore/loader/appcache/ApplicationCacheGroup.cpp:465
> + if (m_updateStatus == Checking || m_updateStatus == Downloading) {
In WebKit code, we prefer early return to nesting code. So, just write
if (m_updateStatus == Idle)
return;
ASSERT(m_updateStatus == Checking || (m_updateStatus == Downloading &&
m_cacheBeingUpdated));
> Source/WebCore/loader/appcache/ApplicationCacheGroup.cpp:470
> + // It hasn't necessary abort download process if
> + // m_completionType was Failure or Completed or NoUpdate
> + // since the process was completed except reset state.
> + if (m_completionType != None)
> + return;
When does this code work? Is it for calling abort() from within an error or
cached event handler? But I would expect that to be caught by m_updateStatus
check above.
Please verify that this code is really needed, and add a regression test that
would have failed if not for it.
> Source/WebCore/loader/appcache/ApplicationCacheGroup.cpp:472
> + stopLoading();
The spec just says that we should run cache failure steps, which translates to
calling cacheUpdateFailed(). Is there a reason why that doesn't work?
I'm very concerned about adding another copy of cleanup code - historically,
it's been extremely fragile and difficult to maintain.
We need a regression test showing that a previous version of appcache is still
fully alive and functioning after an abort().
> Source/WebCore/loader/appcache/ApplicationCacheGroup.h:80
> + void abort(Frame*);
What's the expected behavior if frame argument is different from m_frame?
> Source/WebCore/loader/appcache/ApplicationCacheHost.cpp:468
> + if ((status() == UNCACHED)
> + || (status() == OBSOLETE)
> + || (status() == UPDATEREADY)
> + || (status() == IDLE))
> + return;
We already have a similar check in ApplicationCacheGroup. Why is it repeated
here?
> Source/WebCore/loader/appcache/ApplicationCacheHost.cpp:471
> + ApplicationCache* cache = applicationCache();
> + cache->group()->abort(m_documentLoader->frame());
A comment in ApplicationCacheHost.h says that this is "The application cache
that the document loader is associated with (if any)". But a document loader
isn't associated with a cache until it's fully downloaded. So how can we stop
an initial download with this code? I'm confused.
Shouldn't we be using m_candidateApplicationCacheGroup?
More information about the webkit-reviews
mailing list