Set Ready For Review
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
PTAL when you have a chance, thanks!
Done
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
Sorry for the late review. Overall looks very good to me. I'll defer to lingqi@ for more detailed reviews.
(sorry for nitpicky comments)
// The PUS host was upgraded to full prerender.I'd like to avoid using "PUS" in codebase without explicit clarification. Can we change this to "prerender-until-script host"?
// speculation_action() without modifying the const attributes_.\`speculation_action()\` and \`attributes_\`
// This changes the behavior of should_pause_javascript_execution() and\`should_pause_javascript_execution()\` (adding back-quotes for code search)
// Set to true when this PUS host has been upgraded to a full prerender.Ditto: prerender-until-script
// crashed or the frame was destroyed, keep the host in PUS state (JSprerender-until-script
// Notify DevTools that the PUS attempt has been upgraded.prerender-until-script
// the existing PUS host will be upgraded to a full prerender.prerender-until-script
// same URL and the PUS host was started in an earlier update.prerender-until-script
// Check if we should upgrade an existing PUS host to full prerender.existing prerender-until-script (PUS) host
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Implement prerender-until-script to full prerender upgradeIn a follow-up CL, can you add WPTs?
PrerenderFinalStatus::kUpgradedToFullPrerender,Will the DevTools backend check the final status to determine if this is PUS upgrade and then update the UI?
I'm slightly concerned about this pattern, because actually `kUpgradedToFullPrerender` is not a final status, but it's just used for notifying the DevTools of the upgrade. Instead of that, I wonder if we should add a separate parameter.
To isolate the discussion about the DevTools protocol from this CL, can we move changes for DevTools to a follow-up CL, and leave TODO comments in this CL?