1 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
2 // Use of this source code is governed by a BSD-style license that can be
3 // found in the LICENSE file.
5 #include "content/browser/webui/url_data_source_impl.h"
8 #include "base/memory/ref_counted_memory.h"
9 #include "base/strings/string_util.h"
10 #include "content/browser/webui/url_data_manager_backend.h"
11 #include "content/public/browser/browser_thread.h"
12 #include "content/public/browser/url_data_source.h"
16 URLDataSourceImpl::URLDataSourceImpl(const std::string
& source_name
,
17 URLDataSource
* source
)
18 : source_name_(source_name
),
23 URLDataSourceImpl::~URLDataSourceImpl() {
26 void URLDataSourceImpl::SendResponse(
28 base::RefCountedMemory
* bytes
) {
29 // Take a ref-pointer on entry so byte->Release() will always get called.
30 scoped_refptr
<base::RefCountedMemory
> bytes_ptr(bytes
);
31 if (URLDataManager::IsScheduledForDeletion(this)) {
32 // We're scheduled for deletion. Servicing the request would result in
33 // this->AddRef being invoked, even though the ref count is 0 and 'this' is
34 // about to be deleted. If the AddRef were allowed through, when 'this' is
35 // released it would be deleted again.
37 // This scenario occurs with DataSources that make history requests. Such
38 // DataSources do a history query in |StartDataRequest| and the request is
39 // live until the object is deleted (history requests don't up the ref
40 // count). This means it's entirely possible for the DataSource to invoke
41 // |SendResponse| between the time when there are no more refs and the time
42 // when the object is deleted.
45 BrowserThread::PostTask(
46 BrowserThread::IO
, FROM_HERE
,
47 base::Bind(&URLDataSourceImpl::SendResponseOnIOThread
, this, request_id
,
51 void URLDataSourceImpl::SendResponseOnIOThread(
53 scoped_refptr
<base::RefCountedMemory
> bytes
) {
54 DCHECK(BrowserThread::CurrentlyOn(BrowserThread::IO
));
56 backend_
->DataAvailable(request_id
, bytes
.get());
59 } // namespace content