Fixit update: this might need some trial and error but it might still fit the 3 day limit.

One factor I was ignoring is that the download notification presented to the user is directly related to the existence of a RequestCoordinator request. So even for cases where a background downloaded is not needed/desired, the request might need to be created in case the download notification should be presented.

As I recall, our original thinking on this was to create a RequestCoordinator request right away, in case chrome gets killed before the foreground can render anything.  That required some of the logic to live in the RequestCoordinator, so this may be working the way we want it to already.

You are correct: the current behavior is what we want but there's still room for improvement. We can keep the behavior as is -- creating the request as soon as we confirm it is needed -- once we confirm in RecentTabHelper::ObserveAndDownloadCurrentPage that it is actually needed. This will still be advantegeous as we'll then be able to test for correct background download request creation (or absence of it) in RecentTabHelperTest (unit test).

And to further describe the work:

- Move the pertinent logic from offline_page_download_bridge.cc's SavePageIfNotNavigatedAway into RecentTabHelper::ObserveAndDownloadCurrentPage.

- Update RecentTabHelperTest tests (evaluate if new tests are needed) so to also verify that it is correctly creating background download requests when needed.