summaryrefslogtreecommitdiffstats
path: root/cc/test/fake_scrollbar.h
diff options
context:
space:
mode:
authordfalcantara <dfalcantara@chromium.org>2015-07-10 11:14:16 -0700
committerCommit bot <commit-bot@chromium.org>2015-07-10 18:14:50 +0000
commite6b7b46750d4a54a4005882a19d48334e5a9f628 (patch)
tree650c29e3e2dfed14136cbc175ddd245d6084007b /cc/test/fake_scrollbar.h
parent418274a8890f9af8dd24fa49e8ca47a319b39ec8 (diff)
downloadchromium_src-e6b7b46750d4a54a4005882a19d48334e5a9f628.zip
chromium_src-e6b7b46750d4a54a4005882a19d48334e5a9f628.tar.gz
chromium_src-e6b7b46750d4a54a4005882a19d48334e5a9f628.tar.bz2
Track whether a created WebContents has a resume pending.
On Android, it's possible that a WebContents is created and cannot be loaded immediately, which occurs when Chrome needs to start an Activity asynchronously. There's currently no good way to know when the WebContents is in this state, though. * Start storing whether the WebContents has needs to resume loading in the WebContentsImpl, which can then be checked when the WebContentsImpl may begin accepting requests from the renderer. * Clean up Android code that heuristically tracks whether the WebContents could be in this state. * Existing Java and Chromium tests catch regressions. BUG=508186 Review URL: https://codereview.chromium.org/1214723012 Cr-Commit-Position: refs/heads/master@{#338323}
Diffstat (limited to 'cc/test/fake_scrollbar.h')
0 files changed, 0 insertions, 0 deletions