diff options
author | dfalcantara <dfalcantara@chromium.org> | 2015-07-10 11:14:16 -0700 |
---|---|---|
committer | Commit bot <commit-bot@chromium.org> | 2015-07-10 18:14:50 +0000 |
commit | e6b7b46750d4a54a4005882a19d48334e5a9f628 (patch) | |
tree | 650c29e3e2dfed14136cbc175ddd245d6084007b /cc/test/fake_scrollbar.h | |
parent | 418274a8890f9af8dd24fa49e8ca47a319b39ec8 (diff) | |
download | chromium_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