Custom scheme handlers and responseType="blob"

[Mayhew]

I have found a strange issue with my custom scheme handler when it handles XMLHttpRequests that specify a responseType="blob". The issue is only on Mac and Linux. Windows doesn't seem to have the issue.

My CefResourceHandler subclass is supposed to get data from a local file on disk and respond with it. It uses a custom stream handler that specifies true for MayBlock() as it does disk IO. The resource handler also uses a separate thread for the actual file IO to keep from blocking the browser.

What I see is as follows:
1) I get a ProcessRequest call in my CefResourceHandler subclass and return true.
2) I get the GetResponseHeaders call and add my headers for content length (length of the file), data/time, expiration, etc. Pretty standard HTML stuff. Then I set the status code to 200.
3) I get the initial ReadResponse call. I want to perform the read on a separate thread so I do the following
bytes_read = 0;
// Store this for use by our FILE thread.
request_read_callback_ = callback;
// Start our file reader on the FILE thread.
PostTask(TID_FILE, NewCefRunnableMethod(this,&FileResourceHandler::ReadFile));

This stores the callback as a member var, and posts a task to call the ReadFile member method form the FILE thread. we then return true.
4) ReadFile gets called from the file thread and we start filling a 32768 byte buffer that is protected by a mutex and condition var. The condition var is used to signal the main thread that will get subsequent ReadResponse() calls for data. When ReadFile fills the buffer from disk the first time it calls callback->Continue() to start the flow of ReadResponse() calls and then it signals the condition var.
5) ReadResponse is called and if the buffer was still being filled it waits on the condition var. Once the signal happens, ReadResponse wakes and reads the buffer and respond with it. When that is done, it signals and returns true. The loop in ReadFile wakes and fills the buffer with the next 32768 bytes, and so on. They go back and forth until all the data is read and responded with.

This all works great and has for some time. The problem we see with 3.2062.18XX is that if the file I am reading is larger than 65536 bytes, I only get one ReadResponse call. I respond with the first 32768 bytes, then my read helper reads the next 32768 but no other ReadResponse calls ever come, even though I returned true in the first call. The request hangs. I don't think it is a timeout issue as the whole transaction, is done in milliseconds.

If the file is below 65535 bytes, I get two ReadResponse calls, one for 32768 and one more for the remainder.

If I don't set the XHRs responseType to "blob" it works perfectly. In fact responseType="arraybuffer" also works perfectly. The problem only happens with "blob". Also, it doesn't happen if you aren't using a custom scheme handler. If your XHR is just to some binary file like an image it works fine regardless of size. So it doesn't appear to be a Chromium issue itself.

It's like the thread/task that is responsible for calling ReadResponse just hangs or dies in the blob case. Again, only on Mac and Linux and only for files 65536 bytes or bigger.

We have a workaround of not using the "blob" type. I have tried to mangle the CEF client to simulate this but haven't had luck as it doesn't do the threading the same way I do. I'm also trying to build Chromium/Cef on mac to see if I can debug it. I've spent a ton of time on this so I'm running out of steam to come up with a simple test case to file an issue with.

I'm posting this so if someone else runs into it we can add to it. Also I'm wondering if this is some sort of known issue with blob handling. Otherwise, I'll get around to filing an issue once I have time to create a simple test case in the CefClient.

John

[Mayhew]

It "almost" seems like the code that handles processing the data from the ReadResponse call barfs when it deals with the initial 32768 bytes in the blob case when the total bytes to be processed is over 64K. Maybe its a buffer allocation crash in that task or an simply an unplemented case. Just a thought.