What is the desired behavior? This bug is due to https://chromium-review.googlesource.com/c/chromium/src/+/1352823 

Before that CL, if a user was on a LPR preview and reloaded, it would reload the preview and never be able to get back to the original.

I think the desired behavior would have the correct Reload type throughout the reload process (also keeping bypass cache when needed), so this isn't particular to how the bug affects HTTPS previews, but how HTTPS previews affects everything else.

I can't think of any way to do that without //content changes, any ideas?

With content changes
(1) All reloads navigate to the virtual URL
(2) Make NavigationHandleImpl query the NavigationEntry for IsReload and set the reload type on the NavigationEntry
(3) Something previews specific

Is it not possible to pass ReloadType in the open url params?

Not, it's not (https://cs.chromium.org/chromium/src/content/public/browser/page_navigator.h?l=34&rcl=e28f8726beb95a8a2f270c6779340ddb5bda219f) 

but I'll add that to the list of ideas.

I'm going to schedule some time with creis today or tomorrow and we'll go from there.

Yeah, we could add that as a param to the OpenURLParams struct. Seems like it belongs there (for the same reasons that ui::PageTransition  belongs there).

Also, ui::PageTransition enum has a value PAGE_TRANSITION_RELOAD. Can we not just set the ui::PageTransition in the OpenURLParams struct. Would that work? 

We already do set ui::PageTransition but according to Ryan that isn't enough

Right, so other option might be add logic somewhere (OpenURLParams or somewhere down) that reads PageTransition to set the ReloadType?

The page transition without reloadtype is basically a tab restore/s ssion restore. There are other parts of chrome that delineate the two behaviors I believe, but in previews we want to handle restores if possible.

Yeah, there could be different types of reloads. If it's not possible (and it's necessary) to compute the exact reload type from PageTransition, then it makes sense to pass ReloadType in OpenURLParams.

Hmm, reloads aren't going to be the only thing broken by canceling the old navigation and starting a new one.  There's a bunch of content-internal parameters that can't be passed through OpenURLParams and will be lost (e.g., NavigationDownloadPolicy, probably among many others).  We should perhaps think of a way to preserve the state from the previous NavigationRequest.  I've sent an email to start a discussion about it.

Refreshed during triage. Any updates here?

The best update here is that this will largely depend on the discussion and decisions around Issue 917145 which is a ~superset of this bug. 

Specifically for the reloading experiment, we may consider leaving this preview type out of the experiment.

> Specifically for the reloading experiment, we may consider leaving this preview type out of the experiment.

For the record, I believe we decided not to do this. We are planning to fix reloads in M73.