Bug 43714 - Move filehandling into fileLoadTimer callback
Summary: Move filehandling into fileLoadTimer callback
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Platform (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows XP
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 43712
  Show dependency treegraph
 
Reported: 2010-08-09 02:21 PDT by Patrick R. Gansterer
Modified: 2010-08-23 15:12 PDT (History)
4 users (show)

See Also:


Attachments
Patch (4.43 KB, patch)
2010-08-09 03:19 PDT, Patrick R. Gansterer
aroben: review-
Details | Formatted Diff | Diff
Patch (4.62 KB, patch)
2010-08-23 09:04 PDT, Patrick R. Gansterer
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick R. Gansterer 2010-08-09 02:21:59 PDT
see patch
Comment 1 Patrick R. Gansterer 2010-08-09 03:19:24 PDT
Created attachment 63879 [details]
Patch
Comment 2 Adam Roben (:aroben) 2010-08-16 07:39:20 PDT
Comment on attachment 63879 [details]
Patch

> -void ResourceHandle::fileLoadTimer(Timer<ResourceHandle>* timer)
> +void ResourceHandle::fileLoadTimer(Timer<ResourceHandle>*)
>  {
> +    String path = firstRequest().url().path();
> +    // Windows does not enjoy a leading slash on paths.
> +    if (path[0] == '/')
> +        path = path.substring(1);
> +
> +    int queryPos = path.find('?');
> +    if (queryPos != -1)
> +        path.remove(queryPos);

I'm surprised that KURL::path would return a string that contains a query component. That seems like a bad bug. Is that really happening?

It seems like it would be better to use KURL::fileSystemPath anyway.

> +    if (fileHandle == INVALID_HANDLE_VALUE) {
> +        client()->didFail(this, ResourceError());
> +        deref();
> +        return;
> +    }

Where is the ref() that this deref() is balancing? I don't see it in this patch. Was it a bug that we weren't dereffing before? We usually include a comment at both the ref() and deref() callsites mentioning where the balancing call is.

> +    int dotPos = path.reverseFind('.');
> +    int slashPos = path.reverseFind('/');
> +
> +    if (slashPos < dotPos && dotPos != -1) {
> +        String ext = path.substring(dotPos + 1);
> +        response.setMimeType(MIMETypeRegistry::getMIMETypeForExtension(ext));
> +    }

This code seems entirely new and doesn't match the ChangeLog (which claims this patch just moves code).
Comment 3 Patrick R. Gansterer 2010-08-16 07:50:18 PDT
(In reply to comment #2)
> (From update of attachment 63879 [details])
> > -void ResourceHandle::fileLoadTimer(Timer<ResourceHandle>* timer)
> > +void ResourceHandle::fileLoadTimer(Timer<ResourceHandle>*)
> >  {
> > +    String path = firstRequest().url().path();
> > +    // Windows does not enjoy a leading slash on paths.
> > +    if (path[0] == '/')
> > +        path = path.substring(1);
> > +
> > +    int queryPos = path.find('?');
> > +    if (queryPos != -1)
> > +        path.remove(queryPos);
> 
> I'm surprised that KURL::path would return a string that contains a query component. That seems like a bad bug. Is that really happening?
I had this problem at least once, so i added this.

> It seems like it would be better to use KURL::fileSystemPath anyway.
Didn't see that function. ;-)

> 
> > +    if (fileHandle == INVALID_HANDLE_VALUE) {
> > +        client()->didFail(this, ResourceError());
> > +        deref();
> > +        return;
> > +    }
> 
> Where is the ref() that this deref() is balancing? I don't see it in this patch. Was it a bug that we weren't dereffing before? We usually include a comment at both the ref() and deref() callsites mentioning where the balancing call is.
The ref() is directly at the start(). At the moment the ResourceHandleWin does a "delete this"!!! I'll add comments.

> 
> > +    int dotPos = path.reverseFind('.');
> > +    int slashPos = path.reverseFind('/');
> > +
> > +    if (slashPos < dotPos && dotPos != -1) {
> > +        String ext = path.substring(dotPos + 1);
> > +        response.setMimeType(MIMETypeRegistry::getMIMETypeForExtension(ext));
> > +    }
> 
> This code seems entirely new and doesn't match the ChangeLog (which claims this patch just moves code).
Ok, I'll update the ChangeLog.
Comment 4 Patrick R. Gansterer 2010-08-23 09:04:05 PDT
Created attachment 65126 [details]
Patch

The comment for the ref() will be included in a further patch.
Comment 5 Adam Roben (:aroben) 2010-08-23 09:31:56 PDT
Comment on attachment 65126 [details]
Patch

r=me
Comment 6 WebKit Commit Bot 2010-08-23 15:12:35 PDT
Comment on attachment 65126 [details]
Patch

Clearing flags on attachment: 65126

Committed r65835: <http://trac.webkit.org/changeset/65835>
Comment 7 WebKit Commit Bot 2010-08-23 15:12:40 PDT
All reviewed patches have been landed.  Closing bug.