Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
701953006:
PlzNavigate: Speculatively spawns a renderer process for navigations. (Closed)
|
Created:
6 years, 1 month ago by carlosk Modified:
5 years, 11 months ago CC:
chromium-reviews, darin-cc_chromium.org, nasko+codewatch_chromium.org, jam, creis+watch_chromium.org, ajwong+watch_chromium.org Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionSpeculatively spawns a renderer process for navigations.
Uses a RenderFrameHost instance to hold the reference to the respective
SiteInstance and its pre-spawned renderer process.
BUG=376094
Committed: https://crrev.com/39337115364bd37da597ae90a023b0a31df9b370
Cr-Commit-Position: refs/heads/master@{#311549}
Patch Set 1 #
Total comments: 34
Patch Set 2 : Addressed creis comments. #
Total comments: 37
Patch Set 3 : Addressed CR comments, added simple test, other minor changes. #
Total comments: 4
Patch Set 4 : Merged back the code paths for RFH creation in RFHM; other related changes. #Patch Set 5 : PlzNavigate sets the new RFH at commit time; independent of pending_*. #Patch Set 6 : Reverted SiteInstance creation changes for navigations. #Patch Set 7 : When navigating checks if the current WebUI can be reused. #
Total comments: 76
Patch Set 8 : Addressed lots of CR comments: mostly renames, moves, reverts and minor changes. #Patch Set 9 : Uploading the base changes from crrev.com/753173002. #Patch Set 10 : Re-applying previous changes over. #
Total comments: 22
Patch Set 11 : Uploading the base changes from crrev.com/753173002. #Patch Set 12 : Re-applied full CL changes, addressed comments, rebased, added tests and fixes. #
Total comments: 1
Patch Set 13 : Minor update to tests: new expects and comments. #Patch Set 14 : Fixed flakyness of tests that relied on unsafe pointer comparisons. #
Total comments: 15
Patch Set 15 : Address CR comments and fix possible RFH double swap out. #
Total comments: 107
Patch Set 16 : Updated tests and refactored code based on CR comments. #
Total comments: 57
Patch Set 17 : Rebase and changes from CR comments. #
Total comments: 34
Patch Set 18 : Rebase and one more round of CR work. #
Total comments: 35
Patch Set 19 : Rebase. #Patch Set 20 : Addressed latest round of review comments. #Patch Set 21 : Fixed missing references to |base| namespace. #
Total comments: 10
Patch Set 22 : Addressed last round of CR comments. #
Total comments: 71
Patch Set 23 : Addressed CR comments, mostly -- but not all -- nits. #
Total comments: 6
Patch Set 24 : Addressed CR comments. #
Total comments: 71
Patch Set 25 : Rebase #Patch Set 26 : Address CR comments.. #
Total comments: 4
Patch Set 27 : Changes in reply to latest round of comments. #Patch Set 28 : Latest changes due to review comments. #
Total comments: 72
Patch Set 29 : Addressing latest comments from creis@. #
Total comments: 2
Patch Set 30 : A few minor changes. #Patch Set 31 : Rebase #
Total comments: 8
Patch Set 32 : Replaced "renderer" to something more meaningful in comments. #Messages
Total messages: 90 (14 generated)
carlosk@chromium.org changed reviewers: + clamy@chromium.org, creis@chromium.org, nasko@chromium.org, pasko@chromium.org
creis, nasko: PTAL pasko, clamy: FYI The core of the logic lives in RenderFrameHostManager. I reused/extracted code whenever I could but there's some copy/paste from the current navigation logic. These should be "resolved" once we fully move to browser side navigation. To hold the reference to the speculatively spawned renderer I am using a RenderFrameHost instance. This made me have to mimic the curent "pending RFH" logic quite a bit. I did this as best as I could, simplifying things whenever it seemed appropriate and adding a few TODOs. I might have missed something though. I had to disable 3 of the browser side navigation tests. They now breake or crash due to these changes whether because they depend on the pending RFH instance to exist or because the current navigation test support code doesn't work anymore for browser side navigations. I will work on fixing that next (and also adding tests to this feature). But I want to get feedback on these changes ASAP and that's why I'm putting this up for review even before working on the tests. Some TODOs are there as questions for the reviewers, it should be clear when you see them. I also added a few comments with questions and explanations. One can test this code by running the content shell and enabling browser side navigations: cr run content_shell --enable-browser-side-navigation PS: If you find any formatting weird, blame it on git cl format. https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... File content/browser/frame_host/render_frame_host_manager.cc (left): https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.cc:918: I already added this back locally. https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.cc:1504: I already added this back locally. https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.cc:1543: I already added this back locally. https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.cc:588: // SwapOutOldFrame and we should see that these are unified at some point. SwapOutOldFrame does all of this (extracted from CancelPending with a few modifications) and more. And it's because of the "more" part that I was unsure if I could just merge both into the same. It might make sense to at least make SwapOutOldFrame call into RecycleRenderFrameHost for the common part. https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.cc:782: // TODO(carlosk): find out if this should be called here or only later on. This is also a question to reviewers... https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.cc:1452: for_main_frame_navigation); IDK why but git cl format decided that this should be changed...
A couple more comments/questions: * There's a public getter for the pending RFH in RFHM and it's not only for tests. We will most probably have to take care of those as well at some point https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/fr... * Nasko asked me previously to not use the pending RFH structure and that's why I moved away from it. But in the cases where the speculative RFH is not used won't we have to do the whole pending logic anyway?
Thanks. I definitely agree that we should have a speculative RFH and not just a SiteInstance / process. I haven't looked closely at the actual code for doing the speculative RFH creation and swap yet, since I have some other high level questions that may affect it. On 2014/11/05 16:54:56, carlosk wrote: > A couple more comments/questions: > > * There's a public getter for the pending RFH in RFHM and it's not only for > tests. We will most probably have to take care of those as well at some point > https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/fr... > > * Nasko asked me previously to not use the pending RFH structure and that's why > I moved away from it. But in the cases where the speculative RFH is not used > won't we have to do the whole pending logic anyway? Why would we need a pending RFH in PlzNavigate? Pending RFHs are there in the old flow so that we can issue a navigation from them, wait for it to be ready to commit, and then swap them in. With PlzNavigate, if a speculative RFH isn't used, we don't need to create the new RFH until commit time, when it's possible to immediately make it our current one. In other words, pending RFH is required for the old flow, but PlzNavigate should never use it. PlzNavigate doesn't need the speculative RFH to work, but it offers an optimization if it's succesful. https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/n... File content/browser/frame_host/navigator_impl.cc (right): https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/n... content/browser/frame_host/navigator_impl.cc:741: frame_tree_node->render_manager()->WillBeginNavigating(params, common_params); nit: Let's keep with the existing naming scheme to have fewer names to keep track of. This should be RFHM::BeginNavigation. https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/n... content/browser/frame_host/navigator_impl.cc:784: frame_tree_node->render_manager()->CleanUpCurrentNavigation(); RFHM::CancelNavigation https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.cc:588: // SwapOutOldFrame and we should see that these are unified at some point. On 2014/11/05 16:45:44, carlosk wrote: > SwapOutOldFrame does all of this (extracted from CancelPending with a few > modifications) and more. And it's because of the "more" part that I was unsure > if I could just merge both into the same. It might make sense to at least make > SwapOutOldFrame call into RecycleRenderFrameHost for the common part. I would also like to see this code unified. We can return to that in a later round of review. https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.h:24: struct FrameHostMsg_BeginNavigation_Params; nit: Alphabetize https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.h:36: class RenderFrameHost; This is a duplicate. (Wonder how it snuck in twice before.) https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.h:372: // it can do stuff in advance like trying to speculatively spawn a new Drop "do stuff in advance like trying to" https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.h:432: bool create_unbounded_site_instance); unbounded isn't the right word, but I also think we shouldn't have this concept (see my comment in SiteInstanceImpl). https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.h:448: SiteInstance* CreateSiteInstanceForURL(BrowserContext* browser_context, I'm hoping we can avoid these methods (see SiteInstanceImpl). https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.h:481: // This new instance might be later destroyed if the final navigation new instance -> RenderFrameHost https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.h:506: void CommitPending(bool use_speculative_rfh); Let's give a second paragraph in the comment about how this behaves for PlzNavigate, and clarify that |use_speculative_rfh| is only used in that case (and pending RFHs aren't). https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.h:515: void RecycleRenderFrameHost( If we need this, we should use a more common name (e.g., DestroyRenderFrameHost) rather than recycle/execute. https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.h:624: // Members to store the speculative RFH created upon starting a navigation Important: Preface this with "PlzNavigate" and make it clear that speculative RFHs and pending RFHs are mutually exclusive approaches (i.e., we only use pending RFHs for default behavior and only use speculative RFHs in PlzNavigate). https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.h:626: // Might be discarded later on if the final URL's SiteInstnace mismatches nit: SiteInstance nit: doesn't match https://codereview.chromium.org/701953006/diff/1/content/browser/site_instanc... File content/browser/site_instance_impl.h (right): https://codereview.chromium.org/701953006/diff/1/content/browser/site_instanc... content/browser/site_instance_impl.h:90: SiteInstance* GetRelatedEmptySiteInstance(); This isn't safe to add, and it's movement in the wrong direction. It implies that we will later assign a site to the SiteInstance, but we might then find out that we already have a SiteInstance for that site in the BrowsingInstance. If anything, PlzNavigate should be moving us towards *always* assigning the site of a SiteInstance upon construction, such that HasSite never returns false and can be removed.
Also, please mention PlzNavigate in the CL description.
On 2014/11/05 17:50:02, Charlie Reis wrote: > Thanks. I definitely agree that we should have a speculative RFH and not just a > SiteInstance / process. > > I haven't looked closely at the actual code for doing the speculative RFH > creation and swap yet, since I have some other high level questions that may > affect it. > > On 2014/11/05 16:54:56, carlosk wrote: > > A couple more comments/questions: > > > > * There's a public getter for the pending RFH in RFHM and it's not only for > > tests. We will most probably have to take care of those as well at some point > > > https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/fr... > > > > * Nasko asked me previously to not use the pending RFH structure and that's > why > > I moved away from it. But in the cases where the speculative RFH is not used > > won't we have to do the whole pending logic anyway? > > Why would we need a pending RFH in PlzNavigate? Pending RFHs are there in the > old flow so that we can issue a navigation from them, wait for it to be ready to > commit, and then swap them in. With PlzNavigate, if a speculative RFH isn't > used, we don't need to create the new RFH until commit time, when it's possible > to immediately make it our current one. > > In other words, pending RFH is required for the old flow, but PlzNavigate should > never use it. PlzNavigate doesn't need the speculative RFH to work, but it > offers an optimization if it's succesful. Now that you phrased it this way and with the knowledge I built out of making these changes I think I finally understand what not having a pending RFH actually involves. Then the question is: should I execute this extra change in this CL or in a following one? Right now the system works in the case where the speculative RFH is discarded by using the pending RFH logic (like it used to do before). So it doesn't need to be done right now but I certainly can do it if you deem it better. On 2014/11/05 18:15:09, Charlie Reis wrote: > Also, please mention PlzNavigate in the CL description. Done. https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/n... File content/browser/frame_host/navigator_impl.cc (right): https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/n... content/browser/frame_host/navigator_impl.cc:741: frame_tree_node->render_manager()->WillBeginNavigating(params, common_params); On 2014/11/05 17:50:00, Charlie Reis wrote: > nit: Let's keep with the existing naming scheme to have fewer names to keep > track of. This should be RFHM::BeginNavigation. Done. https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/n... content/browser/frame_host/navigator_impl.cc:784: frame_tree_node->render_manager()->CleanUpCurrentNavigation(); On 2014/11/05 17:50:01, Charlie Reis wrote: > RFHM::CancelNavigation Done. I still wanted to have a method to clean-up the speculative data so I renamed this one to CleanUpSpeculativeRenderFrameHost, made it private and created a new one called CancelNavigation that currently just calls the former. https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.cc:588: // SwapOutOldFrame and we should see that these are unified at some point. On 2014/11/05 17:50:01, Charlie Reis wrote: > On 2014/11/05 16:45:44, carlosk wrote: > > SwapOutOldFrame does all of this (extracted from CancelPending with a few > > modifications) and more. And it's because of the "more" part that I was unsure > > if I could just merge both into the same. It might make sense to at least make > > SwapOutOldFrame call into RecycleRenderFrameHost for the common part. > > I would also like to see this code unified. We can return to that in a later > round of review. Acknowledged. https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.h:24: struct FrameHostMsg_BeginNavigation_Params; On 2014/11/05 17:50:01, Charlie Reis wrote: > nit: Alphabetize Done. https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.h:36: class RenderFrameHost; On 2014/11/05 17:50:01, Charlie Reis wrote: > This is a duplicate. (Wonder how it snuck in twice before.) Done. I wonder why the compiler didn't complain... https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.h:372: // it can do stuff in advance like trying to speculatively spawn a new On 2014/11/05 17:50:01, Charlie Reis wrote: > Drop "do stuff in advance like trying to" Done. That one fell through the gaps of my "let's turn this prototype into real code" review. :) https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.h:432: bool create_unbounded_site_instance); On 2014/11/05 17:50:01, Charlie Reis wrote: > unbounded isn't the right word, but I also think we shouldn't have this concept > (see my comment in SiteInstanceImpl). Woudl "unset" be better? Or "without URL"? https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.h:448: SiteInstance* CreateSiteInstanceForURL(BrowserContext* browser_context, On 2014/11/05 17:50:01, Charlie Reis wrote: > I'm hoping we can avoid these methods (see SiteInstanceImpl). Acknowledged. https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.h:481: // This new instance might be later destroyed if the final navigation On 2014/11/05 17:50:01, Charlie Reis wrote: > new instance -> RenderFrameHost Done. https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.h:506: void CommitPending(bool use_speculative_rfh); On 2014/11/05 17:50:01, Charlie Reis wrote: > Let's give a second paragraph in the comment about how this behaves for > PlzNavigate, and clarify that |use_speculative_rfh| is only used in that case > (and pending RFHs aren't). Done. https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.h:515: void RecycleRenderFrameHost( On 2014/11/05 17:50:01, Charlie Reis wrote: > If we need this, we should use a more common name (e.g., DestroyRenderFrameHost) > rather than recycle/execute. As in fact the RFH might not be destroyed (when it's just swapped out) I was trying to name it in a way that didn't imply "destruction". Maybe my comment was not clear (?) so I updated it. https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.h:624: // Members to store the speculative RFH created upon starting a navigation On 2014/11/05 17:50:01, Charlie Reis wrote: > Important: Preface this with "PlzNavigate" and make it clear that speculative > RFHs and pending RFHs are mutually exclusive approaches (i.e., we only use > pending RFHs for default behavior and only use speculative RFHs in PlzNavigate). Done. Just made it clear that for now PlzNavigate and pendind_* instances are not yet mutually exclusive. https://codereview.chromium.org/701953006/diff/1/content/browser/frame_host/r... content/browser/frame_host/render_frame_host_manager.h:626: // Might be discarded later on if the final URL's SiteInstnace mismatches On 2014/11/05 17:50:01, Charlie Reis wrote: > nit: SiteInstance > nit: doesn't match Done. https://codereview.chromium.org/701953006/diff/1/content/browser/site_instanc... File content/browser/site_instance_impl.h (right): https://codereview.chromium.org/701953006/diff/1/content/browser/site_instanc... content/browser/site_instance_impl.h:90: SiteInstance* GetRelatedEmptySiteInstance(); On 2014/11/05 17:50:01, Charlie Reis wrote: > This isn't safe to add, and it's movement in the wrong direction. It implies > that we will later assign a site to the SiteInstance, but we might then find out > that we already have a SiteInstance for that site in the BrowsingInstance. > > If anything, PlzNavigate should be moving us towards *always* assigning the site > of a SiteInstance upon construction, such that HasSite never returns false and > can be removed. The problem I see with that approach is that it will cause the discard of the speculative RFH in any situation where the initial URL is not exactly the same as the last. I understand there are risks. I did add several checks towards controlling that within the RFHM code (see CreateSiteInstanceForURL and GetRelatedSiteInstanceForURL for the case we have a speculative RFH with an unbounded SiteInstance). As a last stand I also added a DCHECK in SiteInstanceImpl::SetSite for this specific case. We could also "upgrade" this DCHECK into a CHECK or even make SetSite return a boolean and avoid the setting of the site in these situations.
On 2014/11/05 20:28:59, carlosk wrote: > On 2014/11/05 17:50:02, Charlie Reis wrote: > > Thanks. I definitely agree that we should have a speculative RFH and not just > a > > SiteInstance / process. > > > > I haven't looked closely at the actual code for doing the speculative RFH > > creation and swap yet, since I have some other high level questions that may > > affect it. > > > > On 2014/11/05 16:54:56, carlosk wrote: > > > A couple more comments/questions: > > > > > > * There's a public getter for the pending RFH in RFHM and it's not only for > > > tests. We will most probably have to take care of those as well at some > point > > > > > > https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/fr... > > > > > > * Nasko asked me previously to not use the pending RFH structure and that's > > why > > > I moved away from it. But in the cases where the speculative RFH is not used > > > won't we have to do the whole pending logic anyway? > > > > Why would we need a pending RFH in PlzNavigate? Pending RFHs are there in the > > old flow so that we can issue a navigation from them, wait for it to be ready > to > > commit, and then swap them in. With PlzNavigate, if a speculative RFH isn't > > used, we don't need to create the new RFH until commit time, when it's > possible > > to immediately make it our current one. > > > > In other words, pending RFH is required for the old flow, but PlzNavigate > should > > never use it. PlzNavigate doesn't need the speculative RFH to work, but it > > offers an optimization if it's succesful. > > Now that you phrased it this way and with the knowledge I built out of making > these changes I think I finally understand what not having a pending RFH > actually involves. > > Then the question is: should I execute this extra change in this CL or in a > following one? Right now the system works in the case where the speculative RFH > is discarded by using the pending RFH logic (like it used to do before). So it > doesn't need to be done right now but I certainly can do it if you deem it > better. Yes, let's try to take care of the speculative / pending split in this CL. I've been trying to get a deeper understanding of the rest, but unfortunately I need to head out for the day. Our team also has a hackathon Thursday/Friday, so I won't have much time for this until Monday. At a high level, I see that you're trying to safely create unassigned SiteInstances, but I continue to worry about the subtlety there. One of the main goals of PlzNavigate is to end up with a simpler code path for navigation, and I'm not sure that we want to keep the complexity of SiteInstances without sites. This is especially true as we move towards Site Isolation, where we may need to lock down a renderer process's access to cookies and other site-specific data at a very early point in time (in which case redirects do require a security context change). Don't change that just yet, though; I want to spend some time weighing the alternatives more closely.
On 2014/11/06 01:09:10, Charlie Reis wrote: > On 2014/11/05 20:28:59, carlosk wrote: > > On 2014/11/05 17:50:02, Charlie Reis wrote: > > > Thanks. I definitely agree that we should have a speculative RFH and not > just > > a > > > SiteInstance / process. > > > > > > I haven't looked closely at the actual code for doing the speculative RFH > > > creation and swap yet, since I have some other high level questions that may > > > affect it. > > > > > > On 2014/11/05 16:54:56, carlosk wrote: > > > > A couple more comments/questions: > > > > > > > > * There's a public getter for the pending RFH in RFHM and it's not only > for > > > > tests. We will most probably have to take care of those as well at some > > point > > > > > > > > > > https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/fr... > > > > > > > > * Nasko asked me previously to not use the pending RFH structure and > that's > > > why > > > > I moved away from it. But in the cases where the speculative RFH is not > used > > > > won't we have to do the whole pending logic anyway? > > > > > > Why would we need a pending RFH in PlzNavigate? Pending RFHs are there in > the > > > old flow so that we can issue a navigation from them, wait for it to be > ready > > to > > > commit, and then swap them in. With PlzNavigate, if a speculative RFH isn't > > > used, we don't need to create the new RFH until commit time, when it's > > possible > > > to immediately make it our current one. > > > > > > In other words, pending RFH is required for the old flow, but PlzNavigate > > should > > > never use it. PlzNavigate doesn't need the speculative RFH to work, but it > > > offers an optimization if it's succesful. > > > > Now that you phrased it this way and with the knowledge I built out of making > > these changes I think I finally understand what not having a pending RFH > > actually involves. > > > > Then the question is: should I execute this extra change in this CL or in a > > following one? Right now the system works in the case where the speculative > RFH > > is discarded by using the pending RFH logic (like it used to do before). So it > > doesn't need to be done right now but I certainly can do it if you deem it > > better. > > Yes, let's try to take care of the speculative / pending split in this CL. > > I've been trying to get a deeper understanding of the rest, but unfortunately I > need to head out for the day. Our team also has a hackathon Thursday/Friday, so > I won't have much time for this until Monday. > > At a high level, I see that you're trying to safely create unassigned > SiteInstances, but I continue to worry about the subtlety there. One of the > main goals of PlzNavigate is to end up with a simpler code path for navigation, > and I'm not sure that we want to keep the complexity of SiteInstances without > sites. This is especially true as we move towards Site Isolation, where we may > need to lock down a renderer process's access to cookies and other site-specific > data at a very early point in time (in which case redirects do require a > security context change). Don't change that just yet, though; I want to spend > some time weighing the alternatives more closely. Sounds good. I'll then work on removing the pending_* dependency when PlzNavigate is enabled and also on adding at least a few tests of the new system to try and make it clearer how it works. I also owe a proper design doc on this change... I also realized I was wrong in my reply to your comment: we will not lose the speculative RFH for just any change of URL during navigation. We will for all cases where the change requires a different SiteInstance. For instance, if I type "wikipedia.org" and end up in "http://www.wikipedia.org/" it should be alright as both would fall under the same SI. Nonetheless, we would still throw away the speculative RFH for all navigations that don't keep the same SI. As link shortening sees such widespread usage today I think it'd be a considerable hit. I'll try to find metrics that could help estimating the impact it would cause.
"(...) This is especially true as we move towards Site Isolation, where we may need to lock down a renderer process's access to cookies and other site-specific data at a very early point in time" Is there any documentation I can look at and refer to on why is this important and needed?
A bunch of comments. I know this is still very much work in progress, but at some point it will be useful to add some tests. Overall I think it will be best for us to create the RFH with a SiteInstance that properly reflects the URL of the navigation. If we get redirected to a different SiteInstance, the optimization doesn't work. We can measure how often this occurs and figure out if we need to optimize this even further later on. It will be easier to reason about the correctness of the code if we don't layer even more new concepts that we might not need. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.cc:653: // If there is an ongoing navigation, just clean it up. Semantically, we should be cancelling an existing navigation, which might or might not be doing the cleanup. I'd suggest calling CancelNavigation and having that method do the proper thing, which it already does : ). https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.cc:671: if (!success) { nit: no need for {} when you have one line if statement. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.cc:677: // TODO(carlosk): do I need to AddPendingView() in this case as well??? You shouldn't need to. This accounts for browser-side accounting and we aren't recreating anything on the browser side for this RFH. The code that follows will ensure that the renderer side object is properly created and alive. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.cc:695: const GURL& url, SiteInstance* old_instance, SiteInstance* new_instance) { nit: params each on its own line https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.cc:787: // navigation or only later? This should probably be called here. Longer term it will be nice to ensure RenderFrameCreated is a bit more meaningful, but it is outside of the scope of this work for now. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.cc:1190: if (speculative_render_frame_host_) { Why would this condition be hit? If there is a speculative RFH, this means we have already passed the Create* methods and are in the middle of navigation. If this is a new navigation, we should've cancelled the existing one. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.cc:1508: DCHECK(!use_speculative_rfh || nit: CHECK https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.cc:1700: CleanUpSpeculativeRenderFrameHost(); All of the sprinkled calls for CleanUpSpeculativeRenderFrameHost match closely with CancelPending calls. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.h:23: struct FrameHostMsg_BeginNavigation_Params; Why are these structs outside of the content namespace? https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.h:481: // This RenderFrameHost might be later destroyed if the final navigation nit: swap the ordering of "later" and "destroyed" https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.h:510: // With PlzNavigate enabled, |use_speculative_rfh| can be set to true what nit: s/what/which/ https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.h:520: // active (for active ones SwapOutOldFrame is used instead). It can whether be nit: s/whether//
On 2014/11/06 10:56:31, carlosk wrote: > Sounds good. I'll then work on removing the pending_* dependency when > PlzNavigate is enabled and also on adding at least a few tests of the new system > to try and make it clearer how it works. I also owe a proper design doc on this > change... > > I also realized I was wrong in my reply to your comment: we will not lose the > speculative RFH for just any change of URL during navigation. We will for all > cases where the change requires a different SiteInstance. For instance, if I > type "wikipedia.org" and end up in "http://www.wikipedia.org/" it should be > alright as both would fall under the same SI. > > Nonetheless, we would still throw away the speculative RFH for all navigations > that don't keep the same SI. As link shortening sees such widespread usage today > I think it'd be a considerable hit. I'll try to find metrics that could help > estimating the impact it would cause. True, but I don't think we'll need to care about that with where we're heading. I'm finishing a proposal to make the SiteInstance's site URL more meaningful, which will put most web site URLs in a generic "web" principal (likely just an empty GURL). Thus, most redirects will stay in the same SiteInstance. The site URL will only be non-empty if we're actually isolating that site securely, at least once Site Isolation launches. For details, see this doc (with your chromium.org account): https://docs.google.com/document/d/1ND9j2_XzQvzvIckHnuInStJptF62NrqN9iUdH-sMH... On 2014/11/06 12:54:17, carlosk wrote: > "(...) This is especially true as we move towards Site Isolation, where we may > need to lock down a renderer process's access to cookies and other site-specific > data at a very early point in time" > > Is there any documentation I can look at and refer to on why is this important > and needed? Not really, unfortunately. There's some partly-relevant info from our previous effort to put certain sites in their own Storage Partition, but that project was cancelled in favor of the full Site Isolation effort: http://www.chromium.org/developers/design-documents/isolated-sites The main similarity is that we'll want to lock down the RenderProcessHost's access to cookies, HTML5 storage, passwords, etc, as soon as it launches. (We won't be using StoragePartitions for it, though.) You can also consider this somewhat similar to how we assign the site of an extension SiteInstance when starting the navigation, rather than at commit time. That affects the bindings and the extension process management logic.
Thanks! A few comments after the first read-through. On the subject of the pending render frame host, how does getting rid of it works with swapping the old one out. Currently we do: CommitNavigation -> maybe create a new RFH and put it in pending -> Render Frame commits navigation -> RFHM::DidNavigate -> swap out old renderer. In a version where we don't have a pending RFH, do we swap out the old one right at CommitNavigation, or do we store whatever RFH will commit the navigation in the speculative RFH (which is no longer speculative at this point) and swap this one in RFHM::DidNavigate. Personally, I find option 1 to be better, wdyt? https://chromiumcodereview.appspot.com/701953006/diff/20001/content/browser/f... File content/browser/frame_host/navigator_impl.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/20001/content/browser/f... content/browser/frame_host/navigator_impl.cc:741: frame_tree_node->render_manager()->BeginNavigation(params, common_params); Following the performance issues due to spawning a new RFH, shouldn't this take place after the call to navigation_request->BeginNavigation? https://chromiumcodereview.appspot.com/701953006/diff/20001/content/browser/f... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/20001/content/browser/f... content/browser/frame_host/navigator_impl_unittest.cc:175: // changes from speculative renderer creation. Apart from fixing this, it would also be good to add unit tests for the speculative renderer spawning. https://chromiumcodereview.appspot.com/701953006/diff/20001/content/browser/f... File content/browser/frame_host/render_frame_host_manager.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/20001/content/browser/f... content/browser/frame_host/render_frame_host_manager.cc:694: bool RenderFrameHostManager::CreateSpeculativeRenderFrameHost( As mentioned offline, it would be good if this was shared with CreateRenderFrame instead of being copied. https://chromiumcodereview.appspot.com/701953006/diff/20001/content/browser/f... content/browser/frame_host/render_frame_host_manager.cc:1697: if (speculative_render_frame_host_->GetSiteInstance() == new_instance) { nit: no need for braces. https://chromiumcodereview.appspot.com/701953006/diff/20001/content/browser/f... content/browser/frame_host/render_frame_host_manager.cc:1856: if (speculative_web_ui_) { nit: no need for braces. https://chromiumcodereview.appspot.com/701953006/diff/20001/content/browser/f... File content/browser/frame_host/render_frame_host_manager.h (right): https://chromiumcodereview.appspot.com/701953006/diff/20001/content/browser/f... content/browser/frame_host/render_frame_host_manager.h:23: struct FrameHostMsg_BeginNavigation_Params; On 2014/11/10 17:35:31, nasko wrote: > Why are these structs outside of the content namespace? They are defined that way in frame_messages.h (and so are resource_messages.h). https://chromiumcodereview.appspot.com/701953006/diff/20001/content/browser/f... content/browser/frame_host/render_frame_host_manager.h:372: // speculatively spawn a new renderer process. nit: add "if needed" at the end of the comment.
On 2014/11/12 13:01:14, clamy wrote: > Thanks! A few comments after the first read-through. > > On the subject of the pending render frame host, how does getting rid of it > works with swapping the old one out. Currently we do: > CommitNavigation -> maybe create a new RFH and put it in pending -> Render Frame > commits navigation -> RFHM::DidNavigate -> swap out old renderer. In a version > where we don't have a pending RFH, do we swap out the old one right at > CommitNavigation, or do we store whatever RFH will commit the navigation in the > speculative RFH (which is no longer speculative at this point) and swap this one > in RFHM::DidNavigate. Personally, I find option 1 to be better, wdyt? As discussed today, I think we should swap at CommitNavigation time, as this is the time where the new RFH becomes effective and RFHM::DidNavigate skips the CommitPending part, as there is no pending RFH. The only possible issue is painting white between CommitNavigation and the time first paint of the new document is complete.
Thanks for all comments so far. I am still working on a design doc for this work but I'm already sharing it with you for feedback (comments allowed with Chromium account): https://docs.google.com/a/chromium.org/document/d/1d3NhCFK79imXBO_S-qN16XYLS1... On 2014/11/10 17:35:32, nasko wrote: > A bunch of comments. I know this is still very much work in progress, but at > some point it will be useful to add some tests. I am already working on the tests and clamy@ will also work on improving the test fixtures we have in place so to ease the writing of PlzNavigate tests. This last patchset has the most basic one which is still not ideal (see TODOs). > Overall I think it will be best for us to create the RFH with a SiteInstance > that properly reflects the URL of the navigation. If we get redirected to a > different SiteInstance, the optimization doesn't work. We can measure how often > this occurs and figure out if we need to optimize this even further later on. It > will be easier to reason about the correctness of the code if we don't layer > even more new concepts that we might not need. Yes, more details next for the reply to creis@. And yes, we must keep track of how successful speculative spawning is. On 2014/11/11 00:51:28, Charlie Reis wrote: > On 2014/11/06 10:56:31, carlosk wrote: > > Sounds good. I'll then work on removing the pending_* dependency when > > PlzNavigate is enabled and also on adding at least a few tests of the new > system > > to try and make it clearer how it works. I also owe a proper design doc on > this > > change... > > > > I also realized I was wrong in my reply to your comment: we will not lose the > > speculative RFH for just any change of URL during navigation. We will for all > > cases where the change requires a different SiteInstance. For instance, if I > > type "wikipedia.org" and end up in "http://www.wikipedia.org/" it should be > > alright as both would fall under the same SI. > > > > Nonetheless, we would still throw away the speculative RFH for all navigations > > that don't keep the same SI. As link shortening sees such widespread usage > today > > I think it'd be a considerable hit. I'll try to find metrics that could help > > estimating the impact it would cause. > > True, but I don't think we'll need to care about that with where we're heading. > I'm finishing a proposal to make the SiteInstance's site URL more meaningful, > which will put most web site URLs in a generic "web" principal (likely just an > empty GURL). Thus, most redirects will stay in the same SiteInstance. The site > URL will only be non-empty if we're actually isolating that site securely, at > least once Site Isolation launches. > > For details, see this doc (with your http://chromium.org account): > https://docs.google.com/document/d/1ND9j2_XzQvzvIckHnuInStJptF62NrqN9iUdH-sMH... Indeed it seems that with that change it would even improve the success rate of the speculative RFH as it should make matching SiteInstance's easier. I'd even like to set the issue you'd create for it as a dependency of this one. > On 2014/11/06 12:54:17, carlosk wrote: > > "(...) This is especially true as we move towards Site Isolation, where we may > > need to lock down a renderer process's access to cookies and other > site-specific > > data at a very early point in time" > > > > Is there any documentation I can look at and refer to on why is this important > > and needed? > > Not really, unfortunately. There's some partly-relevant info from our previous > effort to put certain sites in their own Storage Partition, but that project was > cancelled in favor of the full Site Isolation effort: > http://www.chromium.org/developers/design-documents/isolated-sites > > The main similarity is that we'll want to lock down the RenderProcessHost's > access to cookies, HTML5 storage, passwords, etc, as soon as it launches. (We > won't be using StoragePartitions for it, though.) > > You can also consider this somewhat similar to how we assign the site of an > extension SiteInstance when starting the navigation, rather than at commit time. > That affects the bindings and the extension process management logic. Ack. On 2014/11/12 23:13:11, nasko wrote: > On 2014/11/12 13:01:14, clamy wrote: > > Thanks! A few comments after the first read-through. > > > > On the subject of the pending render frame host, how does getting rid of it > > works with swapping the old one out. Currently we do: > > CommitNavigation -> maybe create a new RFH and put it in pending -> Render > Frame > > commits navigation -> RFHM::DidNavigate -> swap out old renderer. In a version > > where we don't have a pending RFH, do we swap out the old one right at > > CommitNavigation, or do we store whatever RFH will commit the navigation in > the > > speculative RFH (which is no longer speculative at this point) and swap this > one > > in RFHM::DidNavigate. Personally, I find option 1 to be better, wdyt? > > As discussed today, I think we should swap at CommitNavigation time, as this is > the time where the new RFH becomes effective and RFHM::DidNavigate skips the > CommitPending part, as there is no pending RFH. The only possible issue is > painting white between CommitNavigation and the time first paint of the new > document is complete. I'll also work on this next (along with the consolidation of the RFH creation code mentioned below in a comment reply). https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... File content/browser/frame_host/navigator_impl.cc (right): https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/navigator_impl.cc:741: frame_tree_node->render_manager()->BeginNavigation(params, common_params); On 2014/11/12 13:01:13, clamy wrote: > Following the performance issues due to spawning a new RFH, shouldn't this take > place after the call to navigation_request->BeginNavigation? Yes! I had this already done locally once I realized work done here is message driven so there will be no way for this thread to handle the response from the IO thread before this call is done. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/navigator_impl_unittest.cc:175: // changes from speculative renderer creation. On 2014/11/12 13:01:13, clamy wrote: > Apart from fixing this, it would also be good to add unit tests for the > speculative renderer spawning. Acknowledged. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.cc:653: // If there is an ongoing navigation, just clean it up. On 2014/11/10 17:35:31, nasko wrote: > Semantically, we should be cancelling an existing navigation, which might or > might not be doing the cleanup. I'd suggest calling CancelNavigation and having > that method do the proper thing, which it already does : ). Done. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.cc:671: if (!success) { On 2014/11/10 17:35:31, nasko wrote: > nit: no need for {} when you have one line if statement. Done. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.cc:677: // TODO(carlosk): do I need to AddPendingView() in this case as well??? On 2014/11/10 17:35:31, nasko wrote: > You shouldn't need to. This accounts for browser-side accounting and we aren't > recreating anything on the browser side for this RFH. The code that follows will > ensure that the renderer side object is properly created and alive. Acknowledged. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.cc:694: bool RenderFrameHostManager::CreateSpeculativeRenderFrameHost( On 2014/11/12 13:01:13, clamy wrote: > As mentioned offline, it would be good if this was shared with CreateRenderFrame > instead of being copied. I'll be working on this next. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.cc:695: const GURL& url, SiteInstance* old_instance, SiteInstance* new_instance) { On 2014/11/10 17:35:31, nasko wrote: > nit: params each on its own line Done. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.cc:787: // navigation or only later? On 2014/11/10 17:35:31, nasko wrote: > This should probably be called here. Longer term it will be nice to ensure > RenderFrameCreated is a bit more meaningful, but it is outside of the scope of > this work for now. Acknowledged. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.cc:1190: if (speculative_render_frame_host_) { On 2014/11/10 17:35:31, nasko wrote: > Why would this condition be hit? If there is a speculative RFH, this means we > have already passed the Create* methods and are in the middle of navigation. If > this is a new navigation, we should've cancelled the existing one. This method is called twice during a navigation with PlzNavigate enabled. The 1st time, due to the call do BeginNavigation, create_unbounded_site_instance is true and so a new, site-unbound SiteInstance is created (if the URL being navigated to triggers that). In that case a speculative RFH would be created using this SiteInstance. The 2nd time, create_unbounded_site_instance is false. In that case if a speculative RFH was created int he 1st call its SiteInstance will be returned if the other checks that follow are successful. The reason why this goes down here is to check that the SiteInstance for the speculatively created RFH still matches the final URL. If it doesn't a new SiteInstance will be returned what will finally cause the speculative RFH to be trashed. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.cc:1508: DCHECK(!use_speculative_rfh || On 2014/11/10 17:35:31, nasko wrote: > nit: CHECK Done. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.cc:1697: if (speculative_render_frame_host_->GetSiteInstance() == new_instance) { On 2014/11/12 13:01:13, clamy wrote: > nit: no need for braces. Done. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.cc:1700: CleanUpSpeculativeRenderFrameHost(); On 2014/11/10 17:35:31, nasko wrote: > All of the sprinkled calls for CleanUpSpeculativeRenderFrameHost match closely > with CancelPending calls. In this case that's not true: if the SiteInstance of the speculative RFH doesn't match the one for the final URL we don't want to cancel the navigation. We want to trash the speculative data and create a new RFH to fulfill the navigation. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.cc:1856: if (speculative_web_ui_) { On 2014/11/12 13:01:13, clamy wrote: > nit: no need for braces. Done. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.h:23: struct FrameHostMsg_BeginNavigation_Params; On 2014/11/12 13:01:13, clamy wrote: > On 2014/11/10 17:35:31, nasko wrote: > > Why are these structs outside of the content namespace? > > They are defined that way in frame_messages.h (and so are resource_messages.h). Yes, that. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.h:372: // speculatively spawn a new renderer process. On 2014/11/12 13:01:13, clamy wrote: > nit: add "if needed" at the end of the comment. Done. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.h:481: // This RenderFrameHost might be later destroyed if the final navigation On 2014/11/10 17:35:32, nasko wrote: > nit: swap the ordering of "later" and "destroyed" Done. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.h:510: // With PlzNavigate enabled, |use_speculative_rfh| can be set to true what On 2014/11/10 17:35:32, nasko wrote: > nit: s/what/which/ Done. https://codereview.chromium.org/701953006/diff/20001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.h:520: // active (for active ones SwapOutOldFrame is used instead). It can whether be On 2014/11/10 17:35:32, nasko wrote: > nit: s/whether// Done.
I just realized there might still be an issue with SiteInstances even with creis@ proposal. If we initially create a RFH using a SI to "http://bit.ly/shortened-url" but finally are redirected to "http://wikipedia.org" these changes should still allow the initially created SI to be used. it seems to me that this would still require some sort of site-unbound SiteInstance creation, or maybe a way to "update" a SiteInstance's site later on iff it was not used yet to commit a navigation. Otherwise the initial SI wouldn't match the final one anyway and the RFH would have to be created anew. Sounds right?
On 2014/11/13 14:59:03, carlosk wrote: > I just realized there might still be an issue with SiteInstances even with > creis@ proposal. If we initially create a RFH using a SI to > "http://bit.ly/shortened-url" but finally are redirected to > "http://wikipedia.org" these changes should still allow the initially created SI > to be used. it seems to me that this would still require some sort of > site-unbound SiteInstance creation, or maybe a way to "update" a SiteInstance's > site later on iff it was not used yet to commit a navigation. > > Otherwise the initial SI wouldn't match the final one anyway and the RFH would > have to be created anew. Sounds right? I haven't looked at the rest of the updates yet, but I wanted to reply to this. With the proposal, both http://bit.ly/shortened-url and http://wikipedia.org would end up in the same generic "web" principal SiteInstance, with an empty site GURL. There's no need to swap SiteInstance or RFH on the server redirect. The same is not true for a bitly redirect link to a HTTPS site you've logged into (assuming we isolated it for --site-per-process). However, in that case a process swap is probably necessary, since we will likely end up needing different RenderMessageFilters on the RenderProcessHost to ensure they're locked to the new origin (e.g., for cookie access on the IO thread).
Thanks! A few comments while waiting for the next changes. https://chromiumcodereview.appspot.com/701953006/diff/40001/content/browser/f... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/40001/content/browser/f... content/browser/frame_host/navigator_impl_unittest.cc:510: EXPECT_TRUE(srfh->GetProcess()->HasConnection()); Alternatively, you could use srfh->IsRenderFrameLive(). https://chromiumcodereview.appspot.com/701953006/diff/40001/content/browser/f... File content/browser/frame_host/render_frame_host_manager.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/40001/content/browser/f... content/browser/frame_host/render_frame_host_manager.cc:653: // If there is an ongoing navigation, just clean it up. nit: s/just clean it up/cancel it
On 2014/11/12 23:13:11, nasko wrote: > On 2014/11/12 13:01:14, clamy wrote: > > Thanks! A few comments after the first read-through. > > > > On the subject of the pending render frame host, how does getting rid of it > > works with swapping the old one out. Currently we do: > > CommitNavigation -> maybe create a new RFH and put it in pending -> Render > Frame > > commits navigation -> RFHM::DidNavigate -> swap out old renderer. In a version > > where we don't have a pending RFH, do we swap out the old one right at > > CommitNavigation, or do we store whatever RFH will commit the navigation in > the > > speculative RFH (which is no longer speculative at this point) and swap this > one > > in RFHM::DidNavigate. Personally, I find option 1 to be better, wdyt? > > As discussed today, I think we should swap at CommitNavigation time, as this is > the time where the new RFH becomes effective and RFHM::DidNavigate skips the > CommitPending part, as there is no pending RFH. The only possible issue is > painting white between CommitNavigation and the time first paint of the new > document is complete. Yes, I agree. Not sure if it leads to some complications with Navigation Transitions, but conceptually CommitNavigation is that point of no return, where we know we will show the new RFH. We should swap it in then.
On 2014/11/13 14:40:26, carlosk wrote: > On 2014/11/11 00:51:28, Charlie Reis wrote: > > On 2014/11/06 10:56:31, carlosk wrote: > > > Sounds good. I'll then work on removing the pending_* dependency when > > > PlzNavigate is enabled and also on adding at least a few tests of the new > > system > > > to try and make it clearer how it works. I also owe a proper design doc on > > this > > > change... > > > > > > I also realized I was wrong in my reply to your comment: we will not lose > the > > > speculative RFH for just any change of URL during navigation. We will for > all > > > cases where the change requires a different SiteInstance. For instance, if I > > > type "wikipedia.org" and end up in "http://www.wikipedia.org/" it should be > > > alright as both would fall under the same SI. > > > > > > Nonetheless, we would still throw away the speculative RFH for all > navigations > > > that don't keep the same SI. As link shortening sees such widespread usage > > today > > > I think it'd be a considerable hit. I'll try to find metrics that could help > > > estimating the impact it would cause. > > > > True, but I don't think we'll need to care about that with where we're > heading. > > I'm finishing a proposal to make the SiteInstance's site URL more meaningful, > > which will put most web site URLs in a generic "web" principal (likely just an > > empty GURL). Thus, most redirects will stay in the same SiteInstance. The > site > > URL will only be non-empty if we're actually isolating that site securely, at > > least once Site Isolation launches. > > > > For details, see this doc (with your http://chromium.org account): > > > https://docs.google.com/document/d/1ND9j2_XzQvzvIckHnuInStJptF62NrqN9iUdH-sMH... > > Indeed it seems that with that change it would even improve the success rate of > the speculative RFH as it should make matching SiteInstance's easier. I'd even > like to set the issue you'd create for it as a dependency of this one. I can share a draft CL with you when it's ready, but feel free to proceed with this CL before that's ready. It just means speculative RFHs will succeed for more redirects once mine lands.
I uploaded a new patch set that reverts the code path split of RFH creation: now both speculative and "regular" RFH creation are one and the same. And this comes along with a few related improvements (or at least I think they are improvements). On 2014/11/13 20:10:41, Charlie Reis wrote: > On 2014/11/13 14:59:03, carlosk wrote: > > I just realized there might still be an issue with SiteInstances even with > > creis@ proposal. If we initially create a RFH using a SI to > > "http://bit.ly/shortened-url" but finally are redirected to > > "http://wikipedia.org" these changes should still allow the initially created > SI > > to be used. it seems to me that this would still require some sort of > > site-unbound SiteInstance creation, or maybe a way to "update" a > SiteInstance's > > site later on iff it was not used yet to commit a navigation. > > > > Otherwise the initial SI wouldn't match the final one anyway and the RFH would > > have to be created anew. Sounds right? > > I haven't looked at the rest of the updates yet, but I wanted to reply to this. > With the proposal, both http://bit.ly/shortened-url and http://wikipedia.org > would end up in the same generic "web" principal SiteInstance, with an empty > site GURL. There's no need to swap SiteInstance or RFH on the server redirect. > > The same is not true for a bitly redirect link to a HTTPS site you've logged > into (assuming we isolated it for --site-per-process). However, in that case a > process swap is probably necessary, since we will likely end up needing > different RenderMessageFilters on the RenderProcessHost to ensure they're locked > to the new origin (e.g., for cookie access on the IO thread). Thanks for that information. On 2014/11/14 17:30:29, Charlie Reis wrote: > On 2014/11/12 23:13:11, nasko wrote: > > On 2014/11/12 13:01:14, clamy wrote: > > > Thanks! A few comments after the first read-through. > > > > > > On the subject of the pending render frame host, how does getting rid of it > > > works with swapping the old one out. Currently we do: > > > CommitNavigation -> maybe create a new RFH and put it in pending -> Render > > Frame > > > commits navigation -> RFHM::DidNavigate -> swap out old renderer. In a > version > > > where we don't have a pending RFH, do we swap out the old one right at > > > CommitNavigation, or do we store whatever RFH will commit the navigation in > > the > > > speculative RFH (which is no longer speculative at this point) and swap this > > one > > > in RFHM::DidNavigate. Personally, I find option 1 to be better, wdyt? > > > > As discussed today, I think we should swap at CommitNavigation time, as this > is > > the time where the new RFH becomes effective and RFHM::DidNavigate skips the > > CommitPending part, as there is no pending RFH. The only possible issue is > > painting white between CommitNavigation and the time first paint of the new > > document is complete. > > Yes, I agree. Not sure if it leads to some complications with Navigation > Transitions, but conceptually CommitNavigation is that point of no return, where > we know we will show the new RFH. We should swap it in then. Cool, this is the next thing I'll work on. https://codereview.chromium.org/701953006/diff/40001/content/browser/frame_ho... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/40001/content/browser/frame_ho... content/browser/frame_host/navigator_impl_unittest.cc:510: EXPECT_TRUE(srfh->GetProcess()->HasConnection()); On 2014/11/14 10:11:09, clamy wrote: > Alternatively, you could use srfh->IsRenderFrameLive(). Acknowledged. It just seems more precise on what we want to check here. https://codereview.chromium.org/701953006/diff/40001/content/browser/frame_ho... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/40001/content/browser/frame_ho... content/browser/frame_host/render_frame_host_manager.cc:653: // If there is an ongoing navigation, just clean it up. On 2014/11/14 10:11:09, clamy wrote: > nit: s/just clean it up/cancel it Done.
On 2014/11/14 17:39:26, Charlie Reis wrote: > On 2014/11/13 14:40:26, carlosk wrote: > > On 2014/11/11 00:51:28, Charlie Reis wrote: > > > On 2014/11/06 10:56:31, carlosk wrote: > > > > Sounds good. I'll then work on removing the pending_* dependency when > > > > PlzNavigate is enabled and also on adding at least a few tests of the new > > > system > > > > to try and make it clearer how it works. I also owe a proper design doc on > > > this > > > > change... > > > > > > > > I also realized I was wrong in my reply to your comment: we will not lose > > the > > > > speculative RFH for just any change of URL during navigation. We will for > > all > > > > cases where the change requires a different SiteInstance. For instance, if > I > > > > type "wikipedia.org" and end up in "http://www.wikipedia.org/" it should > be > > > > alright as both would fall under the same SI. > > > > > > > > Nonetheless, we would still throw away the speculative RFH for all > > navigations > > > > that don't keep the same SI. As link shortening sees such widespread usage > > > today > > > > I think it'd be a considerable hit. I'll try to find metrics that could > help > > > > estimating the impact it would cause. > > > > > > True, but I don't think we'll need to care about that with where we're > > heading. > > > I'm finishing a proposal to make the SiteInstance's site URL more > meaningful, > > > which will put most web site URLs in a generic "web" principal (likely just > an > > > empty GURL). Thus, most redirects will stay in the same SiteInstance. The > > site > > > URL will only be non-empty if we're actually isolating that site securely, > at > > > least once Site Isolation launches. > > > > > > For details, see this doc (with your http://chromium.org account): > > > > > > https://docs.google.com/document/d/1ND9j2_XzQvzvIckHnuInStJptF62NrqN9iUdH-sMH... > > > > Indeed it seems that with that change it would even improve the success rate > of > > the speculative RFH as it should make matching SiteInstance's easier. I'd even > > like to set the issue you'd create for it as a dependency of this one. > > I can share a draft CL with you when it's ready, but feel free to proceed with > this CL before that's ready. It just means speculative RFHs will succeed for > more redirects once mine lands. No need as I think your CL might land before mine. I'll anyway revert my current "trick" with site-unbound SiteInstances to avoid even more conflicting changes.
With the last round of PatchSets (4 to 7) I think I got to the point I needed to be to get the next round of reviews. Please see their individual comment-lines to learn what was done. I re-enabled all tests and some are failing/crashing. I'm waiting on clamy@'s test update CL to land to go on and fix them.
I think this CL is trying to do more than one thing and ends up being more complex to read than needed. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:500: static_cast<TestRenderFrameHost*>(rfhm->speculative_render_frame_host()); Why do you need to static cast? You aren't calling any test specific methods on this. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:516: common_params.transition = ui::PAGE_TRANSITION_CLIENT_REDIRECT; In order for client redirect to occur, you need to have a document committed, right? I don't see a commit for google.com at this point. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:161: return NULL; nit: nullptr https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:665: // in UpdateStateForNavigate be copied here? I think we discussed this in the sync-up meeting. You can copy it over and change the strings as appropriate. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:916: dest_url, dest_instance, dest_transition, dest_is_restore, No need to change format of code you aren't modifying. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1124: CancelPending(); Why is this needed? https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1131: int RenderFrameHostManager::GetOpenerRouteIDForNewRenderView( This method does a lot more than GetOpenerRouteID. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1181: int RenderFrameHostManager::CreateSwappedOutHiddenRenderFrame( I don't see a clear advantage to having this wrapper, especially since the booleans were refactored into flags. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:662: bool should_reuse_web_ui_; Can we avoid adding yet more state? https://codereview.chromium.org/701953006/diff/120001/content/browser/web_con... File content/browser/web_contents/web_contents_impl.cc (right): https://codereview.chromium.org/701953006/diff/120001/content/browser/web_con... content/browser/web_contents/web_contents_impl.cc:3909: return GetRenderManager()->CreateSwappedOutHiddenRenderFrame( Please rebase on top of crrev.com/304494.
Thanks! I agree with Nasko that this CL should be split. I think you could move the changes to RFHM that do not depend on the speculative render frame host to their own preparatory CL (mainly having CreateRenderFrame return a RFH instead of storing it in pending_render_frame_host and associated changes to SetPendingWebUI). https://chromiumcodereview.appspot.com/701953006/diff/120001/content/browser/... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/120001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:307: // the pending_* members of RFHM which are not necessarily used by PlzNavigate. In the new version, we should just check that the new main RFH is different from the old one (stored in rfh). https://chromiumcodereview.appspot.com/701953006/diff/120001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:516: common_params.transition = ui::PAGE_TRANSITION_CLIENT_REDIRECT; On 2014/11/19 01:00:23, nasko wrote: > In order for client redirect to occur, you need to have a document committed, > right? I don't see a commit for http://google.com at this point. Unless you are specifically testing a client redirect, you may want to change it to PAGE_TRANSITION_TYPED (since we are faking a browser initiated navigation here). https://chromiumcodereview.appspot.com/701953006/diff/120001/content/browser/... File content/browser/frame_host/render_frame_host_manager.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/120001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:318: if (CommandLine::ForCurrentProcess()->HasSwitch( We should not receive a beforeunload ack in the case of a cross-site transition when PlzNavigate is enabled. The goal is to have the ack included in BeginNavigation. Therefore this block unnecessary, and could be replaced with a DCHECK(!CommandLine::ForCurrentProcess()->HasSwitch( switches::kEnableBrowserSideNavigation)) at the beginning of the block for cross-site transition. As for the second added block, I think that it should prove to be unnecessary as well. The speculative render frame host exists between BeginNavigation and CommitNavigation. So the BeforeUnload event for the old page has already executed (in response to RequestNavigation from the browser), and we don't have a new page committed yet. Therefore, we should not be waiting for the BeforeUnload event to execute when trying to close the page. In practice, I think we do. But this should not be the case. https://chromiumcodereview.appspot.com/701953006/diff/120001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:472: CleanUpSpeculativeRenderFrameHost(); Considering that CancelNavigation is now just a call to CleanUpSpeculativeRenderFrameHost, how about removing CleanUpSpeculativeRenderFrameHost entirely? https://chromiumcodereview.appspot.com/701953006/diff/120001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:647: void RenderFrameHostManager::BeginNavigation( nit: Add above // PlzNavigate https://chromiumcodereview.appspot.com/701953006/diff/120001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:662: // Navigating to a new SiteInstance -> speculatively create a new RFH nit: add a . at the end of the sentence. https://chromiumcodereview.appspot.com/701953006/diff/120001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:667: // TODO(carlosk): enable bindings check below nit: add a . at the end of the comment. https://chromiumcodereview.appspot.com/701953006/diff/120001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:674: // Navigating to the same SiteInstance -> make sure the current RFH is alive nit: add a . at the end of the comment. https://chromiumcodereview.appspot.com/701953006/diff/120001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:691: bool RenderFrameHostManager::CreateSpeculativeRenderFrameHost( nit: add above // PlzNavigate https://chromiumcodereview.appspot.com/701953006/diff/120001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:1121: // It used to happen inside the creation method iff the new RFH was nit: s/iff/if https://chromiumcodereview.appspot.com/701953006/diff/120001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:1192: RenderFrameHostManager::CreateRenderFrameInternal( Note: In theory, methods in the .cc file should have the same order as in the header file, and here it is completely wrong. I know that the initial file was not perfect in that regard, but we're adding even more mess. So please make it less so. In particular, this function needs to move down, and so does CreateSpeculativeRenderFrameHost. https://chromiumcodereview.appspot.com/701953006/diff/120001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:1342: return delegate_->CreateRenderViewForRenderManager( You don't need to change formating for code that is not modified. https://chromiumcodereview.appspot.com/701953006/diff/120001/content/browser/... File content/browser/frame_host/render_frame_host_manager.h (right): https://chromiumcodereview.appspot.com/701953006/diff/120001/content/browser/... content/browser/frame_host/render_frame_host_manager.h:296: void CancelNavigation(); nit: place this function with the other PlzNavigate ones below. https://chromiumcodereview.appspot.com/701953006/diff/120001/content/browser/... File content/browser/site_instance_impl.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/120001/content/browser/... content/browser/site_instance_impl.cc:144: DCHECK(!browsing_instance_->HasSiteInstance(url)); Why did you add this DCHECK?
On 2014/11/19 01:00:24, nasko wrote: > I think this CL is trying to do more than one thing and ends up being more > complex to read than needed. On 2014/11/19 15:03:30, clamy wrote: > Thanks! I agree with Nasko that this CL should be split. I think you could move > the changes to RFHM that do not depend on the speculative render frame host to > their own preparatory CL (mainly having CreateRenderFrame return a RFH instead > of storing it in pending_render_frame_host and associated changes to > SetPendingWebUI). Thanks for your comments. I replied to all of them, asked a lot of questions but I will wait to upload changes until after I get the next round of feedback from you. But the main thing is the concern about this CL being too big. Before doing anything in that regard I just want have consensus among the reviewers as previously creis@ asked that the complete separation of the speculative-related-code form the pending-related-code should happen in this same CL along with the speculative renderer (see https://codereview.chromium.org/701953006/#msg7). https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:307: // the pending_* members of RFHM which are not necessarily used by PlzNavigate. On 2014/11/19 15:03:29, clamy wrote: > In the new version, we should just check that the new main RFH is different from > the old one (stored in rfh). Acknowledged. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:500: static_cast<TestRenderFrameHost*>(rfhm->speculative_render_frame_host()); On 2014/11/19 01:00:23, nasko wrote: > Why do you need to static cast? You aren't calling any test specific methods on > this. I added the cast when I was figuring out how to invoke the correct PlzNavigate methods but it was finally not needed and I forgot to remove it. Removed now. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:516: common_params.transition = ui::PAGE_TRANSITION_CLIENT_REDIRECT; On 2014/11/19 15:03:29, clamy wrote: > On 2014/11/19 01:00:23, nasko wrote: > > In order for client redirect to occur, you need to have a document committed, > > right? I don't see a commit for http://google.com at this point. > > Unless you are specifically testing a client redirect, you may want to change it > to PAGE_TRANSITION_TYPED (since we are faking a browser initiated navigation > here). In this case I was guesstimating that to maintain consistency a faked redirect would be the correct transition because the initial URL differs from the final one. We are faking that the initial one is typed indeed but not the second one otherwise it would cancel the former. Would changing it to PAGE_TRANSITION_SERVER_REDIRECT make this consistent? https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:161: return NULL; On 2014/11/19 01:00:23, nasko wrote: > nit: nullptr I was in doubt about this as I understood we are changing to using nullptr but we also tend to try to keep the standard that is currently used (NULL in this file). So, should I replace all cases? https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:318: if (CommandLine::ForCurrentProcess()->HasSwitch( On 2014/11/19 15:03:29, clamy wrote: > We should not receive a beforeunload ack in the case of a cross-site transition > when PlzNavigate is enabled. The goal is to have the ack included in > BeginNavigation. Therefore this block unnecessary, and could be replaced with a > DCHECK(!CommandLine::ForCurrentProcess()->HasSwitch( > switches::kEnableBrowserSideNavigation)) at the beginning of the block for > cross-site transition. > > As for the second added block, I think that it should prove to be unnecessary as > well. The speculative render frame host exists between BeginNavigation and > CommitNavigation. So the BeforeUnload event for the old page has already > executed (in response to RequestNavigation from the browser), and we don't have > a new page committed yet. Therefore, we should not be waiting for the > BeforeUnload event to execute when trying to close the page. In practice, I > think we do. But this should not be the case. Done for the 1st one. I didn't understood what you meant about the 2nd block. But FYI, I added all these added clean-up calls just following the thought that "whenever a navigation is cancelled, speculative stuff should be cleared". https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:472: CleanUpSpeculativeRenderFrameHost(); On 2014/11/19 15:03:29, clamy wrote: > Considering that CancelNavigation is now just a call to > CleanUpSpeculativeRenderFrameHost, how about removing > CleanUpSpeculativeRenderFrameHost entirely? My reasoning is: - From a public perspective, one should want to cancel a navigation and not fiddle with internal state. So "cancel" is clearer. - Internally I wanted to tell apart the cases when the intention is to cancel the navigation from the ones where I just want to clean-up the speculative stuff. - Also internally I'm expecting that moving forward the "cancel" operation will involve more things. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:647: void RenderFrameHostManager::BeginNavigation( On 2014/11/19 15:03:29, clamy wrote: > nit: Add above // PlzNavigate Done. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:662: // Navigating to a new SiteInstance -> speculatively create a new RFH On 2014/11/19 15:03:29, clamy wrote: > nit: add a . at the end of the sentence. Done. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:665: // in UpdateStateForNavigate be copied here? On 2014/11/19 01:00:23, nasko wrote: > I think we discussed this in the sync-up meeting. You can copy it over and > change the strings as appropriate. Yes, and I will. :) I rephrased the TODO to make it clearer. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:667: // TODO(carlosk): enable bindings check below On 2014/11/19 15:03:29, clamy wrote: > nit: add a . at the end of the comment. Done. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:674: // Navigating to the same SiteInstance -> make sure the current RFH is alive On 2014/11/19 15:03:29, clamy wrote: > nit: add a . at the end of the comment. Done. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:691: bool RenderFrameHostManager::CreateSpeculativeRenderFrameHost( On 2014/11/19 15:03:29, clamy wrote: > nit: add above // PlzNavigate Done. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:916: dest_url, dest_instance, dest_transition, dest_is_restore, On 2014/11/19 01:00:23, nasko wrote: > No need to change format of code you aren't modifying. Reverted. This was a consequence of my previous changing this method and running git cl format which now prefers these kind of formatting. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1121: // It used to happen inside the creation method iff the new RFH was On 2014/11/19 15:03:29, clamy wrote: > nit: s/iff/if This is not a typo: iff == if and only if (http://en.wikipedia.org/wiki/iff) Also, this is a temporary TODO and should be removed before commit. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1124: CancelPending(); On 2014/11/19 01:00:23, nasko wrote: > Why is this needed? See lines 1143-1144 from the previous version: this used to be done in RFHM::CreateRenderFrame that I refactored to me more generic so I'm just trying to keep the old behavior as much as possible. That's why I added the TODO above as well. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1131: int RenderFrameHostManager::GetOpenerRouteIDForNewRenderView( On 2014/11/19 01:00:23, nasko wrote: > This method does a lot more than GetOpenerRouteID. Agreed. I extracted the behavior I wanted to share and might have chosen a poor name for the method. But in fact I have no idea of what to call this... Suggestions? https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1181: int RenderFrameHostManager::CreateSwappedOutHiddenRenderFrame( On 2014/11/19 01:00:24, nasko wrote: > I don't see a clear advantage to having this wrapper, especially since the > booleans were refactored into flags. Calls made outside of RFHM are all swapped-out and consequentially must be also hidden. The only variation was the for_main_frame_navigation parameter. I prefer to keep the publicly available methods as simple as possible hence the change. Note that this was written before I was aware of the incoming change. Even so I did talk with the owner of that CL and he was also OK with this. He confirmed the new render frame creation option flag that he will add soon will also be only internal to RFHM. I did already rebase my changes locally and this looks like an good simplification to me (extracted from web_contents_impl.cc): - return GetRenderManager()->CreateRenderFrame( - instance, opener_route_id, CREATE_RF_FOR_MAIN_FRAME_NAVIGATION | - CREATE_RF_SWAPPED_OUT | CREATE_RF_HIDDEN); + return GetRenderManager()->CreateSwappedOutHiddenRenderFrame( + instance, opener_route_id, true); https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1192: RenderFrameHostManager::CreateRenderFrameInternal( On 2014/11/19 15:03:29, clamy wrote: > Note: In theory, methods in the .cc file should have the same order as in the > header file, and here it is completely wrong. I know that the initial file was > not perfect in that regard, but we're adding even more mess. So please make it > less so. In particular, this function needs to move down, and so does > CreateSpeculativeRenderFrameHost. Acknowledged and done. From now on I will follow that rule of thumb instead of trying to keep related methods together. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1342: return delegate_->CreateRenderViewForRenderManager( On 2014/11/19 15:03:29, clamy wrote: > You don't need to change formating for code that is not modified. Reverted. Same reason as before... https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:296: void CancelNavigation(); On 2014/11/19 15:03:29, clamy wrote: > nit: place this function with the other PlzNavigate ones below. Done. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:662: bool should_reuse_web_ui_; On 2014/11/19 01:00:24, nasko wrote: > Can we avoid adding yet more state? As WebUI instances are held with scoped_ptr I can't (shouldn't is more precise) make the current and speculative point to the same value. So I need something else to let me know at commit time that the current WebUI should just be kept in place For the existing pending logic, this same logic is done with a weak-pointer to the current WebUI (see pending pending_and_current_web_ui_ above). I didn't see any advantages in comparison to simply having a boolean flag. I could also consolidate these 3 speculative-related members into a new struct. https://codereview.chromium.org/701953006/diff/120001/content/browser/site_in... File content/browser/site_instance_impl.cc (right): https://codereview.chromium.org/701953006/diff/120001/content/browser/site_in... content/browser/site_instance_impl.cc:144: DCHECK(!browsing_instance_->HasSiteInstance(url)); On 2014/11/19 15:03:29, clamy wrote: > Why did you add this DCHECK? Even though I reverted the rest I left this change in because it is indeed a valid check: one should not have two equivalent SiteInstances belonging to the same browsing instance. Isn't it so? https://codereview.chromium.org/701953006/diff/120001/content/browser/web_con... File content/browser/web_contents/web_contents_impl.cc (right): https://codereview.chromium.org/701953006/diff/120001/content/browser/web_con... content/browser/web_contents/web_contents_impl.cc:3909: return GetRenderManager()->CreateSwappedOutHiddenRenderFrame( On 2014/11/19 01:00:24, nasko wrote: > Please rebase on top of crrev.com/304494. Already done locally.
On 2014/11/19 17:24:30, carlosk wrote: > On 2014/11/19 01:00:24, nasko wrote: > > I think this CL is trying to do more than one thing and ends up being more > > complex to read than needed. > > On 2014/11/19 15:03:30, clamy wrote: > > Thanks! I agree with Nasko that this CL should be split. I think you could > move > > the changes to RFHM that do not depend on the speculative render frame host to > > their own preparatory CL (mainly having CreateRenderFrame return a RFH instead > > of storing it in pending_render_frame_host and associated changes to > > SetPendingWebUI). > > Thanks for your comments. I replied to all of them, asked a lot of questions but > I will wait to upload changes until after I get the next round of feedback from > you. > > But the main thing is the concern about this CL being too big. Before doing > anything in that regard I just want have consensus among the reviewers as > previously creis@ asked that the complete separation of the > speculative-related-code form the pending-related-code should happen in this > same CL along with the speculative renderer (see > https://codereview.chromium.org/701953006/#msg7). I haven't reviewed the rest yet, but I wanted to respond to this to unblock you. My earlier comment was saying that we should not postpone the speculative/pending split until later. I would be happy to see any necessary ground work for it happen first-- it's always good to have smaller CLs when possible. Thanks!
On 2014/11/19 17:55:31, Charlie Reis wrote: > On 2014/11/19 17:24:30, carlosk wrote: > > On 2014/11/19 01:00:24, nasko wrote: > > > I think this CL is trying to do more than one thing and ends up being more > > > complex to read than needed. > > > > On 2014/11/19 15:03:30, clamy wrote: > > > Thanks! I agree with Nasko that this CL should be split. I think you could > > move > > > the changes to RFHM that do not depend on the speculative render frame host > to > > > their own preparatory CL (mainly having CreateRenderFrame return a RFH > instead > > > of storing it in pending_render_frame_host and associated changes to > > > SetPendingWebUI). > > > > Thanks for your comments. I replied to all of them, asked a lot of questions > but > > I will wait to upload changes until after I get the next round of feedback > from > > you. > > > > But the main thing is the concern about this CL being too big. Before doing > > anything in that regard I just want have consensus among the reviewers as > > previously creis@ asked that the complete separation of the > > speculative-related-code form the pending-related-code should happen in this > > same CL along with the speculative renderer (see > > https://codereview.chromium.org/701953006/#msg7). > > I haven't reviewed the rest yet, but I wanted to respond to this to unblock you. > My earlier comment was saying that we should not postpone the > speculative/pending split until later. I would be happy to see any necessary > ground work for it happen first-- it's always good to have smaller CLs when > possible. Thanks! Thanks for keeping an eye at this CL creis@! :) I'll already being the work of splitting this in two or more CLs.
One generic comment - please don't hold back changes locally. It makes reviews much much harder and time consuming. Now that I've gone through all the comments, I will need to revisit them again when you upload code. This effectively doubles the time needed to review and the probability of quickly reviewing goes way down. Also, to echo what Charlie said - smaller CLs are much more likely to be reviewed quickly and are much easier to reason about. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:516: common_params.transition = ui::PAGE_TRANSITION_CLIENT_REDIRECT; On 2014/11/19 17:24:28, carlosk wrote: > On 2014/11/19 15:03:29, clamy wrote: > > On 2014/11/19 01:00:23, nasko wrote: > > > In order for client redirect to occur, you need to have a document > committed, > > > right? I don't see a commit for http://google.com at this point. > > > > Unless you are specifically testing a client redirect, you may want to change > it > > to PAGE_TRANSITION_TYPED (since we are faking a browser initiated navigation > > here). > > In this case I was guesstimating that to maintain consistency a faked redirect > would be the correct transition because the initial URL differs from the final > one. > > We are faking that the initial one is typed indeed but not the second one > otherwise it would cancel the former. > > Would changing it to PAGE_TRANSITION_SERVER_REDIRECT make this consistent? Why are you even faking it? If you want to test that server redirects behave properly, it should be a separate test case. This test case is called *Simple, so I would expect it to test a regular request that commits fine without anything special. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:161: return NULL; On 2014/11/19 17:24:29, carlosk wrote: > On 2014/11/19 01:00:23, nasko wrote: > > nit: nullptr > > I was in doubt about this as I understood we are changing to using nullptr but > we also tend to try to keep the standard that is currently used (NULL in this > file). So, should I replace all cases? New code should be using current(new) conventions, which means nullptr. Existing code shouldn't be modified for the sake of migrating to the new style. So please don't replace all cases, but update code you have written/touched. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:472: CleanUpSpeculativeRenderFrameHost(); On 2014/11/19 17:24:29, carlosk wrote: > On 2014/11/19 15:03:29, clamy wrote: > > Considering that CancelNavigation is now just a call to > > CleanUpSpeculativeRenderFrameHost, how about removing > > CleanUpSpeculativeRenderFrameHost entirely? > > My reasoning is: > - From a public perspective, one should want to cancel a navigation and not > fiddle with internal state. So "cancel" is clearer. > - Internally I wanted to tell apart the cases when the intention is to cancel > the navigation from the ones where I just want to clean-up the speculative > stuff. > - Also internally I'm expecting that moving forward the "cancel" operation will > involve more things. We shouldn't be speculating about the future. Let's keep code simple until we really need it. I do agree the cleanup should be inlined here. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1131: int RenderFrameHostManager::GetOpenerRouteIDForNewRenderView( On 2014/11/19 17:24:29, carlosk wrote: > On 2014/11/19 01:00:23, nasko wrote: > > This method does a lot more than GetOpenerRouteID. > > Agreed. I extracted the behavior I wanted to share and might have chosen a poor > name for the method. But in fact I have no idea of what to call this... > Suggestions? For one, you lost a very important comment that was prior to the code you've moved around. It will probably be a good source of inspiration of whether to factor this out into its own method or embed somewhere else. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1181: int RenderFrameHostManager::CreateSwappedOutHiddenRenderFrame( On 2014/11/19 17:24:29, carlosk wrote: > On 2014/11/19 01:00:24, nasko wrote: > > I don't see a clear advantage to having this wrapper, especially since the > > booleans were refactored into flags. > > Calls made outside of RFHM are all swapped-out and consequentially must be also > hidden. The only variation was the for_main_frame_navigation parameter. I prefer > to keep the publicly available methods as simple as possible hence the change. While I agree this is in general a very good goal to aim for, I think in this case this is code churn that isn't needed. WebContents and RFHM are very closely tied together, so I don't see the advantage of adding a one-line wrapper. It actually adds more overhead when reading the code. > Note that this was written before I was aware of the incoming change. Even so I > did talk with the owner of that CL and he was also OK with this. He confirmed > the new render frame creation option flag that he will add soon will also be > only internal to RFHM. Sure. > I did already rebase my changes locally and this looks like an good > simplification to me (extracted from web_contents_impl.cc): > > - return GetRenderManager()->CreateRenderFrame( > - instance, opener_route_id, CREATE_RF_FOR_MAIN_FRAME_NAVIGATION | > - CREATE_RF_SWAPPED_OUT | CREATE_RF_HIDDEN); > + return GetRenderManager()->CreateSwappedOutHiddenRenderFrame( > + instance, opener_route_id, true); Until you need to read the code and jump through two levels to get to the actual implementation. Also, since this code is hopefully going to go away in the not-so-distant future, I don't think it is worth "improving" it right now. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1192: RenderFrameHostManager::CreateRenderFrameInternal( On 2014/11/19 17:24:28, carlosk wrote: > On 2014/11/19 15:03:29, clamy wrote: > > Note: In theory, methods in the .cc file should have the same order as in the > > header file, and here it is completely wrong. I know that the initial file was > > not perfect in that regard, but we're adding even more mess. So please make it > > less so. In particular, this function needs to move down, and so does > > CreateSpeculativeRenderFrameHost. > > Acknowledged and done. From now on I will follow that rule of thumb instead of > trying to keep related methods together. You can still keep them together, just reorder the header and .cc to match. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1748: RecycleRenderFrameHost(pending_render_frame_host.Pass()); Recycle sounds like we will like to use it again and seems the wrong semantics for this code. Let's rename it to something else that implies that we are cleaning it up. The fact that we stash it around in certain cases is an implementation detail that will disappear in the not-so-distant future.
Patchset #8 (id:140001) has been deleted
Thanks. On 2014/11/19 19:01:29, nasko wrote: > One generic comment - please don't hold back changes locally. It makes reviews > much much harder and time consuming. Now that I've gone through all the > comments, I will need to revisit them again when you upload code. This > effectively doubles the time needed to review and the probability of quickly > reviewing goes way down. Sorry about that and I'll keep that in mind. I did now upload all changes. To ease the reviewing I also marked with a new "Done" comment all previous places where I mentioned I had it done locally so that it should be easy to track them again. > Also, to echo what Charlie said - smaller CLs are much more likely to be > reviewed quickly and are much easier to reason about. I agree with that and that's why initially I suggested the split. Anyway I'll begin working on splitting this up in smaller CLs (at least 2). https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:307: // the pending_* members of RFHM which are not necessarily used by PlzNavigate. On 2014/11/19 17:24:28, carlosk wrote: > On 2014/11/19 15:03:29, clamy wrote: > > In the new version, we should just check that the new main RFH is different > from > > the old one (stored in rfh). > > Acknowledged. I did that and fixed all but one of the failing tests. NavigatorTestWithBrowserSideNavigation.BeginNavigation is crashing in a CHECK inside RFHM due to an uninitialized RenderViewHost. I think it has something to do with that test trying to navigate a subframe and the speculative RFH code is not handling that case correctly. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:500: static_cast<TestRenderFrameHost*>(rfhm->speculative_render_frame_host()); On 2014/11/19 17:24:28, carlosk wrote: > On 2014/11/19 01:00:23, nasko wrote: > > Why do you need to static cast? You aren't calling any test specific methods > on > > this. > > I added the cast when I was figuring out how to invoke the correct PlzNavigate > methods but it was finally not needed and I forgot to remove it. Removed now. Done. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:516: common_params.transition = ui::PAGE_TRANSITION_CLIENT_REDIRECT; On 2014/11/19 19:01:29, nasko wrote: > On 2014/11/19 17:24:28, carlosk wrote: > > On 2014/11/19 15:03:29, clamy wrote: > > > On 2014/11/19 01:00:23, nasko wrote: > > > > In order for client redirect to occur, you need to have a document > > committed, > > > > right? I don't see a commit for http://google.com at this point. > > > > > > Unless you are specifically testing a client redirect, you may want to > change > > it > > > to PAGE_TRANSITION_TYPED (since we are faking a browser initiated navigation > > > here). > > > > In this case I was guesstimating that to maintain consistency a faked redirect > > would be the correct transition because the initial URL differs from the final > > one. > > > > We are faking that the initial one is typed indeed but not the second one > > otherwise it would cancel the former. > > > > Would changing it to PAGE_TRANSITION_SERVER_REDIRECT make this consistent? > > Why are you even faking it? If you want to test that server redirects behave > properly, it should be a separate test case. This test case is called *Simple, > so I would expect it to test a regular request that commits fine without > anything special. Agreed and done. I made this test to test the actual simplest case of navigating from site 1 to site 2. Redirects are left for another future test. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:161: return NULL; On 2014/11/19 19:01:29, nasko wrote: > On 2014/11/19 17:24:29, carlosk wrote: > > On 2014/11/19 01:00:23, nasko wrote: > > > nit: nullptr > > > > I was in doubt about this as I understood we are changing to using nullptr but > > we also tend to try to keep the standard that is currently used (NULL in this > > file). So, should I replace all cases? > > New code should be using current(new) conventions, which means nullptr. Existing > code shouldn't be modified for the sake of migrating to the new style. So please > don't replace all cases, but update code you have written/touched. Acknowledged and done. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:318: if (CommandLine::ForCurrentProcess()->HasSwitch( On 2014/11/19 17:24:29, carlosk wrote: > On 2014/11/19 15:03:29, clamy wrote: > > We should not receive a beforeunload ack in the case of a cross-site > transition > > when PlzNavigate is enabled. The goal is to have the ack included in > > BeginNavigation. Therefore this block unnecessary, and could be replaced with > a > > DCHECK(!CommandLine::ForCurrentProcess()->HasSwitch( > > switches::kEnableBrowserSideNavigation)) at the beginning of the block for > > cross-site transition. > > > > As for the second added block, I think that it should prove to be unnecessary > as > > well. The speculative render frame host exists between BeginNavigation and > > CommitNavigation. So the BeforeUnload event for the old page has already > > executed (in response to RequestNavigation from the browser), and we don't > have > > a new page committed yet. Therefore, we should not be waiting for the > > BeforeUnload event to execute when trying to close the page. In practice, I > > think we do. But this should not be the case. > > Done for the 1st one. > > I didn't understood what you meant about the 2nd block. > > But FYI, I added all these added clean-up calls just following the thought that > "whenever a navigation is cancelled, speculative stuff should be cleared". Removed second block as discussed in person. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:472: CleanUpSpeculativeRenderFrameHost(); On 2014/11/19 19:01:29, nasko wrote: > On 2014/11/19 17:24:29, carlosk wrote: > > On 2014/11/19 15:03:29, clamy wrote: > > > Considering that CancelNavigation is now just a call to > > > CleanUpSpeculativeRenderFrameHost, how about removing > > > CleanUpSpeculativeRenderFrameHost entirely? > > > > My reasoning is: > > - From a public perspective, one should want to cancel a navigation and not > > fiddle with internal state. So "cancel" is clearer. > > - Internally I wanted to tell apart the cases when the intention is to cancel > > the navigation from the ones where I just want to clean-up the speculative > > stuff. > > - Also internally I'm expecting that moving forward the "cancel" operation > will > > involve more things. > > We shouldn't be speculating about the future. Let's keep code simple until we > really need it. I do agree the cleanup should be inlined here. Done. After discussing with clamy@ I left a single public method called CleanUpNavigation. Reason is that it's called internally midway through the navigation and it would be weird to invoke CancelNavigation when it's not being cancelled at all. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:647: void RenderFrameHostManager::BeginNavigation( On 2014/11/19 17:24:29, carlosk wrote: > On 2014/11/19 15:03:29, clamy wrote: > > nit: Add above // PlzNavigate > > Done. Done. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:662: // Navigating to a new SiteInstance -> speculatively create a new RFH On 2014/11/19 17:24:29, carlosk wrote: > On 2014/11/19 15:03:29, clamy wrote: > > nit: add a . at the end of the sentence. > > Done. Done. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:665: // in UpdateStateForNavigate be copied here? On 2014/11/19 17:24:29, carlosk wrote: > On 2014/11/19 01:00:23, nasko wrote: > > I think we discussed this in the sync-up meeting. You can copy it over and > > change the strings as appropriate. > > Yes, and I will. :) > > I rephrased the TODO to make it clearer. It was indeed a "bad" TODO so I removed it for now and will add TRACE_EVENTs later. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:667: // TODO(carlosk): enable bindings check below On 2014/11/19 17:24:29, carlosk wrote: > On 2014/11/19 15:03:29, clamy wrote: > > nit: add a . at the end of the comment. > > Done. Done. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:674: // Navigating to the same SiteInstance -> make sure the current RFH is alive On 2014/11/19 17:24:29, carlosk wrote: > On 2014/11/19 15:03:29, clamy wrote: > > nit: add a . at the end of the comment. > > Done. Done. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:691: bool RenderFrameHostManager::CreateSpeculativeRenderFrameHost( On 2014/11/19 17:24:29, carlosk wrote: > On 2014/11/19 15:03:29, clamy wrote: > > nit: add above // PlzNavigate > > Done. Done. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:916: dest_url, dest_instance, dest_transition, dest_is_restore, On 2014/11/19 17:24:29, carlosk wrote: > On 2014/11/19 01:00:23, nasko wrote: > > No need to change format of code you aren't modifying. > > Reverted. > > This was a consequence of my previous changing this method and running git cl > format which now prefers these kind of formatting. Done. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1131: int RenderFrameHostManager::GetOpenerRouteIDForNewRenderView( On 2014/11/19 19:01:29, nasko wrote: > On 2014/11/19 17:24:29, carlosk wrote: > > On 2014/11/19 01:00:23, nasko wrote: > > > This method does a lot more than GetOpenerRouteID. > > > > Agreed. I extracted the behavior I wanted to share and might have chosen a > poor > > name for the method. But in fact I have no idea of what to call this... > > Suggestions? > > For one, you lost a very important comment that was prior to the code you've > moved around. It will probably be a good source of inspiration of whether to > factor this out into its own method or embed somewhere else. I didn't lose it. As that comment seemed to describe the logic I extracted I moved it to be the documentation for this method's declaration in the header. I renamed the method to CreateOpenerRenderViewsIfNeeded. Does this sounds better or should I simply not extract this into a new method? https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1181: int RenderFrameHostManager::CreateSwappedOutHiddenRenderFrame( On 2014/11/19 19:01:29, nasko wrote: > On 2014/11/19 17:24:29, carlosk wrote: > > On 2014/11/19 01:00:24, nasko wrote: > > > I don't see a clear advantage to having this wrapper, especially since the > > > booleans were refactored into flags. > > > > Calls made outside of RFHM are all swapped-out and consequentially must be > also > > hidden. The only variation was the for_main_frame_navigation parameter. I > prefer > > to keep the publicly available methods as simple as possible hence the change. > > While I agree this is in general a very good goal to aim for, I think in this > case this is code churn that isn't needed. WebContents and RFHM are very closely > tied together, so I don't see the advantage of adding a one-line wrapper. It > actually adds more overhead when reading the code. > > > Note that this was written before I was aware of the incoming change. Even so > I > > did talk with the owner of that CL and he was also OK with this. He confirmed > > the new render frame creation option flag that he will add soon will also be > > only internal to RFHM. > > Sure. > > > I did already rebase my changes locally and this looks like an good > > simplification to me (extracted from web_contents_impl.cc): > > > > - return GetRenderManager()->CreateRenderFrame( > > - instance, opener_route_id, CREATE_RF_FOR_MAIN_FRAME_NAVIGATION | > > - CREATE_RF_SWAPPED_OUT | > CREATE_RF_HIDDEN); > > + return GetRenderManager()->CreateSwappedOutHiddenRenderFrame( > > + instance, opener_route_id, true); > > Until you need to read the code and jump through two levels to get to the actual > implementation. Also, since this code is hopefully going to go away in the > not-so-distant future, I don't think it is worth "improving" it right now. OK, I reverted to having one single public method. But the callers had to be adapted to the changed signature needed for it to be re-usable by the speculative RFH logic. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1192: RenderFrameHostManager::CreateRenderFrameInternal( On 2014/11/19 19:01:29, nasko wrote: > On 2014/11/19 17:24:28, carlosk wrote: > > On 2014/11/19 15:03:29, clamy wrote: > > > Note: In theory, methods in the .cc file should have the same order as in > the > > > header file, and here it is completely wrong. I know that the initial file > was > > > not perfect in that regard, but we're adding even more mess. So please make > it > > > less so. In particular, this function needs to move down, and so does > > > CreateSpeculativeRenderFrameHost. > > > > Acknowledged and done. From now on I will follow that rule of thumb instead of > > trying to keep related methods together. > > You can still keep them together, just reorder the header and .cc to match. I couldn't really as one method was public and the other private. But it's a moot point now as there's only one. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1342: return delegate_->CreateRenderViewForRenderManager( On 2014/11/19 17:24:29, carlosk wrote: > On 2014/11/19 15:03:29, clamy wrote: > > You don't need to change formating for code that is not modified. > > Reverted. Same reason as before... Done. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1748: RecycleRenderFrameHost(pending_render_frame_host.Pass()); On 2014/11/19 19:01:29, nasko wrote: > Recycle sounds like we will like to use it again and seems the wrong semantics > for this code. Let's rename it to something else that implies that we are > cleaning it up. The fact that we stash it around in certain cases is an > implementation detail that will disappear in the not-so-distant future. Done. Renamed to DiscardRenderFrameHost. WDYT? https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:296: void CancelNavigation(); On 2014/11/19 17:24:29, carlosk wrote: > On 2014/11/19 15:03:29, clamy wrote: > > nit: place this function with the other PlzNavigate ones below. > > Done. Done. https://codereview.chromium.org/701953006/diff/120001/content/browser/web_con... File content/browser/web_contents/web_contents_impl.cc (right): https://codereview.chromium.org/701953006/diff/120001/content/browser/web_con... content/browser/web_contents/web_contents_impl.cc:3909: return GetRenderManager()->CreateSwappedOutHiddenRenderFrame( On 2014/11/19 17:24:29, carlosk wrote: > On 2014/11/19 01:00:24, nasko wrote: > > Please rebase on top of crrev.com/304494. > > Already done locally. Done.
Latest two patches allow one to diff this CL against the changes from crrev.com/753173002 by diffing PS 10 from 9. So this CL basically just adds the speculative RFH creation and related changes to tests.
Few more comments. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:307: // the pending_* members of RFHM which are not necessarily used by PlzNavigate. On 2014/11/21 14:36:33, carlosk wrote: > On 2014/11/19 17:24:28, carlosk wrote: > > On 2014/11/19 15:03:29, clamy wrote: > > > In the new version, we should just check that the new main RFH is different > > from > > > the old one (stored in rfh). > > > > Acknowledged. > > I did that and fixed all but one of the failing tests. > > NavigatorTestWithBrowserSideNavigation.BeginNavigation is crashing in a CHECK > inside RFHM due to an uninitialized RenderViewHost. I think it has something to > do with that test trying to navigate a subframe and the speculative RFH code is > not handling that case correctly. Subframes will never navigate cross-process without --site-per-process flag. https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:356: // PlzNavigate: Confirms that a speculative renderer process is used when nit: s/renderer process/renderer/ or s/renderer process/RenderFrameHost/. Processes are implementation detail of isolating RFHs and SiteInstances. https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:369: // Begins navigating to another site. nit: Begin (no s). https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:378: // Commits. nit: Commit (no s). https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1408: if (!use_speculative_rfh) { Can't this be just a check for browser-site-navigation enabled? It will be nice to not need the parameter to this method. https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:385: // Returns the speculative RenderFrameHost, or NULL if there is no pending nit: null https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:387: RenderFrameHostImpl* speculative_render_frame_host() const { This isn't needed to be public. The tests that use it can be made friends of this class.
Thanks! A few comments below. https://chromiumcodereview.appspot.com/701953006/diff/200001/content/browser/... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/200001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:90: TEST_F(NavigatorTestWithBrowserSideNavigation, BeginNavigation) { Is it still failing? https://chromiumcodereview.appspot.com/701953006/diff/200001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:357: // navigation when navigating from one site to the other Remove "when navigation" https://chromiumcodereview.appspot.com/701953006/diff/200001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:360: // Navigates to an initial site. nit: Navigate (no s). https://chromiumcodereview.appspot.com/701953006/diff/200001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:386: // And just for completeness invokes OnDidCommitProvisionalLoad which nit: invoke (no s). https://chromiumcodereview.appspot.com/701953006/diff/200001/content/browser/... File content/browser/frame_host/render_frame_host_manager.h (right): https://chromiumcodereview.appspot.com/701953006/diff/200001/content/browser/... content/browser/frame_host/render_frame_host_manager.h:641: // only for the regular navigation (not yet true, but will be). Remove the not yet true mention. It is true by now, right :)?
Patchset #12 (id:240001) has been deleted
Patchset #12 (id:180002) has been deleted
Thanks for your comments. All done! This upload contains this last round of changes, some fixes, new and updated tests and is already rebased with the landed changes from crrev.com/753173002. https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/120001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:307: // the pending_* members of RFHM which are not necessarily used by PlzNavigate. On 2014/11/25 00:19:10, nasko (Out until Dec 08) wrote: > On 2014/11/21 14:36:33, carlosk wrote: > > On 2014/11/19 17:24:28, carlosk wrote: > > > On 2014/11/19 15:03:29, clamy wrote: > > > > In the new version, we should just check that the new main RFH is > different > > > from > > > > the old one (stored in rfh). > > > > > > Acknowledged. > > > > I did that and fixed all but one of the failing tests. > > > > NavigatorTestWithBrowserSideNavigation.BeginNavigation is crashing in a CHECK > > inside RFHM due to an uninitialized RenderViewHost. I think it has something > to > > do with that test trying to navigate a subframe and the speculative RFH code > is > > not handling that case correctly. > > Subframes will never navigate cross-process without --site-per-process flag. Done. https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:90: TEST_F(NavigatorTestWithBrowserSideNavigation, BeginNavigation) { On 2014/11/25 16:50:57, clamy wrote: > Is it still failing? Now it's not anymore so that TODO is gone. https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:356: // PlzNavigate: Confirms that a speculative renderer process is used when On 2014/11/25 00:19:10, nasko (Out until Dec 08) wrote: > nit: s/renderer process/renderer/ or s/renderer process/RenderFrameHost/. > Processes are implementation detail of isolating RFHs and SiteInstances. Done. https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:357: // navigation when navigating from one site to the other On 2014/11/25 16:50:57, clamy wrote: > Remove "when navigation" Done. https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:360: // Navigates to an initial site. On 2014/11/25 16:50:57, clamy wrote: > nit: Navigate (no s). Done. https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:369: // Begins navigating to another site. On 2014/11/25 00:19:10, nasko (Out until Dec 08) wrote: > nit: Begin (no s). Done. https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:378: // Commits. On 2014/11/25 00:19:10, nasko (Out until Dec 08) wrote: > nit: Commit (no s). Done. https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:386: // And just for completeness invokes OnDidCommitProvisionalLoad which On 2014/11/25 16:50:57, clamy wrote: > nit: invoke (no s). Done. https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1408: if (!use_speculative_rfh) { On 2014/11/25 00:19:10, nasko (Out until Dec 08) wrote: > Can't this be just a check for browser-site-navigation enabled? It will be nice > to not need the parameter to this method. Indeed, now it can! Great catch! :) https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:385: // Returns the speculative RenderFrameHost, or NULL if there is no pending On 2014/11/25 00:19:11, nasko (Out until Dec 08) wrote: > nit: null Done. https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:387: RenderFrameHostImpl* speculative_render_frame_host() const { On 2014/11/25 00:19:11, nasko (Out until Dec 08) wrote: > This isn't needed to be public. The tests that use it can be made friends of > this class. Done. https://codereview.chromium.org/701953006/diff/200001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:641: // only for the regular navigation (not yet true, but will be). On 2014/11/25 16:50:57, clamy wrote: > Remove the not yet true mention. It is true by now, right :)? Done. https://codereview.chromium.org/701953006/diff/270001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (left): https://codereview.chromium.org/701953006/diff/270001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:118: I already re-added this line locally (and this is the only change you are not seeing uploaded here).
I found some flakyness in one of my tests (on Windows Release) and I think it's a problem we might see in other tests as well. I was relying on a RFH pointer comparison between one instance that was already destroyed and a newly created one. They should be different but in this case they were not. It seems to me that the new one simply replaced the exact same memory position as the previous one and so the EXPECT_NE failed. This is especially true now for both the speculative and pending members because the changes I introduced make the destruction of the previous instance happen before the creation of the new one. Maybe not so much for other cases where an active RFH is replaced as it's not necessarily destroyed but more likely just swapped out. And as the swapped out state is supposed to be eliminated this kind of flakyness might being to happen more often. I marked one case I think could suffer from this problem with a comment as an example. https://codereview.chromium.org/701953006/diff/310001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/310001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:249: RenderFrameHostImpl* rfh = main_test_rfh(); This is one case where I think the flakyness I experienced with my test could happen again once RFH instances are destroyed instead of being swapped out. https://codereview.chromium.org/701953006/diff/310001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/310001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1602: // very welcome! I can see 3 resolutions for this: 1) We don't care all that much about this specific case where I'm using the speculative_* members to store the instances that will for sure be used 2) We rename these fields to something else that better reflects their dual use (speculative creation and this case here) 3) I refactor CreateSpeculativeRenderFrameHost so that it somehow allows the RFH and WebUI instances to be set to arbitrary smart pointers (passed as input parameters?) instead of always using the speculative ones. WDYT?
Thanks! A few more comments but it's looking good otherwise. https://chromiumcodereview.appspot.com/701953006/diff/310001/content/browser/... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/310001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:249: RenderFrameHostImpl* rfh = main_test_rfh(); On 2014/12/01 15:15:27, carlosk wrote: > This is one case where I think the flakyness I experienced with my test could > happen again once RFH instances are destroyed instead of being swapped out. Acknowledged. https://chromiumcodereview.appspot.com/701953006/diff/310001/content/browser/... File content/browser/frame_host/render_frame_host_manager.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/310001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:1399: bool use_speculative_rfh = CommandLine::ForCurrentProcess()->HasSwitch( nit: I would maybe rename this boolean to browser_side_navigation_enabled, or have the call to the command line argument directly down below. https://chromiumcodereview.appspot.com/701953006/diff/310001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:1422: } else { nit: please add a comment to specify that this block is only used in PlzNavigate. https://chromiumcodereview.appspot.com/701953006/diff/310001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:1451: } else { nit: please add a comment that specifies that this is used by PlzNavigate only. https://chromiumcodereview.appspot.com/701953006/diff/310001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:1593: // If the SiteInstance for the final URL doesn't match the one form the nit: s/form/from https://chromiumcodereview.appspot.com/701953006/diff/310001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:1602: // very welcome! On 2014/12/01 15:15:27, carlosk wrote: > I can see 3 resolutions for this: > 1) We don't care all that much about this specific case where I'm using the > speculative_* members to store the instances that will for sure be used > 2) We rename these fields to something else that better reflects their dual use > (speculative creation and this case here) > 3) I refactor CreateSpeculativeRenderFrameHost so that it somehow allows the RFH > and WebUI instances to be set to arbitrary smart pointers (passed as input > parameters?) instead of always using the speculative ones. > > WDYT? Note that 3 also means refactoring CommitPending so that it takes an arbitrary smart pointer :). Having a better name for this would be the ideal solution, but it is not so easy. I guess the best one would be pending, but it's already taken. So NextRenderFrameHost or CandidateRenderFrameHost maybe? Not sure if it's a lot better though. https://chromiumcodereview.appspot.com/701953006/diff/310001/content/browser/... File content/browser/frame_host/render_frame_host_manager.h (right): https://chromiumcodereview.appspot.com/701953006/diff/310001/content/browser/... content/browser/frame_host/render_frame_host_manager.h:561: RenderFrameHostImpl* speculative_render_frame_host() const { If your accessor is private, why do you have an accessor at all?
Thanks. I addressed all comments but the speculative members naming one. https://codereview.chromium.org/701953006/diff/310001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/310001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1399: bool use_speculative_rfh = CommandLine::ForCurrentProcess()->HasSwitch( On 2014/12/02 12:59:27, clamy wrote: > nit: I would maybe rename this boolean to browser_side_navigation_enabled, or > have the call to the command line argument directly down below. Done. https://codereview.chromium.org/701953006/diff/310001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1422: } else { On 2014/12/02 12:59:27, clamy wrote: > nit: please add a comment to specify that this block is only used in > PlzNavigate. As I done the previous change this one doesn't seem necessary. https://codereview.chromium.org/701953006/diff/310001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1451: } else { On 2014/12/02 12:59:27, clamy wrote: > nit: please add a comment that specifies that this is used by PlzNavigate only. Same. https://codereview.chromium.org/701953006/diff/310001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1593: // If the SiteInstance for the final URL doesn't match the one form the On 2014/12/02 12:59:27, clamy wrote: > nit: s/form/from Done. https://codereview.chromium.org/701953006/diff/310001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1602: // very welcome! On 2014/12/02 12:59:27, clamy wrote: > On 2014/12/01 15:15:27, carlosk wrote: > > I can see 3 resolutions for this: > > 1) We don't care all that much about this specific case where I'm using the > > speculative_* members to store the instances that will for sure be used > > 2) We rename these fields to something else that better reflects their dual > use > > (speculative creation and this case here) > > 3) I refactor CreateSpeculativeRenderFrameHost so that it somehow allows the > RFH > > and WebUI instances to be set to arbitrary smart pointers (passed as input > > parameters?) instead of always using the speculative ones. > > > > WDYT? > > Note that 3 also means refactoring CommitPending so that it takes an arbitrary > smart pointer :). > > Having a better name for this would be the ideal solution, but it is not so > easy. I guess the best one would be pending, but it's already taken. So > NextRenderFrameHost or CandidateRenderFrameHost maybe? Not sure if it's a lot > better though. I agree 3) would not worth it because of the extra changes involved. So we're up with changing or not changing the name. As I don't have a strong opinion either way I'll wait on creis@ comments on this. https://codereview.chromium.org/701953006/diff/310001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/310001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:561: RenderFrameHostImpl* speculative_render_frame_host() const { On 2014/12/02 12:59:27, clamy wrote: > If your accessor is private, why do you have an accessor at all? Done.
Patchset #16 (id:350001) has been deleted
Patchset #15 (id:330001) has been deleted
I revisited the DiscardUnusedFrame method based on a previous comment from creis@. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:577: scoped_ptr<RenderFrameHostImpl> render_frame_host) { Continuing the discussion that was started in crrev.com/753173002 regarding calling RFHM::DiscardUnusedFrame for the speculative case: On 2014/12/01 20:12:46, Charlie Reis wrote: > On 2014/11/27 11:02:43, carlosk wrote: > > On 2014/11/26 01:06:40, Charlie Reis (OOO until Dec 1) wrote: > > > This makes sense when called by CancelPending. > > > > > > Are you planning to use this method for speculative RFHs as well? In that > > case > > > I don't think we'll need to call SwapOut. Either it was already swapped out > > > (and we didn't swap it in) or we created it from scratch and we can delete > it. > > > > > (That can be a topic for the next CL, though.) > > > > Yes, it should be a topic for the other CL. > > Sounds good. > > > > > But at this point if the RFH was previously swapped out it did already went > > through the process of being swapped-in (at least I think that's what happens > in > > RFHM::CreateRenderFrame in the if-block beginning with: > > > > if (proxy && proxy->render_frame_host()) { > > > > Isn't that so? > > No, that block just deletes the proxy. We don't actually change the state away > from STATE_SWAPPED_OUT until we get to the RFHI::Navigate call. > > > > > Also at this point we have no idea if the RFH was newly created or not. > I had a second look at this and now I understand the importance of not calling SwapOut on a RFH that is already in that state. Even so it seems like the current implementation (with the fix below) is correct as it will properly handle both situations: * When the RFH was gotten from the swapped out map, it will recreate the previously deleted proxy and re-add it to the map. * When a newly created is used it's simply deleted. Maybe the checks for this are a little convoluted for PlzNavigate (SiteInstance active frame count instead of is_swapped_out()) but that makes it work both in this case and for the current navigation.
Thanks! Once the final comments over the swapped out state are resolved, it should be good. https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... File content/browser/frame_host/render_frame_host_manager.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:577: scoped_ptr<RenderFrameHostImpl> render_frame_host) { On 2014/12/03 16:25:25, carlosk wrote: > Continuing the discussion that was started in crrev.com/753173002 regarding > calling RFHM::DiscardUnusedFrame for the speculative case: > > On 2014/12/01 20:12:46, Charlie Reis wrote: > > On 2014/11/27 11:02:43, carlosk wrote: > > > On 2014/11/26 01:06:40, Charlie Reis (OOO until Dec 1) wrote: > > > > This makes sense when called by CancelPending. > > > > > > > > Are you planning to use this method for speculative RFHs as well? In that > > > case > > > > I don't think we'll need to call SwapOut. Either it was already swapped > out > > > > (and we didn't swap it in) or we created it from scratch and we can delete > > it. > > > > > > > (That can be a topic for the next CL, though.) > > > > > > Yes, it should be a topic for the other CL. > > > > Sounds good. > > > > > > > > But at this point if the RFH was previously swapped out it did already went > > > through the process of being swapped-in (at least I think that's what > happens > > in > > > RFHM::CreateRenderFrame in the if-block beginning with: > > > > > > if (proxy && proxy->render_frame_host()) { > > > > > > Isn't that so? > > > > No, that block just deletes the proxy. We don't actually change the state > away > > from STATE_SWAPPED_OUT until we get to the RFHI::Navigate call. > > > > > > > > Also at this point we have no idea if the RFH was newly created or not. > > > > I had a second look at this and now I understand the importance of not calling > SwapOut on a RFH that is already in that state. > > Even so it seems like the current implementation (with the fix below) is correct > as it will properly handle both situations: > * When the RFH was gotten from the swapped out map, it will recreate the > previously deleted proxy and re-add it to the map. > * When a newly created is used it's simply deleted. > > Maybe the checks for this are a little convoluted for PlzNavigate (SiteInstance > active frame count instead of is_swapped_out()) but that makes it work both in > this case and for the current navigation. Speaking of swapped out state, does the CommitPending method set the state of the RFH we swap in to DEFAULT? Otherwise since PlzNavigate does not call RFHI::Navigate, we may swap back in a RFH in state swapped out. If that's the case, we should have go back to default state before swapping it in.
Ok, I've started a pass through the CL but haven't gotten to the main code (render_frame_host_manager.cc) yet. I thought I'd send out the comments I have so far since I need to head home now. I'll finish up the .cc file tomorrow. Apologies if any of this was covered in earlier discussion. I'm thinking about whether there will be any issues with switching the speculative RFH to be the current RFH at the time of OnResponseStarted. I think that should probably be fine as long as we start to swap out the current RFH at that point as well. (Might want to double check that it doesn't affect the Navigation Transitions work.) https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:230: ASSERT_TRUE(main_request); Can we verify that there's no pending RFH here? And do we expect there to be a speculative RFH at this point? (My guess is yes.) https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:233: GetLoaderForNavigationRequest(main_request)->CallOnResponseStarted( I'm a bit confused by what this means. Before, it created a pending RFH but hadn't committed it. Now, the new RFH has already committed. Where are we in the navigation timeline? Has the new NavigationEntry committed? Maybe it would help to add that stage to the test if not. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:273: EXPECT_FALSE(GetSpeculativeRenderFrameHost(rfhm)); Why is there no speculative RFH after it redirects cross site? Is that planned for later? (Seems like we might as well create one while we're waiting for the new response.) If we're not planning to create one in this CL, then a TODO here might be worthwhile. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:312: // Confirms a speculative RFH was created nit: Please end sentences with a period, here and below. Also "Confirm" rather than "Confirms" (as elsewhere in this test). https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:314: int32 first_site_id = nit: site_instance_id1 and site_instance_id2 would be clearer names, since sites don't have IDs. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:315: GetSpeculativeRenderFrameHost(rfhm)->GetSiteInstance()->GetId(); Let's also verify that GetSiteURL() is kUrl1_site (similar to the kUrl2_site check below). https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:402: GetSpeculativeRenderFrameHost(rfhm)->GetSiteInstance()->GetSiteURL(), nit: Switch argument order. (EXPECT_EQ(expected, actual)) https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:405: GetSpeculativeRenderFrameHost(rfhm)->GetProcess()->HasConnection()); We're in a unit test (with MockRenderProcessHosts), so this can't fail. Might as well leave it out. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:406: int32 site_id = Same nit as above. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:409: // Commit. I'm still finding it very confusing to call this "commit," which sounds a lot like DidCommit. Here (and in general), let's try to clarify it (e.g., "Ask the renderer to commit the response"). https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:431: // the final URL's site differ from the initial one due to redirects. nit: differs https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:450: GetSpeculativeRenderFrameHost(rfhm)->GetProcess()->HasConnection()); Same as above. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:468: EXPECT_EQ(site_id, The test says the redirect is expected to discard the speculative RFH. Why is it still around with the old SiteInstance? Also, as mentioned earlier, it seems like we should go ahead and create a new speculative RFH for the new site. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:471: // Commit. See comment in previous test. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (left): https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:37: class RenderFrameHostManagerTest; I'm not sure we want to delete this. It may not be strictly necessary, but it's consistent with other code (e.g., see render_view_host_impl.h, render_widget.h), and it's in the spirit of "include what you use." Let's avoid this churn unless there's a good reason for it. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:376: // Called when a navigation is ready to commit, to select the renderer that nit: renderer -> RenderFrameHost https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:382: // Cancels any ongoing navigation. nit: Cancels any state for any ongoing navigation. This code doesn't cancel the navigation itself. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:483: // speculative creation of a new renderer for an ongoing navigation request. creation of a new speculative RenderFrameHost for... https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:511: // RenderFrameHost to be the active one instead of the pending. nit: set the speculative (not pending) RenderFrameHost to be the active one. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:593: scoped_ptr<RenderFrameHostImpl> pending_render_frame_host_; Let's add: Note: This is not used in PlzNavigate. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:627: base::WeakPtrFactory<RenderFrameHostManager> weak_factory_; WeakPtrFactories always have to be the last member of the class. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:635: // pending one only for the regular navigation. "for the regular navigation" is a bit awkward. Maybe: Note: PlzNavigate only uses speculative RenderFrameHosts and not pending ones.
And here's the rest of the comments for the .cc file! Sorry for the large number of questions, but I think it'll be worthwhile to get this to an easy-to-follow state. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:64: weak_factory_(this), weak_factory_ must be last. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:433: return; I'm not sure this is correct. What happens if a DidNavigate from the previous RFH arrives just after we've decided to commit in the new one? We'll return without doing anything here, but the NavigationController will probably update the last committed entry to the URL from the previous RFH. We'll end up with a mismatch between the address bar and the actual page contents until the new RFH commits. Not sure what the right behavior in that case is. If we know we've already left the previous RFH, maybe we should ignore the commit? I'm concerned what impact that has in the previous renderer process, but maybe it's ok. (Also see this CL, which is changing the logic below: https://codereview.chromium.org/746993003/) https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:577: scoped_ptr<RenderFrameHostImpl> render_frame_host) { On 2014/12/03 17:24:48, clamy wrote: > On 2014/12/03 16:25:25, carlosk wrote: > > Continuing the discussion that was started in crrev.com/753173002 regarding > > calling RFHM::DiscardUnusedFrame for the speculative case: > > > > On 2014/12/01 20:12:46, Charlie Reis wrote: > > > On 2014/11/27 11:02:43, carlosk wrote: > > > > On 2014/11/26 01:06:40, Charlie Reis (OOO until Dec 1) wrote: > > > > > This makes sense when called by CancelPending. > > > > > > > > > > Are you planning to use this method for speculative RFHs as well? In > that > > > > case > > > > > I don't think we'll need to call SwapOut. Either it was already swapped > > out > > > > > (and we didn't swap it in) or we created it from scratch and we can > delete > > > it. > > > > > > > > > (That can be a topic for the next CL, though.) > > > > > > > > Yes, it should be a topic for the other CL. > > > > > > Sounds good. > > > > > > > > > > > But at this point if the RFH was previously swapped out it did already > went > > > > through the process of being swapped-in (at least I think that's what > > happens > > > in > > > > RFHM::CreateRenderFrame in the if-block beginning with: > > > > > > > > if (proxy && proxy->render_frame_host()) { > > > > > > > > Isn't that so? > > > > > > No, that block just deletes the proxy. We don't actually change the state > > away > > > from STATE_SWAPPED_OUT until we get to the RFHI::Navigate call. > > > > > > > > > > > Also at this point we have no idea if the RFH was newly created or not. > > > > > > > I had a second look at this and now I understand the importance of not calling > > SwapOut on a RFH that is already in that state. > > > > Even so it seems like the current implementation (with the fix below) is > correct > > as it will properly handle both situations: > > * When the RFH was gotten from the swapped out map, it will recreate the > > previously deleted proxy and re-add it to the map. > > * When a newly created is used it's simply deleted. > > > > Maybe the checks for this are a little convoluted for PlzNavigate > (SiteInstance > > active frame count instead of is_swapped_out()) but that makes it work both in > > this case and for the current navigation. Sounds good. > Speaking of swapped out state, does the CommitPending method set the state of > the RFH we swap in to DEFAULT? Otherwise since PlzNavigate does not call > RFHI::Navigate, we may swap back in a RFH in state swapped out. If that's the > case, we should have go back to default state before swapping it in. Good question. CommitPending does not, so we'll need to find the right place to do it. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:639: void RenderFrameHostManager::BeginNavigation( This code looks a lot like UpdateStateForNavigate, but it's missing a lot from there. Is the intention for this to replace that method eventually, once enough of it is moved over? If so, we should have a TODO to that effect. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:644: // If there is an ongoing navigation, cancel it. cancel it -> cancel any state we have for it. (RFHM is just a state machine for the process logic, so it doesn't handle canceling the navigation itself. Do you need the actual navigation to be canceled as well?) https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:648: // TODO(carlosk): Replace the default values with the right ones. I see this is the same TODO as in GetFrameHostForNavigation. Both are a bit vague-- are they referring to dest_is_restore and dest_is_view_source_mode? Let's call them out by name to make this TODO easier to fix in the future (assuming we can't fix it now). https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:654: (frame_tree_node_->IsMainFrame() || These additional checks are non-obvious, so please add a comment for them. They're making me realize that I'm not sure what process model you're intending for PlzNavigate. Today, Chrome is careful not to swap processes for most renderer-initiated cross-site navigations (in the main frame). This is for important reasons, like OAuth popups where a cross-site iframe creates a popup that needs to stay in the same process. It looks like this check is creating a policy halfway between default Chrome behavior and --site-per-process, in a way that breaks OAuth popups. Perhaps we should discuss (in a separate email?) what process model policy you all want PlzNavigate to use, and then we can make it happen here. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:666: DCHECK(new_instance->GetProcess()->GetBrowserContext()); This second check seems unnecessary. Is there a way it could not have a BrowserContext? https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:667: } else { nit: Return here inside the previous block, so that the rest does not need to be inside an else block. (Similar to UpdateStateForNavigate.) https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1409: if (!CommandLine::ForCurrentProcess()->HasSwitch( Please cache this in a bool so we don't repeatedly call it below. (That will also be easier to read.) https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1426: web_ui_.reset(speculative_web_ui_.release()); Let's add a DCHECK(!speculative_web_ui_) after this block, which will verify that it didn't exist if should_reuse_web_ui_ was true. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1434: switches::kEnableBrowserSideNavigation)) { Can we make this !pending_render_frame_host_ && !speculative_render_frame_host_ instead? That would be easier to reason about. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1590: if (CommandLine::ForCurrentProcess()->HasSwitch( This doesn't feel like it fits here. Most of UpdateStateForNavigate (below this block) ends up not being used in PlzNavigate at all. In that case, why not put this logic in GetFrameHostForNavigation, and just copy the first few lines above there as well? (We've already copied them into BeginNavigation.) https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1593: (!frame_tree_node_->IsMainFrame() && Same concern about the process model policy. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1605: // TODO(carlosk): Should rename this method and the speculative members I'm not concerned about the name. We're creating them and then immediately committing them, so it's not visible outside of this block. We could restructure so that CreateSpeculativeRenderFrameHost is a method that returns an RFH instead of assigning it, but I'm not sure if that's worthwhile. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:631: // allowing the creation of the renderer process as early as possible. This first sentence is a bit awkward. Maybe simplify to just convey the intent, and mention it's an optimization: We create a speculative RenderFrameHost early during a navigation to give the renderer process time to start. It is purely an optimization and is not required for correct behavior.
A few comments as well. Maybe the CL could be split again in two, between the part where we move the actual commit time and get rid of the pending rfh, and the part specifically about the speculative render frame host being spawned. Wdyt? https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:233: GetLoaderForNavigationRequest(main_request)->CallOnResponseStarted( On 2014/12/04 01:11:30, Charlie Reis wrote: > I'm a bit confused by what this means. Before, it created a pending RFH but > hadn't committed it. Now, the new RFH has already committed. > > Where are we in the navigation timeline? Has the new NavigationEntry committed? > Maybe it would help to add that stage to the test if not. The new RFH is only committed after this call (this simulates the IO thread signaling us that a navigation is ready to be committed). The navigation entry is still committed after receiving the DidCommitProvisionalLoad IPC. This may be a problem, and I think we should move the commit of the NavigationEntry at the same time as the RFH swap in (ie in response to NavigatorImpl::CommitNavigation). https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:405: GetSpeculativeRenderFrameHost(rfhm)->GetProcess()->HasConnection()); On 2014/12/04 01:11:30, Charlie Reis wrote: > We're in a unit test (with MockRenderProcessHosts), so this can't fail. Might > as well leave it out. This could be replaced by a call to RFH::IsRenderFrameLive(), and we would still test that we initialized the speculative rfh. https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... File content/browser/frame_host/render_frame_host_manager.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:433: return; On 2014/12/04 21:46:28, Charlie Reis wrote: > I'm not sure this is correct. > > What happens if a DidNavigate from the previous RFH arrives just after we've > decided to commit in the new one? We'll return without doing anything here, but > the NavigationController will probably update the last committed entry to the > URL from the previous RFH. We'll end up with a mismatch between the address bar > and the actual page contents until the new RFH commits. > > Not sure what the right behavior in that case is. If we know we've already left > the previous RFH, maybe we should ignore the commit? I'm concerned what impact > that has in the previous renderer process, but maybe it's ok. > > (Also see this CL, which is changing the logic below: > https://codereview.chromium.org/746993003/) If we go along with committing the NavigationEntry at the same time as we swap renderers, then the only issue would be with same-document navigations (since all other renderer initiated navigations should go to the browser). In that case, would the behavior ignore this same-document navigation because it arrived after the commit of another pending navigation be ok? This implies not committing an entry for the same-document navigation in that case as well. https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:577: scoped_ptr<RenderFrameHostImpl> render_frame_host) { On 2014/12/04 21:46:28, Charlie Reis wrote: > On 2014/12/03 17:24:48, clamy wrote: > > On 2014/12/03 16:25:25, carlosk wrote: > > > Continuing the discussion that was started in crrev.com/753173002 regarding > > > calling RFHM::DiscardUnusedFrame for the speculative case: > > > > > > On 2014/12/01 20:12:46, Charlie Reis wrote: > > > > On 2014/11/27 11:02:43, carlosk wrote: > > > > > On 2014/11/26 01:06:40, Charlie Reis (OOO until Dec 1) wrote: > > > > > > This makes sense when called by CancelPending. > > > > > > > > > > > > Are you planning to use this method for speculative RFHs as well? In > > that > > > > > case > > > > > > I don't think we'll need to call SwapOut. Either it was already > swapped > > > out > > > > > > (and we didn't swap it in) or we created it from scratch and we can > > delete > > > > it. > > > > > > > > > > > (That can be a topic for the next CL, though.) > > > > > > > > > > Yes, it should be a topic for the other CL. > > > > > > > > Sounds good. > > > > > > > > > > > > > > But at this point if the RFH was previously swapped out it did already > > went > > > > > through the process of being swapped-in (at least I think that's what > > > happens > > > > in > > > > > RFHM::CreateRenderFrame in the if-block beginning with: > > > > > > > > > > if (proxy && proxy->render_frame_host()) { > > > > > > > > > > Isn't that so? > > > > > > > > No, that block just deletes the proxy. We don't actually change the state > > > away > > > > from STATE_SWAPPED_OUT until we get to the RFHI::Navigate call. > > > > > > > > > > > > > > Also at this point we have no idea if the RFH was newly created or not. > > > > > > > > > > I had a second look at this and now I understand the importance of not > calling > > > SwapOut on a RFH that is already in that state. > > > > > > Even so it seems like the current implementation (with the fix below) is > > correct > > > as it will properly handle both situations: > > > * When the RFH was gotten from the swapped out map, it will recreate the > > > previously deleted proxy and re-add it to the map. > > > * When a newly created is used it's simply deleted. > > > > > > Maybe the checks for this are a little convoluted for PlzNavigate > > (SiteInstance > > > active frame count instead of is_swapped_out()) but that makes it work both > in > > > this case and for the current navigation. > > Sounds good. > > > Speaking of swapped out state, does the CommitPending method set the state of > > the RFH we swap in to DEFAULT? Otherwise since PlzNavigate does not call > > RFHI::Navigate, we may swap back in a RFH in state swapped out. If that's the > > case, we should have go back to default state before swapping it in. > > Good question. CommitPending does not, so we'll need to find the right place to > do it. One option could be to have RFH::CommitNavigation call it, in the same way RFH::Navigate currently reset the state of the RFH before navigating. Granted, this happens just after the RFH has been swapped in in the PlzNavigate case. https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:644: // If there is an ongoing navigation, cancel it. On 2014/12/04 21:46:28, Charlie Reis wrote: > cancel it -> cancel any state we have for it. > > (RFHM is just a state machine for the process logic, so it doesn't handle > canceling the navigation itself. Do you need the actual navigation to be > canceled as well?) NavigatorImpl is normally responsible for canceling the actual navigation. This should be a state clean up. https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:648: // TODO(carlosk): Replace the default values with the right ones. On 2014/12/04 21:46:28, Charlie Reis wrote: > I see this is the same TODO as in GetFrameHostForNavigation. Both are a bit > vague-- are they referring to dest_is_restore and dest_is_view_source_mode? > Let's call them out by name to make this TODO easier to fix in the future > (assuming we can't fix it now). Note that it also concerns the SiteInstance pointer that may be provided by the NavigationEntry. https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:654: (frame_tree_node_->IsMainFrame() || On 2014/12/04 21:46:28, Charlie Reis wrote: > These additional checks are non-obvious, so please add a comment for them. > > They're making me realize that I'm not sure what process model you're intending > for PlzNavigate. Today, Chrome is careful not to swap processes for most > renderer-initiated cross-site navigations (in the main frame). This is for > important reasons, like OAuth popups where a cross-site iframe creates a popup > that needs to stay in the same process. > > It looks like this check is creating a policy halfway between default Chrome > behavior and --site-per-process, in a way that breaks OAuth popups. Perhaps we > should discuss (in a separate email?) what process model policy you all want > PlzNavigate to use, and then we can make it happen here. In that case, we need to be able to distinguish here between a renderer-initiated navigation and a browser-initiated one. We don't do it right now, though it would be useful for other purposes (ie canceling or not an ongoing navigation request). Would a TODO: do not swap processes for renderer initiated navigations be sufficient for the time being, with the goal to revise it when we have agreed on a process model to use?
On 2014/12/05 17:16:19, clamy wrote: > A few comments as well. Maybe the CL could be split again in two, between the > part where we move the actual commit time and get rid of the pending rfh, and > the part specifically about the speculative render frame host being spawned. > Wdyt? I'm not terribly concerned about the size of this CL, but I do like this suggestion for two reasons. First, it means we'll be able to observe any fallout from changing the time of RFH commit (which is very risky in my opinion due to the NavigationEntry issue) on its own. Second, it means we'll be able to compare the performance gains of adding a speculative RFH without other behavior changes mixed in. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:233: GetLoaderForNavigationRequest(main_request)->CallOnResponseStarted( On 2014/12/05 17:16:19, clamy wrote: > On 2014/12/04 01:11:30, Charlie Reis wrote: > > I'm a bit confused by what this means. Before, it created a pending RFH but > > hadn't committed it. Now, the new RFH has already committed. > > > > Where are we in the navigation timeline? Has the new NavigationEntry > committed? > > Maybe it would help to add that stage to the test if not. > > The new RFH is only committed after this call (this simulates the IO thread > signaling us that a navigation is ready to be committed). Oh, I get it. CallOnResponseStarted used to create the pending RFH and it wasn't committed until DidCommitProvisionalLoad. As a result of this CL, we commit the speculative RFH at this time. > The navigation entry > is still committed after receiving the DidCommitProvisionalLoad IPC. This may be > a problem, and I think we should move the commit of the NavigationEntry at the > same time as the RFH swap in (ie in response to > NavigatorImpl::CommitNavigation). This makes me very nervous. I agree that it's not great to commit the RFH earlier than the NavigationEntry, but it's also very bad to say that a NavigationEntry has committed when it hasn't. There's huge potential for URL spoofs in that case. The problem is that it's still too hard to guarantee that we'll see the commit we're expecting. Even if we ignore the fact that the renderer process might crash or be slow, there's just a whole lot of content+Blink code between OnCommitNavigation and DidCommitProvisionalLoad in the renderer. Without auditing that, I don't know if we have a 100% guarantee we'll get a commit of the URL we were expecting, or if something might alter it. Maybe it's worth auditing that code to see if we can get a guarantee? https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:433: return; On 2014/12/05 17:16:19, clamy wrote: > On 2014/12/04 21:46:28, Charlie Reis wrote: > > I'm not sure this is correct. > > > > What happens if a DidNavigate from the previous RFH arrives just after we've > > decided to commit in the new one? We'll return without doing anything here, > but > > the NavigationController will probably update the last committed entry to the > > URL from the previous RFH. We'll end up with a mismatch between the address > bar > > and the actual page contents until the new RFH commits. > > > > Not sure what the right behavior in that case is. If we know we've already > left > > the previous RFH, maybe we should ignore the commit? I'm concerned what > impact > > that has in the previous renderer process, but maybe it's ok. > > > > (Also see this CL, which is changing the logic below: > > https://codereview.chromium.org/746993003/) > > If we go along with committing the NavigationEntry at the same time as we swap > renderers, then the only issue would be with same-document navigations (since > all other renderer initiated navigations should go to the browser). In that > case, would the behavior ignore this same-document navigation because it arrived > after the commit of another pending navigation be ok? This implies not > committing an entry for the same-document navigation in that case as well. I'm nervous about this as well: ignoring a commit usually leads to URL spoofs. Also, the renderer process keeps track of the offset and length of history, which would be wrong in this case. (Today it also keeps track of page IDs for the whole history, but Avi's removing that.) https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:654: (frame_tree_node_->IsMainFrame() || On 2014/12/05 17:16:19, clamy wrote: > On 2014/12/04 21:46:28, Charlie Reis wrote: > > These additional checks are non-obvious, so please add a comment for them. > > > > They're making me realize that I'm not sure what process model you're > intending > > for PlzNavigate. Today, Chrome is careful not to swap processes for most > > renderer-initiated cross-site navigations (in the main frame). This is for > > important reasons, like OAuth popups where a cross-site iframe creates a popup > > that needs to stay in the same process. > > > > It looks like this check is creating a policy halfway between default Chrome > > behavior and --site-per-process, in a way that breaks OAuth popups. Perhaps > we > > should discuss (in a separate email?) what process model policy you all want > > PlzNavigate to use, and then we can make it happen here. > > In that case, we need to be able to distinguish here between a > renderer-initiated navigation and a browser-initiated one. We don't do it right > now, though it would be useful for other purposes (ie canceling or not an > ongoing navigation request). Would a TODO: do not swap processes for renderer > initiated navigations be sufficient for the time being, with the goal to revise > it when we have agreed on a process model to use? Yes, but this is an important TODO we'll need to resolve. Let's include a bug number for it.
Patchset #16 (id:390001) has been deleted
Sorry the extended delay to reply and the large number of comments here. Sickness, trip to MTV and orientation got me busy! Thanks clamy@ for clarifying some of my changes; I had quite some explanations already lined up but didn't have the chance to upload them. Anyway... On 2014/12/04 01:11:32, Charlie Reis wrote: > I'm thinking about whether there will be any issues with switching the > speculative RFH to be the current RFH at the time of OnResponseStarted. I think > that should probably be fine as long as we start to swap out the current RFH at > that point as well. (Might want to double check that it doesn't affect the > Navigation Transitions work.) As I mention below we could also move the RFH switching to the later step. On 2014/12/05 19:06:23, Charlie Reis wrote: > On 2014/12/05 17:16:19, clamy wrote: > > A few comments as well. Maybe the CL could be split again in two, between the > > part where we move the actual commit time and get rid of the pending rfh, and > > the part specifically about the speculative render frame host being spawned. > > Wdyt? > > I'm not terribly concerned about the size of this CL, but I do like this > suggestion for two reasons. First, it means we'll be able to observe any > fallout from changing the time of RFH commit (which is very risky in my opinion > due to the NavigationEntry issue) on its own. Second, it means we'll be able to > compare the performance gains of adding a speculative RFH without other behavior > changes mixed in. If we chose to push the RFH switching for to the commit-provisional-load time we would eliminate the problem with the NavigationEntry. And as we're for now not systematically measuring performance improvements I don't thin it would help. But if even so you'd think that's a good idea I can do it. Let me know. This CL will need a new PatchSet anyway because of a new, failing test I added (explained in a comment). https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:230: ASSERT_TRUE(main_request); On 2014/12/04 01:11:30, Charlie Reis wrote: > Can we verify that there's no pending RFH here? And do we expect there to be a > speculative RFH at this point? (My guess is yes.) Note: Initially I just added a couple tests and expanded a few of the existing to include speculative renderer checks. Going over your comments it seemed like doing that for all tests was the right thing to do. Well, it's done now. It seems weird to add checks for the pending RFH as all of them will be EXPECT_FALSE as it should not be used anymore when PlzNavigate is enabled. Also these checks would have to be removed once we enable PlzNavigate for good. But I agree it's also weird that there are currently some checks for that throughout this unittest file. WDYT? Should I add these checks everywhere or remove them entirely? https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:233: GetLoaderForNavigationRequest(main_request)->CallOnResponseStarted( On 2014/12/05 19:06:23, Charlie Reis wrote: > On 2014/12/05 17:16:19, clamy wrote: > > On 2014/12/04 01:11:30, Charlie Reis wrote: > > > I'm a bit confused by what this means. Before, it created a pending RFH but > > > hadn't committed it. Now, the new RFH has already committed. > > > > > > Where are we in the navigation timeline? Has the new NavigationEntry > > committed? > > > Maybe it would help to add that stage to the test if not. > > > > The new RFH is only committed after this call (this simulates the IO thread > > signaling us that a navigation is ready to be committed). > > Oh, I get it. CallOnResponseStarted used to create the pending RFH and it > wasn't committed until DidCommitProvisionalLoad. As a result of this CL, we > commit the speculative RFH at this time. > > > The navigation entry > > is still committed after receiving the DidCommitProvisionalLoad IPC. This may > be > > a problem, and I think we should move the commit of the NavigationEntry at the > > same time as the RFH swap in (ie in response to > > NavigatorImpl::CommitNavigation). > > This makes me very nervous. I agree that it's not great to commit the RFH > earlier than the NavigationEntry, but it's also very bad to say that a > NavigationEntry has committed when it hasn't. There's huge potential for URL > spoofs in that case. > > The problem is that it's still too hard to guarantee that we'll see the commit > we're expecting. Even if we ignore the fact that the renderer process might > crash or be slow, there's just a whole lot of content+Blink code between > OnCommitNavigation and DidCommitProvisionalLoad in the renderer. Without > auditing that, I don't know if we have a 100% guarantee we'll get a commit of > the URL we were expecting, or if something might alter it. > > Maybe it's worth auditing that code to see if we can get a guarantee? I can do the audit but I'd need more details on what I should be looking for. If I understood what you said it seems the main thing would be to verify that there's no way the navigation could be cancelled in between the RFH being made active and the call to DidNavigate, right? And what else? Another option would be to simply move the RFH swapping back to did-commit-provisional-load time if that makes more sense and keeps the RFH in sync with the other involved components. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:273: EXPECT_FALSE(GetSpeculativeRenderFrameHost(rfhm)); On 2014/12/04 01:11:30, Charlie Reis wrote: > Why is there no speculative RFH after it redirects cross site? Is that planned > for later? (Seems like we might as well create one while we're waiting for the > new response.) > > If we're not planning to create one in this CL, then a TODO here might be > worthwhile. Indeed that is a task for later on. The idea is to monitor redirects --- that now are conveniently tracked at the browser side -- to update the speculative RFH accordingly. But we have to be careful with this as we'll possibly be creating quite some churn by creating and destroying RFH in bursts. Also this made me think that the question regarding the name choice of "speculative" might be the right one (see respective comment in RFHM) as when we actually implement this that all we will have are speculative RFH until the last redirect. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:312: // Confirms a speculative RFH was created On 2014/12/04 01:11:30, Charlie Reis wrote: > nit: Please end sentences with a period, here and below. Also "Confirm" rather > than "Confirms" (as elsewhere in this test). Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:314: int32 first_site_id = On 2014/12/04 01:11:30, Charlie Reis wrote: > nit: site_instance_id1 and site_instance_id2 would be clearer names, since sites > don't have IDs. Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:315: GetSpeculativeRenderFrameHost(rfhm)->GetSiteInstance()->GetId(); On 2014/12/04 01:11:30, Charlie Reis wrote: > Let's also verify that GetSiteURL() is kUrl1_site (similar to the kUrl2_site > check below). Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:402: GetSpeculativeRenderFrameHost(rfhm)->GetSiteInstance()->GetSiteURL(), On 2014/12/04 01:11:30, Charlie Reis wrote: > nit: Switch argument order. (EXPECT_EQ(expected, actual)) Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:405: GetSpeculativeRenderFrameHost(rfhm)->GetProcess()->HasConnection()); On 2014/12/04 01:11:30, Charlie Reis wrote: > We're in a unit test (with MockRenderProcessHosts), so this can't fail. Might > as well leave it out. Acknowledged and done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:406: int32 site_id = On 2014/12/04 01:11:30, Charlie Reis wrote: > Same nit as above. Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:409: // Commit. On 2014/12/04 01:11:30, Charlie Reis wrote: > I'm still finding it very confusing to call this "commit," which sounds a lot > like DidCommit. Here (and in general), let's try to clarify it (e.g., "Ask the > renderer to commit the response"). It seemed to me that "commit" was the usually accepted name for this step in the navigation process. I updated the comment to be more explicit but PTAL. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:431: // the final URL's site differ from the initial one due to redirects. On 2014/12/04 01:11:30, Charlie Reis wrote: > nit: differs Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:450: GetSpeculativeRenderFrameHost(rfhm)->GetProcess()->HasConnection()); On 2014/12/04 01:11:30, Charlie Reis wrote: > Same as above. Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:468: EXPECT_EQ(site_id, On 2014/12/04 01:11:30, Charlie Reis wrote: > The test says the redirect is expected to discard the speculative RFH. Why is > it still around with the old SiteInstance? > > Also, as mentioned earlier, it seems like we should go ahead and create a new > speculative RFH for the new site. As we're not *yet* monitoring redirects the speculative RFH is still the old, now stale one. So this is correct, for now. It's here as a mark/failure point for when we begin monitoring redirects. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:471: // Commit. On 2014/12/04 01:11:30, Charlie Reis wrote: > See comment in previous test. Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:64: weak_factory_(this), On 2014/12/04 21:46:28, Charlie Reis wrote: > weak_factory_ must be last. Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:433: return; On 2014/12/05 19:06:23, Charlie Reis wrote: > On 2014/12/05 17:16:19, clamy wrote: > > On 2014/12/04 21:46:28, Charlie Reis wrote: > > > I'm not sure this is correct. > > > > > > What happens if a DidNavigate from the previous RFH arrives just after we've > > > decided to commit in the new one? We'll return without doing anything here, > > but > > > the NavigationController will probably update the last committed entry to > the > > > URL from the previous RFH. We'll end up with a mismatch between the address > > bar > > > and the actual page contents until the new RFH commits. > > > > > > Not sure what the right behavior in that case is. If we know we've already > > left > > > the previous RFH, maybe we should ignore the commit? I'm concerned what > > impact > > > that has in the previous renderer process, but maybe it's ok. > > > > > > (Also see this CL, which is changing the logic below: > > > https://codereview.chromium.org/746993003/) > > > > If we go along with committing the NavigationEntry at the same time as we swap > > renderers, then the only issue would be with same-document navigations (since > > all other renderer initiated navigations should go to the browser). In that > > case, would the behavior ignore this same-document navigation because it > arrived > > after the commit of another pending navigation be ok? This implies not > > committing an entry for the same-document navigation in that case as well. > > I'm nervous about this as well: ignoring a commit usually leads to URL spoofs. > Also, the renderer process keeps track of the offset and length of history, > which would be wrong in this case. (Today it also keeps track of page IDs for > the whole history, but Avi's removing that.) I'm having trouble following your lines of thought here because I don't know about the cases you are referring to here. But it seems to me that these issues might also be resolved by moving the RFH swapping to this place as I mentioned in a previous comment. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:577: scoped_ptr<RenderFrameHostImpl> render_frame_host) { On 2014/12/05 17:16:19, clamy wrote: > On 2014/12/04 21:46:28, Charlie Reis wrote: > > On 2014/12/03 17:24:48, clamy wrote: > > > On 2014/12/03 16:25:25, carlosk wrote: > > > > Continuing the discussion that was started in crrev.com/753173002 > regarding > > > > calling RFHM::DiscardUnusedFrame for the speculative case: > > > > > > > > On 2014/12/01 20:12:46, Charlie Reis wrote: > > > > > On 2014/11/27 11:02:43, carlosk wrote: > > > > > > On 2014/11/26 01:06:40, Charlie Reis (OOO until Dec 1) wrote: > > > > > > > This makes sense when called by CancelPending. > > > > > > > > > > > > > > Are you planning to use this method for speculative RFHs as well? > In > > > that > > > > > > case > > > > > > > I don't think we'll need to call SwapOut. Either it was already > > swapped > > > > out > > > > > > > (and we didn't swap it in) or we created it from scratch and we can > > > delete > > > > > it. > > > > > > > > > > > > > (That can be a topic for the next CL, though.) > > > > > > > > > > > > Yes, it should be a topic for the other CL. > > > > > > > > > > Sounds good. > > > > > > > > > > > > > > > > > But at this point if the RFH was previously swapped out it did already > > > went > > > > > > through the process of being swapped-in (at least I think that's what > > > > happens > > > > > in > > > > > > RFHM::CreateRenderFrame in the if-block beginning with: > > > > > > > > > > > > if (proxy && proxy->render_frame_host()) { > > > > > > > > > > > > Isn't that so? > > > > > > > > > > No, that block just deletes the proxy. We don't actually change the > state > > > > away > > > > > from STATE_SWAPPED_OUT until we get to the RFHI::Navigate call. > > > > > > > > > > > > > > > > > Also at this point we have no idea if the RFH was newly created or > not. > > > > > > > > > > > > > I had a second look at this and now I understand the importance of not > > calling > > > > SwapOut on a RFH that is already in that state. > > > > > > > > Even so it seems like the current implementation (with the fix below) is > > > correct > > > > as it will properly handle both situations: > > > > * When the RFH was gotten from the swapped out map, it will recreate the > > > > previously deleted proxy and re-add it to the map. > > > > * When a newly created is used it's simply deleted. > > > > > > > > Maybe the checks for this are a little convoluted for PlzNavigate > > > (SiteInstance > > > > active frame count instead of is_swapped_out()) but that makes it work > both > > in > > > > this case and for the current navigation. > > > > Sounds good. > > > > > Speaking of swapped out state, does the CommitPending method set the state > of > > > the RFH we swap in to DEFAULT? Otherwise since PlzNavigate does not call > > > RFHI::Navigate, we may swap back in a RFH in state swapped out. If that's > the > > > case, we should have go back to default state before swapping it in. > > > > Good question. CommitPending does not, so we'll need to find the right place > to > > do it. > > One option could be to have RFH::CommitNavigation call it, in the same way > RFH::Navigate currently reset the state of the RFH before navigating. Granted, > this happens just after the RFH has been swapped in in the PlzNavigate case. It seems we need a test for a speculative RFH that is swapped back in... I'll work on that next so for now I just added a failing test. Now for the actual moment where the RFH should be set to STATE_DEFAULT I am a tad lost. Should it be done immediately at the moment it's taken out of the swapped-out map? It seems that was how it works for the current navigation given how the "RFH recycling" works. Or maybe it should happen only later when the RFH is actually made active? https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:639: void RenderFrameHostManager::BeginNavigation( On 2014/12/04 21:46:28, Charlie Reis wrote: > This code looks a lot like UpdateStateForNavigate, but it's missing a lot from > there. Is the intention for this to replace that method eventually, once enough > of it is moved over? If so, we should have a TODO to that effect. Both methods do check if the current SiteInstance for the navigation matches the current/speculative SiteInstances but in different ways. Also the actions they take from there are completely different. I was not considering merging them. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:644: // If there is an ongoing navigation, cancel it. On 2014/12/05 17:16:19, clamy wrote: > On 2014/12/04 21:46:28, Charlie Reis wrote: > > cancel it -> cancel any state we have for it. > > > > (RFHM is just a state machine for the process logic, so it doesn't handle > > canceling the navigation itself. Do you need the actual navigation to be > > canceled as well?) > > NavigatorImpl is normally responsible for canceling the actual navigation. This > should be a state clean up. Updated the comment. This was more of a just-in-case action: whenever a new navigation begins any previous state is cleaned up. It doesn't seem that there's a guarantee that the cleanup happens otherwise. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:648: // TODO(carlosk): Replace the default values with the right ones. On 2014/12/05 17:16:19, clamy wrote: > On 2014/12/04 21:46:28, Charlie Reis wrote: > > I see this is the same TODO as in GetFrameHostForNavigation. Both are a bit > > vague-- are they referring to dest_is_restore and dest_is_view_source_mode? > > Let's call them out by name to make this TODO easier to fix in the future > > (assuming we can't fix it now). > > Note that it also concerns the SiteInstance pointer that may be provided by the > NavigationEntry. Updated comment. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:654: (frame_tree_node_->IsMainFrame() || On 2014/12/05 19:06:23, Charlie Reis wrote: > On 2014/12/05 17:16:19, clamy wrote: > > On 2014/12/04 21:46:28, Charlie Reis wrote: > > > These additional checks are non-obvious, so please add a comment for them. I inverted the logic here to match the similar snippet from GetRenderFrameForNavigation and added the proper comments. This made so that there's a big number of return statements. I could eliminate some if it should be OK to have if-blocks only with a DCHECK inside, is it? Let's then discuss the correct policy we should use elsewhere. > > > They're making me realize that I'm not sure what process model you're > > intending > > > for PlzNavigate. Today, Chrome is careful not to swap processes for most > > > renderer-initiated cross-site navigations (in the main frame). This is for > > > important reasons, like OAuth popups where a cross-site iframe creates a > popup > > > that needs to stay in the same process. > > > > > > It looks like this check is creating a policy halfway between default Chrome > > > behavior and --site-per-process, in a way that breaks OAuth popups. Perhaps > > we > > > should discuss (in a separate email?) what process model policy you all want > > > PlzNavigate to use, and then we can make it happen here. > > > > In that case, we need to be able to distinguish here between a > > renderer-initiated navigation and a browser-initiated one. We don't do it > right > > now, though it would be useful for other purposes (ie canceling or not an > > ongoing navigation request). Would a TODO: do not swap processes for renderer > > initiated navigations be sufficient for the time being, with the goal to > revise > > it when we have agreed on a process model to use? Interesting you mentioned that. While looking at NavigatorImpl::OnBeginNavigation I noticed there could be a problem when a renderer-initiated navigation is requested while there's already an ongoing one. It seemed it wouldn't cancel the old one and I understand you just confirmed that. > Yes, but this is an important TODO we'll need to resolve. Let's include a bug > number for it. I added the TODO and created the respective issue: crbug.com/440266 https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:666: DCHECK(new_instance->GetProcess()->GetBrowserContext()); On 2014/12/04 21:46:28, Charlie Reis wrote: > This second check seems unnecessary. Is there a way it could not have a > BrowserContext? I was going to say this was a copy/paste from another place but I can't find it anymore. So I just removed this and the next one. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:667: } else { On 2014/12/04 21:46:28, Charlie Reis wrote: > nit: Return here inside the previous block, so that the rest does not need to be > inside an else block. (Similar to UpdateStateForNavigate.) Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1409: if (!CommandLine::ForCurrentProcess()->HasSwitch( On 2014/12/04 21:46:28, Charlie Reis wrote: > Please cache this in a bool so we don't repeatedly call it below. (That will > also be easier to read.) Ha! I had just undone that. :) Re-added the boolean and added comments to make it explicit that the else-blocks are PlzNavigate-only. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1426: web_ui_.reset(speculative_web_ui_.release()); On 2014/12/04 21:46:28, Charlie Reis wrote: > Let's add a DCHECK(!speculative_web_ui_) after this block, which will verify > that it didn't exist if should_reuse_web_ui_ was true. Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1434: switches::kEnableBrowserSideNavigation)) { On 2014/12/04 21:46:28, Charlie Reis wrote: > Can we make this !pending_render_frame_host_ && !speculative_render_frame_host_ > instead? That would be easier to reason about. Makes sense. Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1590: if (CommandLine::ForCurrentProcess()->HasSwitch( On 2014/12/04 21:46:28, Charlie Reis wrote: > This doesn't feel like it fits here. Most of UpdateStateForNavigate (below this > block) ends up not being used in PlzNavigate at all. In that case, why not put > this logic in GetFrameHostForNavigation, and just copy the first few lines above > there as well? (We've already copied them into BeginNavigation.) Makes total sense and so I moved it. It might need some adjustment if we decide to move part of this to the commit-provisional-load time. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1593: (!frame_tree_node_->IsMainFrame() && On 2014/12/04 21:46:28, Charlie Reis wrote: > Same concern about the process model policy. Done: TODO + reference in crbug.com/440266 . https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1605: // TODO(carlosk): Should rename this method and the speculative members On 2014/12/04 21:46:28, Charlie Reis wrote: > I'm not concerned about the name. We're creating them and then immediately > committing them, so it's not visible outside of this block. We could > restructure so that CreateSpeculativeRenderFrameHost is a method that returns an > RFH instead of assigning it, but I'm not sure if that's worthwhile. Great! Later on I realized that as soon as we begin to monitor redirects all created RFH are speculative until the last one. And this part here in fact will cease to exist. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (left): https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:37: class RenderFrameHostManagerTest; On 2014/12/04 01:11:30, Charlie Reis wrote: > I'm not sure we want to delete this. It may not be strictly necessary, but it's > consistent with other code (e.g., see render_view_host_impl.h, render_widget.h), > and it's in the spirit of "include what you use." Let's avoid this churn unless > there's a good reason for it. Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:376: // Called when a navigation is ready to commit, to select the renderer that On 2014/12/04 01:11:32, Charlie Reis wrote: > nit: renderer -> RenderFrameHost Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:382: // Cancels any ongoing navigation. On 2014/12/04 01:11:31, Charlie Reis wrote: > nit: Cancels any state for any ongoing navigation. > > This code doesn't cancel the navigation itself. Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:483: // speculative creation of a new renderer for an ongoing navigation request. On 2014/12/04 01:11:31, Charlie Reis wrote: > creation of a new speculative RenderFrameHost for... Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:511: // RenderFrameHost to be the active one instead of the pending. On 2014/12/04 01:11:31, Charlie Reis wrote: > nit: set the speculative (not pending) RenderFrameHost to be the active one. Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:593: scoped_ptr<RenderFrameHostImpl> pending_render_frame_host_; On 2014/12/04 01:11:31, Charlie Reis wrote: > Let's add: > Note: This is not used in PlzNavigate. Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:627: base::WeakPtrFactory<RenderFrameHostManager> weak_factory_; On 2014/12/04 01:11:30, Charlie Reis wrote: > WeakPtrFactories always have to be the last member of the class. Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:631: // allowing the creation of the renderer process as early as possible. On 2014/12/04 21:46:28, Charlie Reis wrote: > This first sentence is a bit awkward. Maybe simplify to just convey the intent, > and mention it's an optimization: > > We create a speculative RenderFrameHost early during a navigation to give the > renderer process time to start. It is purely an optimization and is not > required for correct behavior. Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:635: // pending one only for the regular navigation. On 2014/12/04 01:11:32, Charlie Reis wrote: > "for the regular navigation" is a bit awkward. Maybe: > > Note: PlzNavigate only uses speculative RenderFrameHosts and not pending ones. Done. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:516: FAIL() << "Must be implemented"; Failing test that I will implement in the next PatchSet. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (left): https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:629: // enabled. I removed this TODO in favor of the new ones I'm adding related to the newly created bug. But from the CR comments I had understood this policy applied for any kind of renderer-initiated navigations, and not only for subframe. Is that so? https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:671: return; These are the returns I'd like to eliminate but I'd have to use if-blocks to hold DCHECKs.
Thanks! I think it is preferable we postpone moving the RFH swapping in cross-site navigation until after we have simplified the renderer load logic. In the meantime, we should end up with a speculative RFH following RFHM::GetFrameHostForNavigation in cross-site navigations, and commit that one in RFHM::DidNavigateFrame, in lieu of the pending RFH. https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... File content/browser/frame_host/render_frame_host_manager.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:433: return; On 2014/12/09 07:55:42, carlosk wrote: > On 2014/12/05 19:06:23, Charlie Reis wrote: > > On 2014/12/05 17:16:19, clamy wrote: > > > On 2014/12/04 21:46:28, Charlie Reis wrote: > > > > I'm not sure this is correct. > > > > > > > > What happens if a DidNavigate from the previous RFH arrives just after > we've > > > > decided to commit in the new one? We'll return without doing anything > here, > > > but > > > > the NavigationController will probably update the last committed entry to > > the > > > > URL from the previous RFH. We'll end up with a mismatch between the > address > > > bar > > > > and the actual page contents until the new RFH commits. > > > > > > > > Not sure what the right behavior in that case is. If we know we've > already > > > left > > > > the previous RFH, maybe we should ignore the commit? I'm concerned what > > > impact > > > > that has in the previous renderer process, but maybe it's ok. > > > > > > > > (Also see this CL, which is changing the logic below: > > > > https://codereview.chromium.org/746993003/) > > > > > > If we go along with committing the NavigationEntry at the same time as we > swap > > > renderers, then the only issue would be with same-document navigations > (since > > > all other renderer initiated navigations should go to the browser). In that > > > case, would the behavior ignore this same-document navigation because it > > arrived > > > after the commit of another pending navigation be ok? This implies not > > > committing an entry for the same-document navigation in that case as well. > > > > I'm nervous about this as well: ignoring a commit usually leads to URL spoofs. > > > Also, the renderer process keeps track of the offset and length of history, > > which would be wrong in this case. (Today it also keeps track of page IDs for > > the whole history, but Avi's removing that.) > > I'm having trouble following your lines of thought here because I don't know > about the cases you are referring to here. > > But it seems to me that these issues might also be resolved by moving the RFH > swapping to this place as I mentioned in a previous comment. Indeed, it seems we are in agreement that the speculative RFH should be committed here. https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:577: scoped_ptr<RenderFrameHostImpl> render_frame_host) { On 2014/12/09 07:55:42, carlosk wrote: > On 2014/12/05 17:16:19, clamy wrote: > > On 2014/12/04 21:46:28, Charlie Reis wrote: > > > On 2014/12/03 17:24:48, clamy wrote: > > > > On 2014/12/03 16:25:25, carlosk wrote: > > > > > Continuing the discussion that was started in crrev.com/753173002 > > regarding > > > > > calling RFHM::DiscardUnusedFrame for the speculative case: > > > > > > > > > > On 2014/12/01 20:12:46, Charlie Reis wrote: > > > > > > On 2014/11/27 11:02:43, carlosk wrote: > > > > > > > On 2014/11/26 01:06:40, Charlie Reis (OOO until Dec 1) wrote: > > > > > > > > This makes sense when called by CancelPending. > > > > > > > > > > > > > > > > Are you planning to use this method for speculative RFHs as well? > > In > > > > that > > > > > > > case > > > > > > > > I don't think we'll need to call SwapOut. Either it was already > > > swapped > > > > > out > > > > > > > > (and we didn't swap it in) or we created it from scratch and we > can > > > > delete > > > > > > it. > > > > > > > > > > > > > > > (That can be a topic for the next CL, though.) > > > > > > > > > > > > > > Yes, it should be a topic for the other CL. > > > > > > > > > > > > Sounds good. > > > > > > > > > > > > > > > > > > > > But at this point if the RFH was previously swapped out it did > already > > > > went > > > > > > > through the process of being swapped-in (at least I think that's > what > > > > > happens > > > > > > in > > > > > > > RFHM::CreateRenderFrame in the if-block beginning with: > > > > > > > > > > > > > > if (proxy && proxy->render_frame_host()) { > > > > > > > > > > > > > > Isn't that so? > > > > > > > > > > > > No, that block just deletes the proxy. We don't actually change the > > state > > > > > away > > > > > > from STATE_SWAPPED_OUT until we get to the RFHI::Navigate call. > > > > > > > > > > > > > > > > > > > > Also at this point we have no idea if the RFH was newly created or > > not. > > > > > > > > > > > > > > > > I had a second look at this and now I understand the importance of not > > > calling > > > > > SwapOut on a RFH that is already in that state. > > > > > > > > > > Even so it seems like the current implementation (with the fix below) is > > > > correct > > > > > as it will properly handle both situations: > > > > > * When the RFH was gotten from the swapped out map, it will recreate the > > > > > previously deleted proxy and re-add it to the map. > > > > > * When a newly created is used it's simply deleted. > > > > > > > > > > Maybe the checks for this are a little convoluted for PlzNavigate > > > > (SiteInstance > > > > > active frame count instead of is_swapped_out()) but that makes it work > > both > > > in > > > > > this case and for the current navigation. > > > > > > Sounds good. > > > > > > > Speaking of swapped out state, does the CommitPending method set the state > > of > > > > the RFH we swap in to DEFAULT? Otherwise since PlzNavigate does not call > > > > RFHI::Navigate, we may swap back in a RFH in state swapped out. If that's > > the > > > > case, we should have go back to default state before swapping it in. > > > > > > Good question. CommitPending does not, so we'll need to find the right > place > > to > > > do it. > > > > One option could be to have RFH::CommitNavigation call it, in the same way > > RFH::Navigate currently reset the state of the RFH before navigating. Granted, > > this happens just after the RFH has been swapped in in the PlzNavigate case. > > It seems we need a test for a speculative RFH that is swapped back in... I'll > work on that next so for now I just added a failing test. > > Now for the actual moment where the RFH should be set to STATE_DEFAULT I am a > tad lost. Should it be done immediately at the moment it's taken out of the > swapped-out map? It seems that was how it works for the current navigation given > how the "RFH recycling" works. > > Or maybe it should happen only later when the RFH is actually made active? If we go with swapping the speculative RFH in after the DidCommitProvisionalLoad IPC was received, then we should reset its state to default in RenderFrameHostImpl::CommitNavigation (as it is currently done in RenderFrameHostImpl::Navigate for a pending RFH in cross-site navigations). https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:644: // If there is an ongoing navigation, cancel it. On 2014/12/09 07:55:42, carlosk wrote: > On 2014/12/05 17:16:19, clamy wrote: > > On 2014/12/04 21:46:28, Charlie Reis wrote: > > > cancel it -> cancel any state we have for it. > > > > > > (RFHM is just a state machine for the process logic, so it doesn't handle > > > canceling the navigation itself. Do you need the actual navigation to be > > > canceled as well?) > > > > NavigatorImpl is normally responsible for canceling the actual navigation. > This > > should be a state clean up. > > Updated the comment. > > This was more of a just-in-case action: whenever a new navigation begins any > previous state is cleaned up. It doesn't seem that there's a guarantee that the > cleanup happens otherwise. The way the code is written, there would not have been a clean-up in the case where a new navigation cancels an ongoing one. I think we should have the CleanUpNavigation method be called by the destructor of the NavigationRequest, instead of in separate places in the code. That way, whenever a navigation is canceled, we are sure the associated state in RFHM is cleaned up as well. In that case, you could replace this call by a DCHECK(!speculative_render_frame_host_.get()). https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:654: (frame_tree_node_->IsMainFrame() || On 2014/12/09 07:55:42, carlosk wrote: > On 2014/12/05 19:06:23, Charlie Reis wrote: > > On 2014/12/05 17:16:19, clamy wrote: > > > On 2014/12/04 21:46:28, Charlie Reis wrote: > > > > These additional checks are non-obvious, so please add a comment for them. > > I inverted the logic here to match the similar snippet from > GetRenderFrameForNavigation and added the proper comments. This made so that > there's a big number of return statements. I could eliminate some if it should > be OK to have if-blocks only with a DCHECK inside, is it? I think it is fine to have an if-block with just a DCHECK inside. Example in RFHM (with a CHECK): https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/fr... Generally the goal is to have simpler logical conditions and less indentation. > > Let's then discuss the correct policy we should use elsewhere. > > > > > They're making me realize that I'm not sure what process model you're > > > intending > > > > for PlzNavigate. Today, Chrome is careful not to swap processes for most > > > > renderer-initiated cross-site navigations (in the main frame). This is > for > > > > important reasons, like OAuth popups where a cross-site iframe creates a > > popup > > > > that needs to stay in the same process. > > > > > > > > It looks like this check is creating a policy halfway between default > Chrome > > > > behavior and --site-per-process, in a way that breaks OAuth popups. > Perhaps > > > we > > > > should discuss (in a separate email?) what process model policy you all > want > > > > PlzNavigate to use, and then we can make it happen here. > > > > > > In that case, we need to be able to distinguish here between a > > > renderer-initiated navigation and a browser-initiated one. We don't do it > > right > > > now, though it would be useful for other purposes (ie canceling or not an > > > ongoing navigation request). Would a TODO: do not swap processes for > renderer > > > initiated navigations be sufficient for the time being, with the goal to > > revise > > > it when we have agreed on a process model to use? > > Interesting you mentioned that. While looking at > NavigatorImpl::OnBeginNavigation I noticed there could be a problem when a > renderer-initiated navigation is requested while there's already an ongoing one. > It seemed it wouldn't cancel the old one and I understand you just confirmed > that. Actually it is not canceled. Instead we attempt to call NavigationRequest::BeginNavigation again on the existing one. This fails because of a DCHECK(!_loader.get()). I am currently working on fixing that behavior (and have the current request be canceled by the render-initiated one if it was user-initiated as well). > > > Yes, but this is an important TODO we'll need to resolve. Let's include a bug > > number for it. > > I added the TODO and created the respective issue: crbug.com/440266 https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... File content/browser/frame_host/navigator_impl.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/navigator_impl.cc:757: // First starts the IO/net requests. nit: I would rephrase as "First start the request on the IO thread. https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/navigator_impl.cc:759: // Then notify the manager so it can speculatively create a renderer in Please add a line before the comment. nit: s/manager/RenderFrameHostManager https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:99: RenderFrameHostManager* root_rfhm = root->render_manager(); nit: Please add an empty line here. https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:128: // Subframe navigations should not create a speculative RenderFrameHost. nit: Please add an empty line before this comment. https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:145: // Main frame navigations to different sites should use a speculative nit: Please add an empty line before this comment. https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:163: // As we're re-using the current RenderFrameHost, no speculative one should be nit: Please add an empty line before this comment. https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:200: // Navigations to a different site do create a speculative RenderFrameHost. nit: Please add an empty line before this comment. https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:512: // PlzNavigate: Verify a previously swapped-out RenderFrameHost is correctly s/Verify/Verify that I would also rephrase as "is correctly used when spawning a speculative RenderFrameHost in a navigation using the same SiteInstance". https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:516: FAIL() << "Must be implemented"; On 2014/12/09 07:55:43, carlosk wrote: > Failing test that I will implement in the next PatchSet. Acknowledged. https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... File content/browser/frame_host/render_frame_host_manager.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:448: if (render_frame_host == pending_render_frame_host_) { We probably want to something a bit similar, only with the speculative RFH instead of the pending one. I am not sure we can quite reuse that one, due to slight differences in the case of same-site navigations (see below). https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:452: } else if (render_frame_host == render_frame_host_) { Note that in the PlzNavigate case, we only want to cancel the current navigation (and speculative RFH) if we receive a commit message from an in-page user-initiated navigation. In-page non user-initiated navigations should not cancel any pending navigations, and in all other cases the pending navigation should be the one that commits, and there should be no speculative RFH. Also, CancelPending destroys the pending RFH, which indeed cancels an on-going cross-site navigation. In PlzNavigate it does not work that way, so we need to make sure that navigations are properly cancelled following the commit of in-page user-initiated navigations. I think this can be left as a TODO for a future patch though. https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:671: return; On 2014/12/09 07:55:43, carlosk wrote: > These are the returns I'd like to eliminate but I'd have to use if-blocks to > hold DCHECKs. While it is fine in general to have an if-block with only a DCHECK inside, I don't think it would be better in that case. IMO the early return makes it clearer that something went wrong if InitRenderView did not succeed, compared to writing: if (InitRenderView(...)) DCHECK(current_instance->GetProcess()->HasConnection()) return; https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:677: // Speculatively create a new RFH. Please add a line before that comment and remove the one below. https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:724: RenderFrameHostImpl* RenderFrameHostManager::GetFrameHostForNavigation( Please modify this function so that it does not commit the pending RFH. Instead it should either return the current renderer, or the speculative RFH. If it turns out we need a speculative RFH and we don't have one, or the one we have is wrong, a new speculative RFh should be created and returned.
Thanks for all the updates. Sounds like we're mainly waiting on the change to commit time, but here's a few replies along the way. https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:230: ASSERT_TRUE(main_request); On 2014/12/09 07:55:41, carlosk wrote: > On 2014/12/04 01:11:30, Charlie Reis wrote: > > Can we verify that there's no pending RFH here? And do we expect there to be > a > > speculative RFH at this point? (My guess is yes.) > > Note: Initially I just added a couple tests and expanded a few of the existing > to include speculative renderer checks. Going over your comments it seemed like > doing that for all tests was the right thing to do. Well, it's done now. > > It seems weird to add checks for the pending RFH as all of them will be > EXPECT_FALSE as it should not be used anymore when PlzNavigate is enabled. Also > these checks would have to be removed once we enable PlzNavigate for good. But I > agree it's also weird that there are currently some checks for that throughout > this unittest file. > > WDYT? Should I add these checks everywhere or remove them entirely? I'd be happy with having speculative RFH checks in all the PlzNavigate tests and only checking that the pending RFH isn't used in one of the tests. https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:233: GetLoaderForNavigationRequest(main_request)->CallOnResponseStarted( On 2014/12/09 07:55:41, carlosk wrote: > On 2014/12/05 19:06:23, Charlie Reis wrote: > > On 2014/12/05 17:16:19, clamy wrote: > > > On 2014/12/04 01:11:30, Charlie Reis wrote: > > > > I'm a bit confused by what this means. Before, it created a pending RFH > but > > > > hadn't committed it. Now, the new RFH has already committed. > > > > > > > > Where are we in the navigation timeline? Has the new NavigationEntry > > > committed? > > > > Maybe it would help to add that stage to the test if not. > > > > > > The new RFH is only committed after this call (this simulates the IO thread > > > signaling us that a navigation is ready to be committed). > > > > Oh, I get it. CallOnResponseStarted used to create the pending RFH and it > > wasn't committed until DidCommitProvisionalLoad. As a result of this CL, we > > commit the speculative RFH at this time. > > > > > The navigation entry > > > is still committed after receiving the DidCommitProvisionalLoad IPC. This > may > > be > > > a problem, and I think we should move the commit of the NavigationEntry at > the > > > same time as the RFH swap in (ie in response to > > > NavigatorImpl::CommitNavigation). > > > > This makes me very nervous. I agree that it's not great to commit the RFH > > earlier than the NavigationEntry, but it's also very bad to say that a > > NavigationEntry has committed when it hasn't. There's huge potential for URL > > spoofs in that case. > > > > The problem is that it's still too hard to guarantee that we'll see the commit > > we're expecting. Even if we ignore the fact that the renderer process might > > crash or be slow, there's just a whole lot of content+Blink code between > > OnCommitNavigation and DidCommitProvisionalLoad in the renderer. Without > > auditing that, I don't know if we have a 100% guarantee we'll get a commit of > > the URL we were expecting, or if something might alter it. > > > > Maybe it's worth auditing that code to see if we can get a guarantee? > > I can do the audit but I'd need more details on what I should be looking for. If > I understood what you said it seems the main thing would be to verify that > there's no way the navigation could be cancelled in between the RFH being made > active and the call to DidNavigate, right? And what else? Canceled or otherwise altered (e.g., committing a different URL than expected, or other changes to the DidCommit parameters). > Another option would be to simply move the RFH swapping back to > did-commit-provisional-load time if that makes more sense and keeps the RFH in > sync with the other involved components. Yes, I'm in favor of not making the change to commit time in this CL. https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:273: EXPECT_FALSE(GetSpeculativeRenderFrameHost(rfhm)); On 2014/12/09 07:55:41, carlosk wrote: > On 2014/12/04 01:11:30, Charlie Reis wrote: > > Why is there no speculative RFH after it redirects cross site? Is that > planned > > for later? (Seems like we might as well create one while we're waiting for > the > > new response.) > > > > If we're not planning to create one in this CL, then a TODO here might be > > worthwhile. > > Indeed that is a task for later on. The idea is to monitor redirects --- that > now are conveniently tracked at the browser side -- to update the speculative > RFH accordingly. But we have to be careful with this as we'll possibly be > creating quite some churn by creating and destroying RFH in bursts. Later is fine. Worth noting that we wouldn't get a "burst" for multiple redirects, at least. We'll get at most two speculative RFHs per navigation (once when it starts, and once after all the server redirects are done). > > Also this made me think that the question regarding the name choice of > "speculative" might be the right one (see respective comment in RFHM) as when we > actually implement this that all we will have are speculative RFH until the last > redirect. https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... File content/browser/frame_host/render_frame_host_manager.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/370001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:577: scoped_ptr<RenderFrameHostImpl> render_frame_host) { On 2014/12/09 15:09:51, clamy wrote: > On 2014/12/09 07:55:42, carlosk wrote: > > On 2014/12/05 17:16:19, clamy wrote: > > > On 2014/12/04 21:46:28, Charlie Reis wrote: > > > > On 2014/12/03 17:24:48, clamy wrote: > > > > > On 2014/12/03 16:25:25, carlosk wrote: > > > > > > Continuing the discussion that was started in crrev.com/753173002 > > > regarding > > > > > > calling RFHM::DiscardUnusedFrame for the speculative case: > > > > > > > > > > > > On 2014/12/01 20:12:46, Charlie Reis wrote: > > > > > > > On 2014/11/27 11:02:43, carlosk wrote: > > > > > > > > On 2014/11/26 01:06:40, Charlie Reis (OOO until Dec 1) wrote: > > > > > > > > > This makes sense when called by CancelPending. > > > > > > > > > > > > > > > > > > Are you planning to use this method for speculative RFHs as > well? > > > In > > > > > that > > > > > > > > case > > > > > > > > > I don't think we'll need to call SwapOut. Either it was already > > > > swapped > > > > > > out > > > > > > > > > (and we didn't swap it in) or we created it from scratch and we > > can > > > > > delete > > > > > > > it. > > > > > > > > > > > > > > > > > (That can be a topic for the next CL, though.) > > > > > > > > > > > > > > > > Yes, it should be a topic for the other CL. > > > > > > > > > > > > > > Sounds good. > > > > > > > > > > > > > > > > > > > > > > > But at this point if the RFH was previously swapped out it did > > already > > > > > went > > > > > > > > through the process of being swapped-in (at least I think that's > > what > > > > > > happens > > > > > > > in > > > > > > > > RFHM::CreateRenderFrame in the if-block beginning with: > > > > > > > > > > > > > > > > if (proxy && proxy->render_frame_host()) { > > > > > > > > > > > > > > > > Isn't that so? > > > > > > > > > > > > > > No, that block just deletes the proxy. We don't actually change the > > > state > > > > > > away > > > > > > > from STATE_SWAPPED_OUT until we get to the RFHI::Navigate call. > > > > > > > > > > > > > > > > > > > > > > > Also at this point we have no idea if the RFH was newly created or > > > not. > > > > > > > > > > > > > > > > > > > I had a second look at this and now I understand the importance of not > > > > calling > > > > > > SwapOut on a RFH that is already in that state. > > > > > > > > > > > > Even so it seems like the current implementation (with the fix below) > is > > > > > correct > > > > > > as it will properly handle both situations: > > > > > > * When the RFH was gotten from the swapped out map, it will recreate > the > > > > > > previously deleted proxy and re-add it to the map. > > > > > > * When a newly created is used it's simply deleted. > > > > > > > > > > > > Maybe the checks for this are a little convoluted for PlzNavigate > > > > > (SiteInstance > > > > > > active frame count instead of is_swapped_out()) but that makes it work > > > both > > > > in > > > > > > this case and for the current navigation. > > > > > > > > Sounds good. > > > > > > > > > Speaking of swapped out state, does the CommitPending method set the > state > > > of > > > > > the RFH we swap in to DEFAULT? Otherwise since PlzNavigate does not call > > > > > RFHI::Navigate, we may swap back in a RFH in state swapped out. If > that's > > > the > > > > > case, we should have go back to default state before swapping it in. > > > > > > > > Good question. CommitPending does not, so we'll need to find the right > > place > > > to > > > > do it. > > > > > > One option could be to have RFH::CommitNavigation call it, in the same way > > > RFH::Navigate currently reset the state of the RFH before navigating. > Granted, > > > this happens just after the RFH has been swapped in in the PlzNavigate case. > > > > It seems we need a test for a speculative RFH that is swapped back in... I'll > > work on that next so for now I just added a failing test. > > > > Now for the actual moment where the RFH should be set to STATE_DEFAULT I am a > > tad lost. Should it be done immediately at the moment it's taken out of the > > swapped-out map? It seems that was how it works for the current navigation > given > > how the "RFH recycling" works. > > > > Or maybe it should happen only later when the RFH is actually made active? > > If we go with swapping the speculative RFH in after the DidCommitProvisionalLoad > IPC was received, then we should reset its state to default in > RenderFrameHostImpl::CommitNavigation (as it is currently done in > RenderFrameHostImpl::Navigate for a pending RFH in cross-site navigations). That sounds right. The only reason we swapped it back in during Navigate was so that the renderer could send navigation-related IPCs (which is no longer necessary with PlzNavigate). https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:129: // (unless site-per-process is enabled) nit: Period goes after the the close paren, not after RenderFrameHost. Can we find a way to make this pass with the --site-per-process flag? Otherwise our Site Isolation FYI bots will go red. https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:440: // Commit the navigation with Navigator by simulating the call to How about: "Ask Navigator to commit the navigation by simulating..." https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:498: EXPECT_EQ(site_instance_id, Please add a TODO, given that the behavior (stale RFH) doesn't seem to match the test description or desired behavior (discard on redirect). https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... File content/browser/frame_host/render_frame_host_manager.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:671: return; On 2014/12/09 15:09:52, clamy wrote: > On 2014/12/09 07:55:43, carlosk wrote: > > These are the returns I'd like to eliminate but I'd have to use if-blocks to > > hold DCHECKs. > > While it is fine in general to have an if-block with only a DCHECK inside, I > don't think it would be better in that case. IMO the early return makes it > clearer that something went wrong if InitRenderView did not succeed, compared to > writing: > if (InitRenderView(...)) > DCHECK(current_instance->GetProcess()->HasConnection()) > return; +1 to both. (DCHECKs inside a conditional mostly make sense if the conditional can be optimized out.)
Few comments as I try to swap back in memory the CL. Thanks for slimming it down! It is much easier to look at smaller number of changes. https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... File content/browser/frame_host/render_frame_host_manager.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:762: CommitPending(); Why is this method calling CommitPending? https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... File content/browser/frame_host/render_frame_host_manager.h (right): https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/render_frame_host_manager.h:373: // Notifies the RFHM that a navigation is about to begin so that it can nit: s/about to begin/has begun/ since we issue the network request before calling into RFHM. https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/render_frame_host_manager.h:374: // speculatively spawn a new renderer process if needed. nit: s/spawn/create/ https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/render_frame_host_manager.h:379: // Called when a navigation is ready to commit, to select the RenderFrameHost nit: no need for comma https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/render_frame_host_manager.h:486: // speculative creation of a new speculative RenderFrameHost for an ongoing nit: It will be nice to avoid using "speculative" twice in the same sentence, makes it hard to read.
nick@chromium.org changed reviewers: + nick@chromium.org
https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:75: CleanUpNavigation(); A CL I'm working on -- https://codereview.chromium.org/799593004/ -- will fix a bug in ~RenderFrameHostManager that's due to the save-for-reuse work of DiscardUnusedFrame being problematic during destruction. Since CleanUpNavigation() also calls DiscardUnusedFrame, I think this will introduce a new instance of that bug. See if you can use the test I added in the CL as a starting point for tickling the CleanUpNavigation() instance?
Thanks to all! I hope I replied to all comments but let me know if I missed any. Somewhat significant changes this time. Main points: * Following @ncarter comment I implemented a copycat fix from his from crrev.com/799593004 * The switching of the active RFH was pushed back again to commit-provisional-load time (this caused quite some changes in existing tests) * The swap-back-in-a-RFH test is implemented https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:230: ASSERT_TRUE(main_request); On 2014/12/10 22:37:44, Charlie Reis wrote: > On 2014/12/09 07:55:41, carlosk wrote: > > On 2014/12/04 01:11:30, Charlie Reis wrote: > > > Can we verify that there's no pending RFH here? And do we expect there to > be > > a > > > speculative RFH at this point? (My guess is yes.) > > > > Note: Initially I just added a couple tests and expanded a few of the existing > > to include speculative renderer checks. Going over your comments it seemed > like > > doing that for all tests was the right thing to do. Well, it's done now. > > > > It seems weird to add checks for the pending RFH as all of them will be > > EXPECT_FALSE as it should not be used anymore when PlzNavigate is enabled. > Also > > these checks would have to be removed once we enable PlzNavigate for good. But > I > > agree it's also weird that there are currently some checks for that throughout > > this unittest file. > > > > WDYT? Should I add these checks everywhere or remove them entirely? > > I'd be happy with having speculative RFH checks in all the PlzNavigate tests and > only checking that the pending RFH isn't used in one of the tests. Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:233: GetLoaderForNavigationRequest(main_request)->CallOnResponseStarted( On 2014/12/10 22:37:44, Charlie Reis wrote: > On 2014/12/09 07:55:41, carlosk wrote: > > On 2014/12/05 19:06:23, Charlie Reis wrote: > > > On 2014/12/05 17:16:19, clamy wrote: > > > > On 2014/12/04 01:11:30, Charlie Reis wrote: > > > > > I'm a bit confused by what this means. Before, it created a pending RFH > > but > > > > > hadn't committed it. Now, the new RFH has already committed. > > > > > > > > > > Where are we in the navigation timeline? Has the new NavigationEntry > > > > committed? > > > > > Maybe it would help to add that stage to the test if not. > > > > > > > > The new RFH is only committed after this call (this simulates the IO > thread > > > > signaling us that a navigation is ready to be committed). > > > > > > Oh, I get it. CallOnResponseStarted used to create the pending RFH and it > > > wasn't committed until DidCommitProvisionalLoad. As a result of this CL, we > > > commit the speculative RFH at this time. > > > > > > > The navigation entry > > > > is still committed after receiving the DidCommitProvisionalLoad IPC. This > > may > > > be > > > > a problem, and I think we should move the commit of the NavigationEntry at > > the > > > > same time as the RFH swap in (ie in response to > > > > NavigatorImpl::CommitNavigation). > > > > > > This makes me very nervous. I agree that it's not great to commit the RFH > > > earlier than the NavigationEntry, but it's also very bad to say that a > > > NavigationEntry has committed when it hasn't. There's huge potential for > URL > > > spoofs in that case. > > > > > > The problem is that it's still too hard to guarantee that we'll see the > commit > > > we're expecting. Even if we ignore the fact that the renderer process might > > > crash or be slow, there's just a whole lot of content+Blink code between > > > OnCommitNavigation and DidCommitProvisionalLoad in the renderer. Without > > > auditing that, I don't know if we have a 100% guarantee we'll get a commit > of > > > the URL we were expecting, or if something might alter it. > > > > > > Maybe it's worth auditing that code to see if we can get a guarantee? > > > > I can do the audit but I'd need more details on what I should be looking for. > If > > I understood what you said it seems the main thing would be to verify that > > there's no way the navigation could be cancelled in between the RFH being made > > active and the call to DidNavigate, right? And what else? > > Canceled or otherwise altered (e.g., committing a different URL than expected, > or other changes to the DidCommit parameters). Ack. As discussed let's leave that for when we remove regular navigation code and have a clear code path. > > Another option would be to simply move the RFH swapping back to > > did-commit-provisional-load time if that makes more sense and keeps the RFH in > > sync with the other involved components. > > Yes, I'm in favor of not making the change to commit time in this CL. Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:273: EXPECT_FALSE(GetSpeculativeRenderFrameHost(rfhm)); On 2014/12/10 22:37:44, Charlie Reis wrote: > On 2014/12/09 07:55:41, carlosk wrote: > > On 2014/12/04 01:11:30, Charlie Reis wrote: > > > Why is there no speculative RFH after it redirects cross site? Is that > > planned > > > for later? (Seems like we might as well create one while we're waiting for > > the > > > new response.) > > > > > > If we're not planning to create one in this CL, then a TODO here might be > > > worthwhile. > > > > Indeed that is a task for later on. The idea is to monitor redirects --- that > > now are conveniently tracked at the browser side -- to update the speculative > > RFH accordingly. But we have to be careful with this as we'll possibly be > > creating quite some churn by creating and destroying RFH in bursts. > > Later is fine. Worth noting that we wouldn't get a "burst" for multiple > redirects, at least. We'll get at most two speculative RFHs per navigation > (once when it starts, and once after all the server redirects are done). So if I understand correctly when server redirects happen we only get the final result? I guess we could still get some more when jumping from one server to the next? > > Also this made me think that the question regarding the name choice of > > "speculative" might be the right one (see respective comment in RFHM) as when > we > > actually implement this that all we will have are speculative RFH until the > last > > redirect. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:433: return; On 2014/12/09 15:09:51, clamy wrote: > On 2014/12/09 07:55:42, carlosk wrote: > > On 2014/12/05 19:06:23, Charlie Reis wrote: > > > On 2014/12/05 17:16:19, clamy wrote: > > > > On 2014/12/04 21:46:28, Charlie Reis wrote: > > > > > I'm not sure this is correct. > > > > > > > > > > What happens if a DidNavigate from the previous RFH arrives just after > > we've > > > > > decided to commit in the new one? We'll return without doing anything > > here, > > > > but > > > > > the NavigationController will probably update the last committed entry > to > > > the > > > > > URL from the previous RFH. We'll end up with a mismatch between the > > address > > > > bar > > > > > and the actual page contents until the new RFH commits. > > > > > > > > > > Not sure what the right behavior in that case is. If we know we've > > already > > > > left > > > > > the previous RFH, maybe we should ignore the commit? I'm concerned what > > > > impact > > > > > that has in the previous renderer process, but maybe it's ok. > > > > > > > > > > (Also see this CL, which is changing the logic below: > > > > > https://codereview.chromium.org/746993003/) > > > > > > > > If we go along with committing the NavigationEntry at the same time as we > > swap > > > > renderers, then the only issue would be with same-document navigations > > (since > > > > all other renderer initiated navigations should go to the browser). In > that > > > > case, would the behavior ignore this same-document navigation because it > > > arrived > > > > after the commit of another pending navigation be ok? This implies not > > > > committing an entry for the same-document navigation in that case as well. > > > > > > I'm nervous about this as well: ignoring a commit usually leads to URL > spoofs. > > > > > Also, the renderer process keeps track of the offset and length of history, > > > which would be wrong in this case. (Today it also keeps track of page IDs > for > > > the whole history, but Avi's removing that.) > > > > I'm having trouble following your lines of thought here because I don't know > > about the cases you are referring to here. > > > > But it seems to me that these issues might also be resolved by moving the RFH > > swapping to this place as I mentioned in a previous comment. > > Indeed, it seems we are in agreement that the speculative RFH should be > committed here. Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:577: scoped_ptr<RenderFrameHostImpl> render_frame_host) { On 2014/12/10 22:37:44, Charlie Reis wrote: > On 2014/12/09 15:09:51, clamy wrote: > > On 2014/12/09 07:55:42, carlosk wrote: > > > On 2014/12/05 17:16:19, clamy wrote: > > > > On 2014/12/04 21:46:28, Charlie Reis wrote: > > > > > On 2014/12/03 17:24:48, clamy wrote: > > > > > > On 2014/12/03 16:25:25, carlosk wrote: > > > > > > > Continuing the discussion that was started in crrev.com/753173002 > > > > regarding > > > > > > > calling RFHM::DiscardUnusedFrame for the speculative case: > > > > > > > > > > > > > > On 2014/12/01 20:12:46, Charlie Reis wrote: > > > > > > > > On 2014/11/27 11:02:43, carlosk wrote: > > > > > > > > > On 2014/11/26 01:06:40, Charlie Reis (OOO until Dec 1) wrote: > > > > > > > > > > This makes sense when called by CancelPending. > > > > > > > > > > > > > > > > > > > > Are you planning to use this method for speculative RFHs as > > well? > > > > In > > > > > > that > > > > > > > > > case > > > > > > > > > > I don't think we'll need to call SwapOut. Either it was > already > > > > > swapped > > > > > > > out > > > > > > > > > > (and we didn't swap it in) or we created it from scratch and > we > > > can > > > > > > delete > > > > > > > > it. > > > > > > > > > > > > > > > > > > > (That can be a topic for the next CL, though.) > > > > > > > > > > > > > > > > > > Yes, it should be a topic for the other CL. > > > > > > > > > > > > > > > > Sounds good. > > > > > > > > > > > > > > > > > > > > > > > > > > But at this point if the RFH was previously swapped out it did > > > already > > > > > > went > > > > > > > > > through the process of being swapped-in (at least I think that's > > > what > > > > > > > happens > > > > > > > > in > > > > > > > > > RFHM::CreateRenderFrame in the if-block beginning with: > > > > > > > > > > > > > > > > > > if (proxy && proxy->render_frame_host()) { > > > > > > > > > > > > > > > > > > Isn't that so? > > > > > > > > > > > > > > > > No, that block just deletes the proxy. We don't actually change > the > > > > state > > > > > > > away > > > > > > > > from STATE_SWAPPED_OUT until we get to the RFHI::Navigate call. > > > > > > > > > > > > > > > > > > > > > > > > > > Also at this point we have no idea if the RFH was newly created > or > > > > not. > > > > > > > > > > > > > > > > > > > > > > I had a second look at this and now I understand the importance of > not > > > > > calling > > > > > > > SwapOut on a RFH that is already in that state. > > > > > > > > > > > > > > Even so it seems like the current implementation (with the fix > below) > > is > > > > > > correct > > > > > > > as it will properly handle both situations: > > > > > > > * When the RFH was gotten from the swapped out map, it will recreate > > the > > > > > > > previously deleted proxy and re-add it to the map. > > > > > > > * When a newly created is used it's simply deleted. > > > > > > > > > > > > > > Maybe the checks for this are a little convoluted for PlzNavigate > > > > > > (SiteInstance > > > > > > > active frame count instead of is_swapped_out()) but that makes it > work > > > > both > > > > > in > > > > > > > this case and for the current navigation. > > > > > > > > > > Sounds good. > > > > > > > > > > > Speaking of swapped out state, does the CommitPending method set the > > state > > > > of > > > > > > the RFH we swap in to DEFAULT? Otherwise since PlzNavigate does not > call > > > > > > RFHI::Navigate, we may swap back in a RFH in state swapped out. If > > that's > > > > the > > > > > > case, we should have go back to default state before swapping it in. > > > > > > > > > > Good question. CommitPending does not, so we'll need to find the right > > > place > > > > to > > > > > do it. > > > > > > > > One option could be to have RFH::CommitNavigation call it, in the same way > > > > RFH::Navigate currently reset the state of the RFH before navigating. > > Granted, > > > > this happens just after the RFH has been swapped in in the PlzNavigate > case. > > > > > > It seems we need a test for a speculative RFH that is swapped back in... > I'll > > > work on that next so for now I just added a failing test. > > > > > > Now for the actual moment where the RFH should be set to STATE_DEFAULT I am > a > > > tad lost. Should it be done immediately at the moment it's taken out of the > > > swapped-out map? It seems that was how it works for the current navigation > > given > > > how the "RFH recycling" works. > > > > > > Or maybe it should happen only later when the RFH is actually made active? > > > > If we go with swapping the speculative RFH in after the > DidCommitProvisionalLoad > > IPC was received, then we should reset its state to default in > > RenderFrameHostImpl::CommitNavigation (as it is currently done in > > RenderFrameHostImpl::Navigate for a pending RFH in cross-site navigations). > > That sounds right. The only reason we swapped it back in during Navigate was so > that the renderer could send navigation-related IPCs (which is no longer > necessary with PlzNavigate). Done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:644: // If there is an ongoing navigation, cancel it. On 2014/12/09 15:09:52, clamy wrote: > On 2014/12/09 07:55:42, carlosk wrote: > > On 2014/12/05 17:16:19, clamy wrote: > > > On 2014/12/04 21:46:28, Charlie Reis wrote: > > > > cancel it -> cancel any state we have for it. > > > > > > > > (RFHM is just a state machine for the process logic, so it doesn't handle > > > > canceling the navigation itself. Do you need the actual navigation to be > > > > canceled as well?) > > > > > > NavigatorImpl is normally responsible for canceling the actual navigation. > > This > > > should be a state clean up. > > > > Updated the comment. > > > > This was more of a just-in-case action: whenever a new navigation begins any > > previous state is cleaned up. It doesn't seem that there's a guarantee that > the > > cleanup happens otherwise. > > The way the code is written, there would not have been a clean-up in the case > where a new navigation cancels an ongoing one. > > I think we should have the CleanUpNavigation method be called by the destructor > of the NavigationRequest, instead of in separate places in the code. That way, > whenever a navigation is canceled, we are sure the associated state in RFHM is > cleaned up as well. > > In that case, you could replace this call by a > DCHECK(!speculative_render_frame_host_.get()). It is already being called in NavigatorImpl::CancelNavigation, which is the method that erases NavigationRequest instances from the request map. But right now either of these options work right but crash or behave weirdly. So I'll leave this as is for now and then get back to this issue once we sort out how and when to cancel ongoing navigations upon receiving a new request. Added a TODO for that. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:654: (frame_tree_node_->IsMainFrame() || On 2014/12/09 15:09:51, clamy wrote: > On 2014/12/09 07:55:42, carlosk wrote: > > On 2014/12/05 19:06:23, Charlie Reis wrote: > > > On 2014/12/05 17:16:19, clamy wrote: > > > > On 2014/12/04 21:46:28, Charlie Reis wrote: > > > > > These additional checks are non-obvious, so please add a comment for > them. > > > > I inverted the logic here to match the similar snippet from > > GetRenderFrameForNavigation and added the proper comments. This made so that > > there's a big number of return statements. I could eliminate some if it should > > be OK to have if-blocks only with a DCHECK inside, is it? > > I think it is fine to have an if-block with just a DCHECK inside. Example in > RFHM (with a CHECK): > https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/fr... > Generally the goal is to have simpler logical conditions and less indentation. Done! > > Let's then discuss the correct policy we should use elsewhere. > > > > > > > They're making me realize that I'm not sure what process model you're > > > > intending > > > > > for PlzNavigate. Today, Chrome is careful not to swap processes for > most > > > > > renderer-initiated cross-site navigations (in the main frame). This is > > for > > > > > important reasons, like OAuth popups where a cross-site iframe creates a > > > popup > > > > > that needs to stay in the same process. > > > > > > > > > > It looks like this check is creating a policy halfway between default > > Chrome > > > > > behavior and --site-per-process, in a way that breaks OAuth popups. > > Perhaps > > > > we > > > > > should discuss (in a separate email?) what process model policy you all > > want > > > > > PlzNavigate to use, and then we can make it happen here. > > > > > > > > In that case, we need to be able to distinguish here between a > > > > renderer-initiated navigation and a browser-initiated one. We don't do it > > > right > > > > now, though it would be useful for other purposes (ie canceling or not an > > > > ongoing navigation request). Would a TODO: do not swap processes for > > renderer > > > > initiated navigations be sufficient for the time being, with the goal to > > > revise > > > > it when we have agreed on a process model to use? > > > > Interesting you mentioned that. While looking at > > NavigatorImpl::OnBeginNavigation I noticed there could be a problem when a > > renderer-initiated navigation is requested while there's already an ongoing > one. > > It seemed it wouldn't cancel the old one and I understand you just confirmed > > that. > > Actually it is not canceled. Instead we attempt to call > NavigationRequest::BeginNavigation again on the existing one. This fails because > of a DCHECK(!_loader.get()). I am currently working on fixing that behavior (and > have the current request be canceled by the render-initiated one if it was > user-initiated as well). Ack. > > > Yes, but this is an important TODO we'll need to resolve. Let's include a > bug > > > number for it. > > > > I added the TODO and created the respective issue: crbug.com/440266 > https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... File content/browser/frame_host/navigator_impl.cc (right): https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/navigator_impl.cc:757: // First starts the IO/net requests. On 2014/12/09 15:09:52, clamy wrote: > nit: I would rephrase as "First start the request on the IO thread. Done. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/navigator_impl.cc:759: // Then notify the manager so it can speculatively create a renderer in On 2014/12/09 15:09:52, clamy wrote: > Please add a line before the comment. > nit: s/manager/RenderFrameHostManager Done. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:99: RenderFrameHostManager* root_rfhm = root->render_manager(); On 2014/12/09 15:09:52, clamy wrote: > nit: Please add an empty line here. This part was moved to another test. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:128: // Subframe navigations should not create a speculative RenderFrameHost. On 2014/12/09 15:09:52, clamy wrote: > nit: Please add an empty line before this comment. Done. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:129: // (unless site-per-process is enabled) On 2014/12/10 22:37:45, Charlie Reis wrote: > nit: Period goes after the the close paren, not after RenderFrameHost. > > Can we find a way to make this pass with the --site-per-process flag? Otherwise > our Site Isolation FYI bots will go red. Done. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:145: // Main frame navigations to different sites should use a speculative On 2014/12/09 15:09:52, clamy wrote: > nit: Please add an empty line before this comment. Done. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:163: // As we're re-using the current RenderFrameHost, no speculative one should be On 2014/12/09 15:09:52, clamy wrote: > nit: Please add an empty line before this comment. Done. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:200: // Navigations to a different site do create a speculative RenderFrameHost. On 2014/12/09 15:09:52, clamy wrote: > nit: Please add an empty line before this comment. Done. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:440: // Commit the navigation with Navigator by simulating the call to On 2014/12/10 22:37:45, Charlie Reis wrote: > How about: "Ask Navigator to commit the navigation by simulating..." Done. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:498: EXPECT_EQ(site_instance_id, On 2014/12/10 22:37:45, Charlie Reis wrote: > Please add a TODO, given that the behavior (stale RFH) doesn't seem to match the > test description or desired behavior (discard on redirect). Done. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:512: // PlzNavigate: Verify a previously swapped-out RenderFrameHost is correctly On 2014/12/09 15:09:52, clamy wrote: > s/Verify/Verify that > > I would also rephrase as "is correctly used when spawning a speculative > RenderFrameHost in a navigation using the same SiteInstance". Done. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:75: CleanUpNavigation(); On 2014/12/12 22:37:54, ncarter wrote: > A CL I'm working on -- https://codereview.chromium.org/799593004/ -- will fix a > bug in ~RenderFrameHostManager that's due to the save-for-reuse work of > DiscardUnusedFrame being problematic during destruction. > > Since CleanUpNavigation() also calls DiscardUnusedFrame, I think this will > introduce a new instance of that bug. See if you can use the test I added in the > CL as a starting point for tickling the CleanUpNavigation() instance? Thanks for pointing this out! I refactored the code to follow pretty much exactly your fix for the pending case. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:448: if (render_frame_host == pending_render_frame_host_) { On 2014/12/09 15:09:52, clamy wrote: > We probably want to something a bit similar, only with the speculative RFH > instead of the pending one. I am not sure we can quite reuse that one, due to > slight differences in the case of same-site navigations (see below). This makes me think that even after committing a specific RFH we could get a different one here. Isn't this awfully weird? And I'm guessing we want to change this with PlzNavigate? Also I don't know if this is lacking support by our test infrastructure or if it's PlzNavigate that is still incomplete, but this method always receives the currently active RFH instead of the one that was committed before. So I tried adding this DCHECK: DCHECK((render_frame_host == speculative_render_frame_host_.get()) || (render_frame_host == render_frame_host_.get() && !speculative_render_frame_host_)); but it would just fail all the time because of that. I'm adding TODOs and we'll have to figure this out later. Maybe the solution is simply to remove the RenderFrameHostImpl parameter? https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:452: } else if (render_frame_host == render_frame_host_) { On 2014/12/09 15:09:52, clamy wrote: > Note that in the PlzNavigate case, we only want to cancel the current navigation > (and speculative RFH) if we receive a commit message from an in-page > user-initiated navigation. In-page non user-initiated navigations should not > cancel any pending navigations, and in all other cases the pending navigation > should be the one that commits, and there should be no speculative RFH. > > Also, CancelPending destroys the pending RFH, which indeed cancels an on-going > cross-site navigation. In PlzNavigate it does not work that way, so we need to > make sure that navigations are properly cancelled following the commit of > in-page user-initiated navigations. I think this can be left as a TODO for a > future patch though. Let me try to understand what you are saying. You are referring to the case where an ongoing navigation was cancelled by a new request but this method is called anyway for the cancelled one as the renderer was already processing it. Is this so? I think we'll have to figure out how to deal with that when we handle cancellations properly and I'd really like to do this using the navigation request ID. I added a TODO for this too. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:671: return; On 2014/12/10 22:37:45, Charlie Reis wrote: > On 2014/12/09 15:09:52, clamy wrote: > > On 2014/12/09 07:55:43, carlosk wrote: > > > These are the returns I'd like to eliminate but I'd have to use if-blocks to > > > hold DCHECKs. > > > > While it is fine in general to have an if-block with only a DCHECK inside, I > > don't think it would be better in that case. IMO the early return makes it > > clearer that something went wrong if InitRenderView did not succeed, compared > to > > writing: > > if (InitRenderView(...)) > > DCHECK(current_instance->GetProcess()->HasConnection()) > > return; > > +1 to both. > > (DCHECKs inside a conditional mostly make sense if the conditional can be > optimized out.) Finally I didn't need the if's. I simply DCHECK the |success|es. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:677: // Speculatively create a new RFH. On 2014/12/09 15:09:52, clamy wrote: > Please add a line before that comment and remove the one below. Done. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:724: RenderFrameHostImpl* RenderFrameHostManager::GetFrameHostForNavigation( On 2014/12/09 15:09:52, clamy wrote: > Please modify this function so that it does not commit the pending RFH. Instead > it should either return the current renderer, or the speculative RFH. If it > turns out we need a speculative RFH and we don't have one, or the one we have is > wrong, a new speculative RFh should be created and returned. Done. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:762: CommitPending(); On 2014/12/10 23:11:34, nasko wrote: > Why is this method calling CommitPending? Because it was here that we would switch the active RFHs. It was moved back to the later step at DidNavigateFrame as per other discussions. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:373: // Notifies the RFHM that a navigation is about to begin so that it can On 2014/12/10 23:11:34, nasko wrote: > nit: s/about to begin/has begun/ since we issue the network request before > calling into RFHM. Done. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:374: // speculatively spawn a new renderer process if needed. On 2014/12/10 23:11:34, nasko wrote: > nit: s/spawn/create/ Done. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:379: // Called when a navigation is ready to commit, to select the RenderFrameHost On 2014/12/10 23:11:34, nasko wrote: > nit: no need for comma Done. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:486: // speculative creation of a new speculative RenderFrameHost for an ongoing On 2014/12/10 23:11:34, nasko wrote: > nit: It will be nice to avoid using "speculative" twice in the same sentence, > makes it hard to read. Yeah, this was very bad Engrish. ;) I updated the whole comment and hopefully it's better now.
Patchset #18 (id:450001) has been deleted
Thanks! Please find a few comments below. It is looking better, and I think we have ironed out the main issues. https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... File content/browser/frame_host/render_frame_host_manager.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:448: if (render_frame_host == pending_render_frame_host_) { On 2014/12/16 01:53:48, carlosk wrote: > On 2014/12/09 15:09:52, clamy wrote: > > We probably want to something a bit similar, only with the speculative RFH > > instead of the pending one. I am not sure we can quite reuse that one, due to > > slight differences in the case of same-site navigations (see below). > > This makes me think that even after committing a specific RFH we could get a > different one here. Isn't this awfully weird? And I'm guessing we want to change > this with PlzNavigate? > > Also I don't know if this is lacking support by our test infrastructure or if > it's PlzNavigate that is still incomplete, but this method always receives the > currently active RFH instead of the one that was committed before. So I tried > adding this DCHECK: > > DCHECK((render_frame_host == speculative_render_frame_host_.get()) || > (render_frame_host == render_frame_host_.get() && > !speculative_render_frame_host_)); > > but it would just fail all the time because of that. > > I'm adding TODOs and we'll have to figure this out later. Maybe the solution is > simply to remove the RenderFrameHostImpl parameter? No we can only get the pending RFH or current RFH with the way the code currently works. And with the way PlzNavigate should work, we should also only get the speculative or the current one. I don't really understand what you mean by RFH we commit. We commit the RFH that sends us this IPC. As to reason the test is failing, it is most likely because the tests make use of TestWebContents::NavigateAndCommit. This function itself calls TestWebContents::CommitPendingNavigation. The way the function works is by doing roughly this: TestRenderFrameHost* old_rfh = GetMainFrame(); TestRenderFrameHost* rfh = GetPendingMainFrame(); if (!rfh) rfh = old_rfh; rfh->SendDidNavigate It needs to be updated to take into account the speculative RFH instead of the pending one when PlzNavigate is enabled (otherwise since the pending rfh is always null, we will only call DidNavigate with the current rfh). https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:452: } else if (render_frame_host == render_frame_host_) { On 2014/12/16 01:53:48, carlosk wrote: > On 2014/12/09 15:09:52, clamy wrote: > > Note that in the PlzNavigate case, we only want to cancel the current > navigation > > (and speculative RFH) if we receive a commit message from an in-page > > user-initiated navigation. In-page non user-initiated navigations should not > > cancel any pending navigations, and in all other cases the pending navigation > > should be the one that commits, and there should be no speculative RFH. > > > > Also, CancelPending destroys the pending RFH, which indeed cancels an on-going > > cross-site navigation. In PlzNavigate it does not work that way, so we need to > > make sure that navigations are properly cancelled following the commit of > > in-page user-initiated navigations. I think this can be left as a TODO for a > > future patch though. > > Let me try to understand what you are saying. You are referring to the case > where an ongoing navigation was cancelled by a new request but this method is > called anyway for the cancelled one as the renderer was already processing it. > Is this so? > > I think we'll have to figure out how to deal with that when we handle > cancellations properly and I'd really like to do this using the navigation > request ID. I added a TODO for this too. I've written what I meant in code version in the comment above, so it should be easier to understand. I left the cancelation part as a TODO. We cannot use navigation request ID as those were removed. Instead, we just need to destroy the navigation request for the FrameTreeNode that is stored in NavigatorImpl. https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:671: return; On 2014/12/16 01:53:48, carlosk wrote: > On 2014/12/10 22:37:45, Charlie Reis wrote: > > On 2014/12/09 15:09:52, clamy wrote: > > > On 2014/12/09 07:55:43, carlosk wrote: > > > > These are the returns I'd like to eliminate but I'd have to use if-blocks > to > > > > hold DCHECKs. > > > > > > While it is fine in general to have an if-block with only a DCHECK inside, I > > > don't think it would be better in that case. IMO the early return makes it > > > clearer that something went wrong if InitRenderView did not succeed, > compared > > to > > > writing: > > > if (InitRenderView(...)) > > > DCHECK(current_instance->GetProcess()->HasConnection()) > > > return; > > > > +1 to both. > > > > (DCHECKs inside a conditional mostly make sense if the conditional can be > > optimized out.) > > Finally I didn't need the if's. I simply DCHECK the |success|es. That is not equivalent to the previous condition. https://chromiumcodereview.appspot.com/701953006/diff/410001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:766: // If the renderer that needs to navigate is not live (it was just created or As mentionned above this _must_ absolutely stay there. We can't have an initialized renderer try to commit the page. The renderer selected here is going to try to request the navigation url from the browser and get the body of the response (and it absolutely needs to be live to do that). https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:83: FrameHostMsg_DidCommitProvisionalLoad_Params BuildSimpleDCPLParams(GURL url) { This is actually a rewrite of some of the helper functions of TestRenderFrameHost. I think you should be using TestRenderFrameHost::SendNavigate instead of TestRenderFrameHost::SendNavigateWithParams and a function to generate default params. https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:96: // this these checks). Remove the extra this. https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:302: main_test_rfh()->SendNavigateWithParams(¶ms); Switch to using TestRenderFrameHost::SendNavigate (here and below). https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:357: EXPECT_EQ(final_srfh, final_rfh); nit: could you rename one of those parameters? final_srfh and final_rfh are a bit hard to tell apart. https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:598: // Then to another to swap-out the initial RenderFrameHost. s/Then to another/Navigate to another site https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:606: // Now goes back to the initial site. s/goes/go I would add a comment along the lines of: The swapped-out initial RenderFrameHost should be reused. https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:607: contents()->NavigateAndCommit(kUrl1); I think you could actually split the NavigateAndCommit here to check that you actually have a speculative rfh, and that it is the swapped out initial RFH. https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... File content/browser/frame_host/render_frame_host_impl.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... content/browser/frame_host/render_frame_host_impl.cc:1401: SetState(RenderFrameHostImpl::STATE_DEFAULT); Could you add the comment that is present in RenderFrameImpl::Navigate above this line as well? The reason we reset the state to default here is the same. https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... File content/browser/frame_host/render_frame_host_manager.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:440: CommitPending(); No we shouldn't eliminate this parameter. Also this method is always triggered by the renderer since it is called in response to receiving an IPC from it. What we should be doing here is roughly: if (render_frame_host == speculative_render_frame_host_.get()) { CommitPending(); DCHECK(!speculative_render_frame_host_.get()); } else if (render_frame_host == render_frame_host_.get()) { if (!is_same_document_navigation) { // This is a same-site navigation driven by the browser. There should not be a speculative RenderFrameHost. DCHECK(!speculative_render_frame_host_.get()); } else { if (was_caused_by_user_gesture) { // TODO: make sure the ongoing navigation request is properly canceled } } } else { // No one else should be sending us a DidNavigate in this state. DCHECK(false); } This requires introducing an additional boolean to the arguments of the function to distinguish same-document navigations from the rest. Also you may want to think about merging this logic with the one below. https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:443: // If the renderer that needs to navigate is not live (it was just created Why is that block here? The code in this function should be pretty close to what is below. Any initialization work should be done in GetFrameHostForNavigation.
Few more nits. Camille has raised quite a few points, so I'll wait for the next patch. https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:154: EXPECT_FALSE(GetSpeculativeRenderFrameHost(root_rfhm)); nit: Move this check before the comment as it doesn't check subframes. https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... File content/browser/frame_host/render_frame_host_manager.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:297: DCHECK(!CommandLine::ForCurrentProcess()->HasSwitch( Why not move this check up? Should we ever see OnBeforeUnloadACK in PlzNavigate world? https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:476: // See https://code.google.com/p/chromium/issues/detail?id=75195 nit: Use https://crbug.com/75195 for shorter URLs. https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... File content/browser/frame_host/render_frame_host_manager.h (right): https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... content/browser/frame_host/render_frame_host_manager.h:381: // that will commit it. nit: "the RenderFrameHost in which the navigation will commit."
Patchset #18 (id:470001) has been deleted
Thansk for one more round of comments. https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:448: if (render_frame_host == pending_render_frame_host_) { On 2014/12/16 15:22:48, clamy wrote: > On 2014/12/16 01:53:48, carlosk wrote: > > On 2014/12/09 15:09:52, clamy wrote: > > > We probably want to something a bit similar, only with the speculative RFH > > > instead of the pending one. I am not sure we can quite reuse that one, due > to > > > slight differences in the case of same-site navigations (see below). > > > > This makes me think that even after committing a specific RFH we could get a > > different one here. Isn't this awfully weird? And I'm guessing we want to > change > > this with PlzNavigate? > > > > Also I don't know if this is lacking support by our test infrastructure or if > > it's PlzNavigate that is still incomplete, but this method always receives the > > currently active RFH instead of the one that was committed before. So I tried > > adding this DCHECK: > > > > DCHECK((render_frame_host == speculative_render_frame_host_.get()) || > > (render_frame_host == render_frame_host_.get() && > > !speculative_render_frame_host_)); > > > > but it would just fail all the time because of that. > > > > I'm adding TODOs and we'll have to figure this out later. Maybe the solution > is > > simply to remove the RenderFrameHostImpl parameter? > > No we can only get the pending RFH or current RFH with the way the code > currently works. And with the way PlzNavigate should work, we should also only > get the speculative or the current one. I don't really understand what you mean > by RFH we commit. We commit the RFH that sends us this IPC. Now that I read all of your other comments I realized that this method can be called by the renderer without being triggered from the browser by an ongoing navigation. > As to reason the test is failing, it is most likely because the tests make use > of TestWebContents::NavigateAndCommit. This function itself calls > TestWebContents::CommitPendingNavigation. The way the function works is by doing > roughly this: > TestRenderFrameHost* old_rfh = GetMainFrame(); > TestRenderFrameHost* rfh = GetPendingMainFrame(); > if (!rfh) > rfh = old_rfh; > > rfh->SendDidNavigate > > It needs to be updated to take into account the speculative RFH instead of the > pending one when PlzNavigate is enabled (otherwise since the pending rfh is > always null, we will only call DidNavigate with the current rfh). I see. I added the speculative RFH support there but that was not enough as we were calling SendNavigate always on the main RFH. So I also switched to using TestWebContents::CommitPendingNavigation so that the correct RFH commits but that made me learn that as we were bypassing the controller the NavigationEntry was not being properly set. So I added a new test helper method, LoadURLAndBeginNavigationOnMainFrame, that most tests now use (when they don't need special navigation parameters) that calls the controller's LoadUrl and also SendBeginNavigationWithURL... And finally it worked. Whew! As a side thing I added a new method to TestWebContents to get the main frame's speculative RFH in the model of the existing one for pending. I didn't remove the one we already had in NavigatorTestWithBrowserSideNavigation because it's still needed for special cases (subframes). https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:452: } else if (render_frame_host == render_frame_host_) { On 2014/12/16 15:22:48, clamy wrote: > On 2014/12/16 01:53:48, carlosk wrote: > > On 2014/12/09 15:09:52, clamy wrote: > > > Note that in the PlzNavigate case, we only want to cancel the current > > navigation > > > (and speculative RFH) if we receive a commit message from an in-page > > > user-initiated navigation. In-page non user-initiated navigations should not > > > cancel any pending navigations, and in all other cases the pending > navigation > > > should be the one that commits, and there should be no speculative RFH. > > > > > > Also, CancelPending destroys the pending RFH, which indeed cancels an > on-going > > > cross-site navigation. In PlzNavigate it does not work that way, so we need > to > > > make sure that navigations are properly cancelled following the commit of > > > in-page user-initiated navigations. I think this can be left as a TODO for a > > > future patch though. > > > > Let me try to understand what you are saying. You are referring to the case > > where an ongoing navigation was cancelled by a new request but this method is > > called anyway for the cancelled one as the renderer was already processing it. > > Is this so? > > > > I think we'll have to figure out how to deal with that when we handle > > cancellations properly and I'd really like to do this using the navigation > > request ID. I added a TODO for this too. > > I've written what I meant in code version in the comment above, so it should be > easier to understand. I left the cancelation part as a TODO. We cannot use > navigation request ID as those were removed. Instead, we just need to destroy > the navigation request for the FrameTreeNode that is stored in NavigatorImpl. Acknowledged. Note: Your reference to the "code above" confused the hell out of me as the comment you are actually referring to is in the next PatchSet. :) https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:671: return; On 2014/12/16 15:22:48, clamy wrote: > On 2014/12/16 01:53:48, carlosk wrote: > > On 2014/12/10 22:37:45, Charlie Reis wrote: > > > On 2014/12/09 15:09:52, clamy wrote: > > > > On 2014/12/09 07:55:43, carlosk wrote: > > > > > These are the returns I'd like to eliminate but I'd have to use > if-blocks > > to > > > > > hold DCHECKs. > > > > > > > > While it is fine in general to have an if-block with only a DCHECK inside, > I > > > > don't think it would be better in that case. IMO the early return makes it > > > > clearer that something went wrong if InitRenderView did not succeed, > > compared > > > to > > > > writing: > > > > if (InitRenderView(...)) > > > > DCHECK(current_instance->GetProcess()->HasConnection()) > > > > return; > > > > > > +1 to both. > > > > > > (DCHECKs inside a conditional mostly make sense if the conditional can be > > > optimized out.) > > > > Finally I didn't need the if's. I simply DCHECK the |success|es. > > That is not equivalent to the previous condition. You are right, it is not equivalent for the Debug case as it will crash on renderer creation failure. Now for the Release case it is still equivalent. As this version has stronger guarantees and content tests are still passing I thought it was OK to keep it that way. WDYT? https://codereview.chromium.org/701953006/diff/410001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:766: // If the renderer that needs to navigate is not live (it was just created or On 2014/12/16 15:22:48, clamy wrote: > As mentionned above this _must_ absolutely stay there. We can't have an > initialized renderer try to commit the page. The renderer selected here is going > to try to request the navigation url from the browser and get the body of the > response (and it absolutely needs to be live to do that). Acknowledged and moved it back here from DidNavigateFrame. https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:83: FrameHostMsg_DidCommitProvisionalLoad_Params BuildSimpleDCPLParams(GURL url) { On 2014/12/16 15:22:48, clamy wrote: > This is actually a rewrite of some of the helper functions of > TestRenderFrameHost. I think you should be using > TestRenderFrameHost::SendNavigate instead of > TestRenderFrameHost::SendNavigateWithParams and a function to generate default > params. Done. https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:96: // this these checks). On 2014/12/16 15:22:48, clamy wrote: > Remove the extra this. Done. https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:154: EXPECT_FALSE(GetSpeculativeRenderFrameHost(root_rfhm)); On 2014/12/18 00:22:39, nasko wrote: > nit: Move this check before the comment as it doesn't check subframes. Done. https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:302: main_test_rfh()->SendNavigateWithParams(¶ms); On 2014/12/16 15:22:48, clamy wrote: > Switch to using TestRenderFrameHost::SendNavigate (here and below). Done. https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:357: EXPECT_EQ(final_srfh, final_rfh); On 2014/12/16 15:22:48, clamy wrote: > nit: could you rename one of those parameters? final_srfh and final_rfh are a > bit hard to tell apart. Done. https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:598: // Then to another to swap-out the initial RenderFrameHost. On 2014/12/16 15:22:48, clamy wrote: > s/Then to another/Navigate to another site Done. https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:606: // Now goes back to the initial site. On 2014/12/16 15:22:48, clamy wrote: > s/goes/go > > I would add a comment along the lines of: The swapped-out initial > RenderFrameHost should be reused. Done. https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:607: contents()->NavigateAndCommit(kUrl1); On 2014/12/16 15:22:48, clamy wrote: > I think you could actually split the NavigateAndCommit here to check that you > actually have a speculative rfh, and that it is the swapped out initial RFH. Done. https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_impl.cc (right): https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... content/browser/frame_host/render_frame_host_impl.cc:1401: SetState(RenderFrameHostImpl::STATE_DEFAULT); On 2014/12/16 15:22:48, clamy wrote: > Could you add the comment that is present in RenderFrameImpl::Navigate above > this line as well? The reason we reset the state to default here is the same. Done. https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:297: DCHECK(!CommandLine::ForCurrentProcess()->HasSwitch( On 2014/12/18 00:22:39, nasko wrote: > Why not move this check up? Should we ever see OnBeforeUnloadACK in PlzNavigate > world? I'm not super sure but it seems it would. My indirect evidence is that RenderFrameHostImpl::OnBeforeUnloadACK calls this and it was there that I added those new navigation metrics and they do work with PlzNavigate. https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:440: CommitPending(); On 2014/12/16 15:22:48, clamy wrote: > No we shouldn't eliminate this parameter. Also this method is always triggered > by the renderer since it is called in response to receiving an IPC from it. What > we should be doing here is roughly: > > if (render_frame_host == speculative_render_frame_host_.get()) { > CommitPending(); > DCHECK(!speculative_render_frame_host_.get()); > } else if (render_frame_host == render_frame_host_.get()) { > if (!is_same_document_navigation) { > // This is a same-site navigation driven by the browser. There should not be > a speculative RenderFrameHost. > DCHECK(!speculative_render_frame_host_.get()); > } else { > if (was_caused_by_user_gesture) { > // TODO: make sure the ongoing navigation request is properly canceled > } > } > } else { > // No one else should be sending us a DidNavigate in this state. > DCHECK(false); > } > > This requires introducing an additional boolean to the arguments of the function > to distinguish same-document navigations from the rest. Also you may want to > think about merging this logic with the one below. OK, now I understand. I hadn't realized before that this method could be invoked by the renderer without an existing ongoing navigation. I implemented it but chose not to mix it with the similar code below to keep the PlzNavigate version separate and consequentially cleaner. I left the cancellation TODO there. Is it OK to leave it for a following CL? https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:443: // If the renderer that needs to navigate is not live (it was just created On 2014/12/16 15:22:48, clamy wrote: > Why is that block here? The code in this function should be pretty close to what > is below. Any initialization work should be done in GetFrameHostForNavigation. Acknowledged. I didn't realize before that it was at that point that the renderer needed to exist so that it could receive the commit IPC. https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:476: // See https://code.google.com/p/chromium/issues/detail?id=75195 On 2014/12/18 00:22:40, nasko wrote: > nit: Use https://crbug.com/75195 for shorter URLs. Done. https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:381: // that will commit it. On 2014/12/18 00:22:40, nasko wrote: > nit: "the RenderFrameHost in which the navigation will commit." Done. https://codereview.chromium.org/701953006/diff/490001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (left): https://codereview.chromium.org/701953006/diff/490001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1531: UpdateStateForNavigate is not called by PlzNavigate code anymore.
Thanks! A few more comments, mostly centered on the tests. https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:302: main_test_rfh()->SendNavigateWithParams(¶ms); On 2014/12/19 04:27:14, carlosk wrote: > On 2014/12/16 15:22:48, clamy wrote: > > Switch to using TestRenderFrameHost::SendNavigate (here and below). > > Done. I really meant to use that precise function and not TestWebContents::CommitPendingNavigation. Using the later will break when https://chromiumcodereview.appspot.com/761013003/ lands (you will call OnResponseStarted on the loader twice). https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... File content/browser/frame_host/render_frame_host_manager.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:297: DCHECK(!CommandLine::ForCurrentProcess()->HasSwitch( On 2014/12/19 04:27:15, carlosk wrote: > On 2014/12/18 00:22:39, nasko wrote: > > Why not move this check up? Should we ever see OnBeforeUnloadACK in > PlzNavigate > > world? > > I'm not super sure but it seems it would. My indirect evidence is that > RenderFrameHostImpl::OnBeforeUnloadACK calls this and it was there that I added > those new navigation metrics and they do work with PlzNavigate. We will still see OnBeforeUnloadACK for tab closes. https://chromiumcodereview.appspot.com/701953006/diff/430001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:440: CommitPending(); On 2014/12/19 04:27:15, carlosk wrote: > On 2014/12/16 15:22:48, clamy wrote: > > No we shouldn't eliminate this parameter. Also this method is always triggered > > by the renderer since it is called in response to receiving an IPC from it. > What > > we should be doing here is roughly: > > > > if (render_frame_host == speculative_render_frame_host_.get()) { > > CommitPending(); > > DCHECK(!speculative_render_frame_host_.get()); > > } else if (render_frame_host == render_frame_host_.get()) { > > if (!is_same_document_navigation) { > > // This is a same-site navigation driven by the browser. There should not > be > > a speculative RenderFrameHost. > > DCHECK(!speculative_render_frame_host_.get()); > > } else { > > if (was_caused_by_user_gesture) { > > // TODO: make sure the ongoing navigation request is properly canceled > > } > > } > > } else { > > // No one else should be sending us a DidNavigate in this state. > > DCHECK(false); > > } > > > > This requires introducing an additional boolean to the arguments of the > function > > to distinguish same-document navigations from the rest. Also you may want to > > think about merging this logic with the one below. > > OK, now I understand. I hadn't realized before that this method could be invoked > by the renderer without an existing ongoing navigation. > > I implemented it but chose not to mix it with the similar code below to keep the > PlzNavigate version separate and consequentially cleaner. > > I left the cancellation TODO there. Is it OK to leave it for a following CL? Yes. I think this CL has enough in it already that we don't need to tackle that right now. https://chromiumcodereview.appspot.com/701953006/diff/490001/content/browser/... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/490001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:224: LoadURLAndBeginNavigationOnMainFrame(kUrl2); Considering that the unit tests are for NavigatorImpl and the navigation logic specifically, I'm not terribly fan of abstracting it away in this helper function. I don't know what the other reviewers think about it though. https://chromiumcodereview.appspot.com/701953006/diff/490001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:428: main_test_rfh()->SendNavigate(10, kUrl); Why 10? https://chromiumcodereview.appspot.com/701953006/diff/490001/content/public/t... File content/public/test/web_contents_tester.h (right): https://chromiumcodereview.appspot.com/701953006/diff/490001/content/public/t... content/public/test/web_contents_tester.h:67: // Gets the speculative RenderFrameHost, if any, for the main frame. Please preface this with a PlzNavigate comment. Also, we would need a method that would return either the pending RFH in current navigation or the speculative one in PlzNavigate to use in unit tests (to replace GetPendingMainFrame in many of them). Maybe it can be called GetNextMainFrame, or GetFutureMainFrame. And I'm not sure we currently need to expose both these methods to the public API. https://chromiumcodereview.appspot.com/701953006/diff/490001/content/test/tes... File content/test/test_web_contents.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/490001/content/test/tes... content/test/test_web_contents.cc:182: rfh = GetSpeculativeMainFrame(); This is one of the cases where having a method that returns either the pending or the speculative RFH would come in handy. https://chromiumcodereview.appspot.com/701953006/diff/490001/content/test/tes... content/test/test_web_contents.cc:210: if (!GetPendingMainFrame() && !GetSpeculativeMainFrame()) This function should only be called at the beginning of a cross-site navigation in the current codepath. In PlzNavigate, the execution of the BeforeUnload handler is to be done through the RequestNavigation/BeginNavigation pair. Therefore, what you should do here is return immediately when PlzNavigate is enabled, or have a DCHECK PlzNavigate is not enabled, and make sure we don't call it when it is.
[Note: Sorry that I didn't get a chance to look at this before going OOO. I've been heads down on 429399 and 436379. I'll take a look again in January.] To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
It is getting better! Hopefully it is close. Few more comments. In general, please separate patches between sync and actual code changes. It makes reviewing a LOT more efficient if the intra-patchset diffs actually work. https://chromiumcodereview.appspot.com/701953006/diff/490001/content/browser/... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/490001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:103: EXPECT_FALSE(contents()->GetSpeculativeMainFrame()); I'd rather not add more code to contents(), as people need to start thinking in terms of frames. If you want to gain readability of the test code, use a static method as in the previous patchset. https://chromiumcodereview.appspot.com/701953006/diff/490001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:224: LoadURLAndBeginNavigationOnMainFrame(kUrl2); On 2014/12/19 13:35:57, clamy wrote: > Considering that the unit tests are for NavigatorImpl and the navigation logic > specifically, I'm not terribly fan of abstracting it away in this helper > function. I don't know what the other reviewers think about it though. I'd second that, mainly since the abstraction is just two very simple method calls. https://chromiumcodereview.appspot.com/701953006/diff/490001/content/browser/... File content/browser/frame_host/render_frame_host_manager.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/490001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:429: } else if (render_frame_host == render_frame_host_.get()) { Can't we simplify this if/else to be if (spectulative) else DCHECK (rfh == rfh_.get()? https://chromiumcodereview.appspot.com/701953006/diff/490001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:430: if (!was_within_same_page) { If statement just for a DCHECK isn't worthwhile. Fold it into the DCHECK itself. https://chromiumcodereview.appspot.com/701953006/diff/490001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:435: if (was_caused_by_user_gesture) { Let's skip adding the if statement, just add the condition as wording in the comment. https://chromiumcodereview.appspot.com/701953006/diff/490001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:664: SiteInstance* current_instance = render_frame_host_->GetSiteInstance(); The block of code from here to 692 looks almost identical to GetFrameHostForNavigation. Why not just call that method and avoid code duplication? In general both browser-initiated and renderer-initiated navigations will have to execute the same logic, so it makes sense even at the higher level. https://chromiumcodereview.appspot.com/701953006/diff/490001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:767: // former. nit: former is what? SiteInstance, URL, or RFH? https://chromiumcodereview.appspot.com/701953006/diff/490001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:1525: // Swap in the pending frame and make it active. Also ensure the FrameTree I think this comment can be updated and put above the if statement, as it applies equally well for both cases, just "pending or speculative". https://chromiumcodereview.appspot.com/701953006/diff/490001/content/public/t... File content/public/test/web_contents_tester.h (right): https://chromiumcodereview.appspot.com/701953006/diff/490001/content/public/t... content/public/test/web_contents_tester.h:67: // Gets the speculative RenderFrameHost, if any, for the main frame. On 2014/12/19 13:35:57, clamy wrote: > Please preface this with a PlzNavigate comment. Also, we would need a method > that would return either the pending RFH in current navigation or the > speculative one in PlzNavigate to use in unit tests (to replace > GetPendingMainFrame in many of them). Maybe it can be called GetNextMainFrame, > or GetFutureMainFrame. > > And I'm not sure we currently need to expose both these methods to the public > API. This definitely should not be exposed through public API. This is totally an internal optimization in content/ and shouldn't be known outside of it (even outside of RFHM if we want to be precise). https://chromiumcodereview.appspot.com/701953006/diff/490001/content/test/tes... File content/test/test_web_contents.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/490001/content/test/tes... content/test/test_web_contents.cc:206: // Note: At the moment in the navigation process when this method is called nit: s/process/progress/ https://chromiumcodereview.appspot.com/701953006/diff/490001/content/test/tes... content/test/test_web_contents.cc:207: // (after the RenderFrameHost committed), the speculative RenderFrameHost, if "(after the RenderFrameHost committed)" Is this actually true? The fact that the code later sends the BeforeUnloadACK it means that the navigation hasn't committed, though it has started.
Thanks again. Replies and changes are in. Had to upload a following PS because of missing base:: namespace references failing trybots (content tests ran locally just fine). https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:302: main_test_rfh()->SendNavigateWithParams(¶ms); On 2014/12/19 13:35:57, clamy wrote: > On 2014/12/19 04:27:14, carlosk wrote: > > On 2014/12/16 15:22:48, clamy wrote: > > > Switch to using TestRenderFrameHost::SendNavigate (here and below). > > > > Done. > > I really meant to use that precise function and not > TestWebContents::CommitPendingNavigation. Using the later will break when > https://chromiumcodereview.appspot.com/761013003/ lands (you will call > OnResponseStarted on the loader twice). OK. What was bugging me about that approach was that the RFH being committed was chosen by the test without checking for which one actually had sent the commit IPC (this was the case even with my previous change). For this and all following cases I reverted to using TestRenderFrameHost::SendNavigate as you suggested but also added pre-checks for the RFH we're calling it on being the one that actually committed. https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:297: DCHECK(!CommandLine::ForCurrentProcess()->HasSwitch( On 2014/12/19 13:35:57, clamy wrote: > On 2014/12/19 04:27:15, carlosk wrote: > > On 2014/12/18 00:22:39, nasko wrote: > > > Why not move this check up? Should we ever see OnBeforeUnloadACK in > > PlzNavigate > > > world? > > > > I'm not super sure but it seems it would. My indirect evidence is that > > RenderFrameHostImpl::OnBeforeUnloadACK calls this and it was there that I > added > > those new navigation metrics and they do work with PlzNavigate. > > We will still see OnBeforeUnloadACK for tab closes. Acknowledged. https://codereview.chromium.org/701953006/diff/430001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:440: CommitPending(); On 2014/12/19 13:35:57, clamy wrote: > On 2014/12/19 04:27:15, carlosk wrote: > > On 2014/12/16 15:22:48, clamy wrote: > > > No we shouldn't eliminate this parameter. Also this method is always > triggered > > > by the renderer since it is called in response to receiving an IPC from it. > > What > > > we should be doing here is roughly: > > > > > > if (render_frame_host == speculative_render_frame_host_.get()) { > > > CommitPending(); > > > DCHECK(!speculative_render_frame_host_.get()); > > > } else if (render_frame_host == render_frame_host_.get()) { > > > if (!is_same_document_navigation) { > > > // This is a same-site navigation driven by the browser. There should > not > > be > > > a speculative RenderFrameHost. > > > DCHECK(!speculative_render_frame_host_.get()); > > > } else { > > > if (was_caused_by_user_gesture) { > > > // TODO: make sure the ongoing navigation request is properly canceled > > > } > > > } > > > } else { > > > // No one else should be sending us a DidNavigate in this state. > > > DCHECK(false); > > > } > > > > > > This requires introducing an additional boolean to the arguments of the > > function > > > to distinguish same-document navigations from the rest. Also you may want to > > > think about merging this logic with the one below. > > > > OK, now I understand. I hadn't realized before that this method could be > invoked > > by the renderer without an existing ongoing navigation. > > > > I implemented it but chose not to mix it with the similar code below to keep > the > > PlzNavigate version separate and consequentially cleaner. > > > > I left the cancellation TODO there. Is it OK to leave it for a following CL? > > Yes. I think this CL has enough in it already that we don't need to tackle that > right now. Acknowledged. https://codereview.chromium.org/701953006/diff/490001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/490001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:103: EXPECT_FALSE(contents()->GetSpeculativeMainFrame()); On 2014/12/20 00:09:09, nasko (Out till 2015) wrote: > I'd rather not add more code to contents(), as people need to start thinking in > terms of frames. If you want to gain readability of the test code, use a static > method as in the previous patchset. I complied with what nasko@ and clamy@ asked for by: - Reverting to using a local static method for getting the speculative RFH in this test - Leaving the supporting changes to TestWebContents as they will be needed to make other tests work when PlzNavigate is enabled https://codereview.chromium.org/701953006/diff/490001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:224: LoadURLAndBeginNavigationOnMainFrame(kUrl2); On 2014/12/20 00:09:09, nasko (Out till 2015) wrote: > On 2014/12/19 13:35:57, clamy wrote: > > Considering that the unit tests are for NavigatorImpl and the navigation logic > > specifically, I'm not terribly fan of abstracting it away in this helper > > function. I don't know what the other reviewers think about it though. > > I'd second that, mainly since the abstraction is just two very simple method > calls. They were 2 repetitive calls that apart from the URL contained a lot of default valued parameters. It looked cleaner to me and the implementation was close by. But I didn't feel strongly about it and it's now reverted. https://codereview.chromium.org/701953006/diff/490001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:428: main_test_rfh()->SendNavigate(10, kUrl); On 2014/12/19 13:35:57, clamy wrote: > Why 10? I was just setting a value high enough. I fixed them to reflect the number of navigations inside the same site instance (that seems to be what they represent). https://codereview.chromium.org/701953006/diff/490001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/490001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:429: } else if (render_frame_host == render_frame_host_.get()) { On 2014/12/20 00:09:09, nasko wrote: > Can't we simplify this if/else to be if (spectulative) else DCHECK (rfh == > rfh_.get()? If I understood correctly what you meant I think it would be somewhat unsafe. If we should have a speculative set but (for some crazy reason) the instance passed in is neither the speculative nor the current one we would not detect that inconsistency. I could also add a DCHECK that verifies that the instance matches at least one of them, what would eliminate the final else and DCHECK(false). But even those a little more verbose I think these if-else blocks convey a clearer idea (I wrote that version locally and wasn't very fond of it). Following this and the next comments I updated this logic and left further instructions in the TODO. https://codereview.chromium.org/701953006/diff/490001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:430: if (!was_within_same_page) { On 2014/12/20 00:09:09, nasko wrote: > If statement just for a DCHECK isn't worthwhile. Fold it into the DCHECK itself. Done. https://codereview.chromium.org/701953006/diff/490001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:435: if (was_caused_by_user_gesture) { On 2014/12/20 00:09:09, nasko wrote: > Let's skip adding the if statement, just add the condition as wording in the > comment. Done. https://codereview.chromium.org/701953006/diff/490001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:664: SiteInstance* current_instance = render_frame_host_->GetSiteInstance(); On 2014/12/20 00:09:09, nasko wrote: > The block of code from here to 692 looks almost identical to > GetFrameHostForNavigation. Why not just call that method and avoid code > duplication? In general both browser-initiated and renderer-initiated > navigations will have to execute the same logic, so it makes sense even at the > higher level. I replied to a very similar comment from creis@ in message #49 when we still the code in GetFrameHostForNavigation was still in UpdateStateForNavigate. See https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h.... Mind that these two methods you are referring to belong exclusively to PlzNavigate. In both cases we have to do the SiteInstance check and take different actions depending on the result (the if-block contents from 680 to 691 are very different). I could extract a) the getting of both SiteInstances and b) the condition of the 1st if-block into a new method that returns a bool, possibly calling it ShouldKeepCurrentSiteInstance. I am reluctant to do it as I it would require quite some parameters to be passed in and doesn't look like a great de-duplication improvement. https://codereview.chromium.org/701953006/diff/490001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:767: // former. On 2014/12/20 00:09:09, nasko wrote: > nit: former is what? SiteInstance, URL, or RFH? I made the comment clearer. https://codereview.chromium.org/701953006/diff/490001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1525: // Swap in the pending frame and make it active. Also ensure the FrameTree On 2014/12/20 00:09:09, nasko wrote: > I think this comment can be updated and put above the if statement, as it > applies equally well for both cases, just "pending or speculative". Done. https://codereview.chromium.org/701953006/diff/490001/content/public/test/web... File content/public/test/web_contents_tester.h (right): https://codereview.chromium.org/701953006/diff/490001/content/public/test/web... content/public/test/web_contents_tester.h:67: // Gets the speculative RenderFrameHost, if any, for the main frame. On 2014/12/20 00:09:09, nasko wrote: > On 2014/12/19 13:35:57, clamy wrote: > > Please preface this with a PlzNavigate comment. Also, we would need a method > > that would return either the pending RFH in current navigation or the > > speculative one in PlzNavigate to use in unit tests (to replace > > GetPendingMainFrame in many of them). Maybe it can be called GetNextMainFrame, > > or GetFutureMainFrame. > > > > And I'm not sure we currently need to expose both these methods to the public > > API. > > This definitely should not be exposed through public API. This is totally an > internal optimization in content/ and shouldn't be known outside of it (even > outside of RFHM if we want to be precise). I added it to the public API because there is already one for the pending RFH. It's now removed from it. Given the previous request from clamy@ I kept it in the private API, added the pending-speculative shared getter but turned both into private methods. https://codereview.chromium.org/701953006/diff/490001/content/test/test_web_c... File content/test/test_web_contents.cc (right): https://codereview.chromium.org/701953006/diff/490001/content/test/test_web_c... content/test/test_web_contents.cc:182: rfh = GetSpeculativeMainFrame(); On 2014/12/19 13:35:57, clamy wrote: > This is one of the cases where having a method that returns either the pending > or the speculative RFH would come in handy. Done. https://codereview.chromium.org/701953006/diff/490001/content/test/test_web_c... content/test/test_web_contents.cc:206: // Note: At the moment in the navigation process when this method is called On 2014/12/20 00:09:09, nasko wrote: > nit: s/process/progress/ (comment was removed) https://codereview.chromium.org/701953006/diff/490001/content/test/test_web_c... content/test/test_web_contents.cc:207: // (after the RenderFrameHost committed), the speculative RenderFrameHost, if On 2014/12/20 00:09:09, nasko wrote: > "(after the RenderFrameHost committed)" Is this actually true? The fact that the > code later sends the BeforeUnloadACK it means that the navigation hasn't > committed, though it has started. What I meant was that the call to RFH::CommitNavigation aldready happened (it happens when we call CallOnResponseStarted on the loader). Is that not what we mean by the RFH having committed? But this comment was removed anyway. https://codereview.chromium.org/701953006/diff/490001/content/test/test_web_c... content/test/test_web_contents.cc:210: if (!GetPendingMainFrame() && !GetSpeculativeMainFrame()) On 2014/12/19 13:35:57, clamy wrote: > This function should only be called at the beginning of a cross-site navigation > in the current codepath. In PlzNavigate, the execution of the BeforeUnload > handler is to be done through the RequestNavigation/BeginNavigation pair. > > Therefore, what you should do here is return immediately when PlzNavigate is > enabled, or have a DCHECK PlzNavigate is not enabled, and make sure we don't > call it when it is. Done the 1st option as it eases things.
Thanks! A few comments on the latest patch set. https://chromiumcodereview.appspot.com/701953006/diff/490001/content/browser/... File content/browser/frame_host/render_frame_host_manager.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/490001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:664: SiteInstance* current_instance = render_frame_host_->GetSiteInstance(); On 2014/12/29 16:40:16, carlosk wrote: > On 2014/12/20 00:09:09, nasko wrote: > > The block of code from here to 692 looks almost identical to > > GetFrameHostForNavigation. Why not just call that method and avoid code > > duplication? In general both browser-initiated and renderer-initiated > > navigations will have to execute the same logic, so it makes sense even at the > > higher level. > > I replied to a very similar comment from creis@ in message #49 when we still the > code in GetFrameHostForNavigation was still in UpdateStateForNavigate. See > https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h.... > > Mind that these two methods you are referring to belong exclusively to > PlzNavigate. In both cases we have to do the SiteInstance check and take > different actions depending on the result (the if-block contents from 680 to 691 > are very different). > > I could extract a) the getting of both SiteInstances and b) the condition of the > 1st if-block into a new method that returns a bool, possibly calling it > ShouldKeepCurrentSiteInstance. I am reluctant to do it as I it would require > quite some parameters to be passed in and doesn't look like a great > de-duplication improvement. The thing is we should also make sure here that the speculative RFH is live, as in GetFrameHostForNavigation (otherwise we loose the benefit of having it spawned here in the first place). Then the logic becomes the same between the two methods. In any case, conceptually they should be doing the same thing (except in one case we do it earlier). The good thing about having a helper method with that logic inside is that when we want to change the speculative RFH on redirects we just need to call the helper function. https://chromiumcodereview.appspot.com/701953006/diff/490001/content/test/tes... File content/test/test_web_contents.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/490001/content/test/tes... content/test/test_web_contents.cc:207: // (after the RenderFrameHost committed), the speculative RenderFrameHost, if On 2014/12/29 16:40:17, carlosk wrote: > On 2014/12/20 00:09:09, nasko wrote: > > "(after the RenderFrameHost committed)" Is this actually true? The fact that > the > > code later sends the BeforeUnloadACK it means that the navigation hasn't > > committed, though it has started. > > What I meant was that the call to RFH::CommitNavigation aldready happened (it > happens when we call CallOnResponseStarted on the loader). Is that not what we > mean by the RFH having committed? > > But this comment was removed anyway. In the current code path this function is called before the navigation has even started. The navigation can only start when the BeforeUnload ack has been received, which is what the function simulates. https://chromiumcodereview.appspot.com/701953006/diff/550001/content/browser/... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/550001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:80: TestRenderFrameHost* GetSpeculativeRenderFrameHost( I don't think this method should take a RenderFrameHost as an argument. Instead it should take a RenderFrameHostManager or a FrameTreeNode. They both exist on a per-frame basis, as opposed to a per WebContents-basis, and make more sense here. https://chromiumcodereview.appspot.com/701953006/diff/550001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:316: DidRenderFrameHostCommit(GetSpeculativeRenderFrameHost(main_test_rfh()))); I think you could assign a variable to GetSpeculativeRenderFrameHost when it is not supposed to vary, instead of calling the function several times. Same comment in the tests below. https://chromiumcodereview.appspot.com/701953006/diff/550001/content/test/tes... File content/test/test_web_contents.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/550001/content/test/tes... content/test/test_web_contents.cc:176: if (!GetPendingMainFrame() || This return is no longer necessary, as following the unit test helper functions refactoring we should no longer be calling this in PlzNavigate unit tests. https://chromiumcodereview.appspot.com/701953006/diff/550001/content/test/tes... File content/test/test_web_contents.h (right): https://chromiumcodereview.appspot.com/701953006/diff/550001/content/test/tes... content/test/test_web_contents.h:122: TestRenderFrameHost* GetSpeculativeMainFrame() const; This method is currently private and used exactly one time in test_web_contents.cc and one line long. Please remove it if it is not going to be used publicly or make it public if it will be used. https://chromiumcodereview.appspot.com/701953006/diff/550001/content/test/tes... content/test/test_web_contents.h:128: TestRenderFrameHost* GetFutureMainFrame() const; This method should not be private as we expect to use it in several unit tests. Also please rephrase the comment with a description of what the method does in the current code path, and then on a new line PlzNavigate: with a description of what it does in PlzNavigate case.
Patchset #22 (id:570001) has been deleted
Patchset #22 (id:590001) has been deleted
Thanks! https://codereview.chromium.org/701953006/diff/490001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/490001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:664: SiteInstance* current_instance = render_frame_host_->GetSiteInstance(); On 2014/12/29 17:36:21, clamy wrote: > On 2014/12/29 16:40:16, carlosk wrote: > > On 2014/12/20 00:09:09, nasko wrote: > > > The block of code from here to 692 looks almost identical to > > > GetFrameHostForNavigation. Why not just call that method and avoid code > > > duplication? In general both browser-initiated and renderer-initiated > > > navigations will have to execute the same logic, so it makes sense even at > the > > > higher level. > > > > I replied to a very similar comment from creis@ in message #49 when we still > the > > code in GetFrameHostForNavigation was still in UpdateStateForNavigate. See > > > https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h.... > > > > Mind that these two methods you are referring to belong exclusively to > > PlzNavigate. In both cases we have to do the SiteInstance check and take > > different actions depending on the result (the if-block contents from 680 to > 691 > > are very different). > > > > I could extract a) the getting of both SiteInstances and b) the condition of > the > > 1st if-block into a new method that returns a bool, possibly calling it > > ShouldKeepCurrentSiteInstance. I am reluctant to do it as I it would require > > quite some parameters to be passed in and doesn't look like a great > > de-duplication improvement. > > The thing is we should also make sure here that the speculative RFH is live, as > in GetFrameHostForNavigation (otherwise we loose the benefit of having it > spawned here in the first place). Then the logic becomes the same between the > two methods. In any case, conceptually they should be doing the same thing > (except in one case we do it earlier). The good thing about having a helper > method with that logic inside is that when we want to change the speculative RFH > on redirects we just need to call the helper function. Yes, you are both right in fact! I was utterly confused. So I made GetFrameHostForNavigation the main implementation and now BeginNavigation calls into it. In the future when we should monitor redirects, we should just call GetFrameHostForNavigation again and be done with it. I also found out I was ignoring the speculative WebUI in InitRenderView so I fixed that too. https://codereview.chromium.org/701953006/diff/490001/content/test/test_web_c... File content/test/test_web_contents.cc (right): https://codereview.chromium.org/701953006/diff/490001/content/test/test_web_c... content/test/test_web_contents.cc:207: // (after the RenderFrameHost committed), the speculative RenderFrameHost, if On 2014/12/29 17:36:21, clamy wrote: > On 2014/12/29 16:40:17, carlosk wrote: > > On 2014/12/20 00:09:09, nasko wrote: > > > "(after the RenderFrameHost committed)" Is this actually true? The fact that > > the > > > code later sends the BeforeUnloadACK it means that the navigation hasn't > > > committed, though it has started. > > > > What I meant was that the call to RFH::CommitNavigation aldready happened (it > > happens when we call CallOnResponseStarted on the loader). Is that not what we > > mean by the RFH having committed? > > > > But this comment was removed anyway. > > In the current code path this function is called before the navigation has even > started. The navigation can only start when the BeforeUnload ack has been > received, which is what the function simulates. Acknowledged. What I said before was wrong... https://codereview.chromium.org/701953006/diff/550001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/550001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:80: TestRenderFrameHost* GetSpeculativeRenderFrameHost( On 2014/12/29 17:36:22, clamy wrote: > I don't think this method should take a RenderFrameHost as an argument. Instead > it should take a RenderFrameHostManager or a FrameTreeNode. They both exist on a > per-frame basis, as opposed to a per WebContents-basis, and make more sense > here. Done. https://codereview.chromium.org/701953006/diff/550001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:316: DidRenderFrameHostCommit(GetSpeculativeRenderFrameHost(main_test_rfh()))); On 2014/12/29 17:36:21, clamy wrote: > I think you could assign a variable to GetSpeculativeRenderFrameHost when it is > not supposed to vary, instead of calling the function several times. Same > comment in the tests below. Done. I made the change here and in other tests as well, where it made sense due to having many repetitive calls to GetSpeculativeRenderFrameHost while it was not being updated. https://codereview.chromium.org/701953006/diff/550001/content/test/test_web_c... File content/test/test_web_contents.cc (right): https://codereview.chromium.org/701953006/diff/550001/content/test/test_web_c... content/test/test_web_contents.cc:176: if (!GetPendingMainFrame() || On 2014/12/29 17:36:22, clamy wrote: > This return is no longer necessary, as following the unit test helper functions > refactoring we should no longer be calling this in PlzNavigate unit tests. Done. https://codereview.chromium.org/701953006/diff/550001/content/test/test_web_c... File content/test/test_web_contents.h (right): https://codereview.chromium.org/701953006/diff/550001/content/test/test_web_c... content/test/test_web_contents.h:122: TestRenderFrameHost* GetSpeculativeMainFrame() const; On 2014/12/29 17:36:22, clamy wrote: > This method is currently private and used exactly one time in > test_web_contents.cc and one line long. Please remove it if it is not going to > be used publicly or make it public if it will be used. Done. https://codereview.chromium.org/701953006/diff/550001/content/test/test_web_c... content/test/test_web_contents.h:128: TestRenderFrameHost* GetFutureMainFrame() const; On 2014/12/29 17:36:22, clamy wrote: > This method should not be private as we expect to use it in several unit tests. > Also please rephrase the comment with a description of what the method does in > the current code path, and then on a new line PlzNavigate: with a description of > what it does in PlzNavigate case. Done. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1395: render_view_host->AllowBindings(future_web_ui->GetBindings()); This is the fix I mentioned in another comment. Previously it was not considering the existence of the speculative WebUI. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:383: RenderFrameHostImpl* SelectFrameHostForNavigation( I renamed GetFrameHostForNavigation to SelectFrameHostForNavigation as the former gave the wrong impression it was just a getter, when in fact it does way more than that.
Thanks! I think we have the logic right in place, so a lot of comments but minor ones and nits. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... File content/browser/frame_host/navigator_impl.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl.cc:827: frame_tree_node->render_manager()->CleanUpNavigation(); Could you add a TODO that CleanUpNavigation should be called by the destructor of NavigationRequest? https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:90: static_cast<MockRenderProcessHost*>(rfh->GetProcess()); You can just call process() instead (from RenderViewHostTestHarness). https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:99: // PlzNavigate: Test final state after a complete navigation (to avoid repeating nit: "(to avoid repeating these checks)" may be unnecessary. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:107: main_test_rfh()->GetSiteInstance()->GetSiteURL()); nit: add an extra-line here. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:111: EXPECT_FALSE(GetSpeculativeRenderFrameHost(node)); nit: add an extra line here. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:126: FrameTreeNode* root_node = contents()->GetFrameTree()->root(); nit: this line does not need to be moved. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:137: EXPECT_NE(root_rfhm, subframe_node->render_manager()); This is unnecessary (you are testing FrameTree functionality here, and not navigation behavior). https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:181: if (base::CommandLine::ForCurrentProcess()->HasSwitch( nit: maybe you should precise that this check is different because the subframe navigation has not committed yet. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:306: ASSERT_TRUE(DidRenderFrameHostCommit(speculative_rfh)); I would use an EXPECT_TRUE here. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:354: TestRenderFrameHost* last_speculative_rfh = nit: why is it called last_speculative_rfh if no other speculative rfh was created before? https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:359: contents()->CommitPendingNavigation(); Could you use TestRenderFrameHost::SendNavigate here? https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:423: contents()->CommitPendingNavigation(); Same as above, please use SendNavigate here. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:502: contents()->CommitPendingNavigation(); Same as above, please use SendNavigate. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:567: contents()->CommitPendingNavigation(); Please us SendNavigate here. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:570: // is made active. Maybe rephrase this as Finally, when the navigation has committed in the speculative RenderFrameHost, it is swapped in. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:576: // PlzNavigate: Verify that a previously swapped-out RenderFrameHost is nit: s/swapped-out/swapped out https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:616: contents()->CommitPendingNavigation(); Please use SendNavigate. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... File content/browser/frame_host/render_frame_host_manager.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:609: if (!render_frame_host->is_swapped_out()) I think we discuss that previously in a comment, why do we have that line here? Maybe add a comment to precise? https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:658: const CommonNavigationParams& common_params) { Just wondering, considering that this method is now not doing much, should it still exist, or should we just call SelectFrameHostForNavigation in NavigatorImpl::BeginNavigation? https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:661: nit: remove unnecessary line here. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:673: bool RenderFrameHostManager::CreateSpeculativeRenderFrameHost( nit: This method should be located below CreateRenderFrameHost as per header file ordering. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:745: CHECK(success); This should be a DCHECK (see comment below). https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:750: CHECK(rfh_for_navigation); I would use a DCHECK here instead of a CHECK. CHECKs are normally reserved for security critical issues that require us to crash the complete browser rather than letting it go on. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:1395: render_view_host->AllowBindings(future_web_ui->GetBindings()); On 2014/12/30 15:54:50, carlosk wrote: > This is the fix I mentioned in another comment. Previously it was not > considering the existence of the speculative WebUI. Acknowledged. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... File content/browser/frame_host/render_frame_host_manager.h (right): https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/render_frame_host_manager.h:23: struct FrameHostMsg_BeginNavigation_Params; Remove this forward declaration (see below). https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/render_frame_host_manager.h:377: void BeginNavigation(const FrameHostMsg_BeginNavigation_Params& params, This method should not take a FrameHostMsg_BeginNavigation_Params as a parameter (and it is not doing anything with it anyway). https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/render_frame_host_manager.h:382: // in which the navigation will commit. nit: This method is also called by BeginNavigation so amybe remove the part about the navigation being ready to commit? https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/render_frame_host_manager.h:383: RenderFrameHostImpl* SelectFrameHostForNavigation( On 2014/12/30 15:54:50, carlosk wrote: > I renamed GetFrameHostForNavigation to SelectFrameHostForNavigation as the > former gave the wrong impression it was just a getter, when in fact it does way > more than that. Acknowledged. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/render_frame_host_manager.h:658: // in parallel with it. This is purely an optimization and is not required for nit: remove with it. Add a performance optimization? https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/render_frame_host_manager.h:659: // correct behavior. The created instance might be discarded later on if the nit: s/instance/RenderFrameHost
Indeed mostly nits but there were some pretty useful ones, especially for the tests. Thanks for the more thorough review! Most of them are "done" but there are a few replies with WDYT's and questions. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... File content/browser/frame_host/navigator_impl.cc (right): https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/navigator_impl.cc:827: frame_tree_node->render_manager()->CleanUpNavigation(); On 2014/12/30 16:57:45, clamy wrote: > Could you add a TODO that CleanUpNavigation should be called by the destructor > of NavigationRequest? Done. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:90: static_cast<MockRenderProcessHost*>(rfh->GetProcess()); On 2014/12/30 16:57:45, clamy wrote: > You can just call process() instead (from RenderViewHostTestHarness). I can't. For this check to work I need the mock process associated with the specific RFH that was passed in which is not necessarily the main frame one. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:99: // PlzNavigate: Test final state after a complete navigation (to avoid repeating On 2014/12/30 16:57:45, clamy wrote: > nit: "(to avoid repeating these checks)" may be unnecessary. I'd prefer to leave that note to indicate to future test implementors that they should not repeat these checks. Sound reasonable? I also tried to make it clearer: "to avoid repeating these checks in other tests". https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:107: main_test_rfh()->GetSiteInstance()->GetSiteURL()); On 2014/12/30 16:57:45, clamy wrote: > nit: add an extra-line here. Done. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:111: EXPECT_FALSE(GetSpeculativeRenderFrameHost(node)); On 2014/12/30 16:57:45, clamy wrote: > nit: add an extra line here. Done. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:126: FrameTreeNode* root_node = contents()->GetFrameTree()->root(); On 2014/12/30 16:57:45, clamy wrote: > nit: this line does not need to be moved. Done. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:137: EXPECT_NE(root_rfhm, subframe_node->render_manager()); On 2014/12/30 16:57:45, clamy wrote: > This is unnecessary (you are testing FrameTree functionality here, and not > navigation behavior). Done. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:181: if (base::CommandLine::ForCurrentProcess()->HasSwitch( On 2014/12/30 16:57:46, clamy wrote: > nit: maybe you should precise that this check is different because the subframe > navigation has not committed yet. Done. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:306: ASSERT_TRUE(DidRenderFrameHostCommit(speculative_rfh)); On 2014/12/30 16:57:45, clamy wrote: > I would use an EXPECT_TRUE here. Done. This reminded me to add that similar commit-checks to other tests where we need to know the RFH that actually committed. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:354: TestRenderFrameHost* last_speculative_rfh = On 2014/12/30 16:57:45, clamy wrote: > nit: why is it called last_speculative_rfh if no other speculative rfh was > created before? Because this will not be the case for much longer... Once we get redirects to update the speculative RFH. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:359: contents()->CommitPendingNavigation(); On 2014/12/30 16:57:46, clamy wrote: > Could you use TestRenderFrameHost::SendNavigate here? Done here and for the following cases. And now more surely as we're checking fort the RFH that actually committed. But I'm in doubt about the page_id value: do redirects under the same site increase its value? I assumed not so left the value here at 0 as it's the 1st time it's being committed to |kUrl2|. I used this same rationale for the following cases. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:423: contents()->CommitPendingNavigation(); On 2014/12/30 16:57:45, clamy wrote: > Same as above, please use SendNavigate here. Done. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:502: contents()->CommitPendingNavigation(); On 2014/12/30 16:57:45, clamy wrote: > Same as above, please use SendNavigate. Done. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:567: contents()->CommitPendingNavigation(); On 2014/12/30 16:57:46, clamy wrote: > Please us SendNavigate here. Done. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:570: // is made active. On 2014/12/30 16:57:45, clamy wrote: > Maybe rephrase this as Finally, when the navigation has committed in the > speculative RenderFrameHost, it is swapped in. This doesn't sound very accurate either as the RFH did commit in the previous step (before SendNavigate). So I made it: Checks that the speculative RenderFrameHost was swapped in. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:576: // PlzNavigate: Verify that a previously swapped-out RenderFrameHost is On 2014/12/30 16:57:45, clamy wrote: > nit: s/swapped-out/swapped out Done. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:616: contents()->CommitPendingNavigation(); On 2014/12/30 16:57:45, clamy wrote: > Please use SendNavigate. Done. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:609: if (!render_frame_host->is_swapped_out()) On 2014/12/30 16:57:46, clamy wrote: > I think we discuss that previously in a comment, why do we have that line here? > Maybe add a comment to precise? Added comment. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:658: const CommonNavigationParams& common_params) { On 2014/12/30 16:57:46, clamy wrote: > Just wondering, considering that this method is now not doing much, should it > still exist, or should we just call SelectFrameHostForNavigation in > NavigatorImpl::BeginNavigation? For now it needs to exist because of the CleanUpNavigation call that follows. Once we sort out navigation cancellation and this call is made from the NavigationRequest destructor, it should be possible to replace this call with SelectFrameHostForNavigation. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:661: On 2014/12/30 16:57:46, clamy wrote: > nit: remove unnecessary line here. Done. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:673: bool RenderFrameHostManager::CreateSpeculativeRenderFrameHost( On 2014/12/30 16:57:46, clamy wrote: > nit: This method should be located below CreateRenderFrameHost as per header > file ordering. Done. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:745: CHECK(success); On 2014/12/30 16:57:46, clamy wrote: > This should be a DCHECK (see comment below). Done. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:750: CHECK(rfh_for_navigation); On 2014/12/30 16:57:46, clamy wrote: > I would use a DCHECK here instead of a CHECK. CHECKs are normally reserved for > security critical issues that require us to crash the complete browser rather > than letting it go on. I think it's better to use CHECK here because this pointer is dereferenced in the following if clause. Will we get a decent stack trace if it's a nullptr there? https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:23: struct FrameHostMsg_BeginNavigation_Params; On 2014/12/30 16:57:46, clamy wrote: > Remove this forward declaration (see below). Done. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:377: void BeginNavigation(const FrameHostMsg_BeginNavigation_Params& params, On 2014/12/30 16:57:46, clamy wrote: > This method should not take a FrameHostMsg_BeginNavigation_Params as a parameter > (and it is not doing anything with it anyway). Done. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:382: // in which the navigation will commit. On 2014/12/30 16:57:46, clamy wrote: > nit: This method is also called by BeginNavigation so amybe remove the part > about the navigation being ready to commit? Updated the comment. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:658: // in parallel with it. This is purely an optimization and is not required for On 2014/12/30 16:57:46, clamy wrote: > nit: remove with it. Add a performance optimization? Done. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:659: // correct behavior. The created instance might be discarded later on if the On 2014/12/30 16:57:46, clamy wrote: > nit: s/instance/RenderFrameHost Done.
Thanks! Lgtm with a few nits. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:90: static_cast<MockRenderProcessHost*>(rfh->GetProcess()); On 2014/12/31 13:39:18, carlosk wrote: > On 2014/12/30 16:57:45, clamy wrote: > > You can just call process() instead (from RenderViewHostTestHarness). > > I can't. For this check to work I need the mock process associated with the > specific RFH that was passed in which is not necessarily the main frame one. Acknowledged. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:99: // PlzNavigate: Test final state after a complete navigation (to avoid repeating On 2014/12/31 13:39:18, carlosk wrote: > On 2014/12/30 16:57:45, clamy wrote: > > nit: "(to avoid repeating these checks)" may be unnecessary. > > I'd prefer to leave that note to indicate to future test implementors that they > should not repeat these checks. Sound reasonable? > > I also tried to make it clearer: "to avoid repeating these checks in other > tests". Acknowledged. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:354: TestRenderFrameHost* last_speculative_rfh = On 2014/12/31 13:39:19, carlosk wrote: > On 2014/12/30 16:57:45, clamy wrote: > > nit: why is it called last_speculative_rfh if no other speculative rfh was > > created before? > > Because this will not be the case for much longer... Once we get redirects to > update the speculative RFH. nit: Then could it be called final_speculative_rfh - that works whether we have one or several. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:359: contents()->CommitPendingNavigation(); On 2014/12/31 13:39:18, carlosk wrote: > On 2014/12/30 16:57:46, clamy wrote: > > Could you use TestRenderFrameHost::SendNavigate here? > > Done here and for the following cases. And now more surely as we're checking > fort the RFH that actually committed. > > But I'm in doubt about the page_id value: do redirects under the same site > increase its value? I assumed not so left the value here at 0 as it's the 1st > time it's being committed to |kUrl2|. I used this same rationale for the > following cases. Yes the value should not be modified by redirects (only the commit of a new navigation permanently increases the max value). https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:570: // is made active. On 2014/12/31 13:39:18, carlosk wrote: > On 2014/12/30 16:57:45, clamy wrote: > > Maybe rephrase this as Finally, when the navigation has committed in the > > speculative RenderFrameHost, it is swapped in. > > This doesn't sound very accurate either as the RFH did commit in the previous > step (before SendNavigate). So I made it: > > Checks that the speculative RenderFrameHost was swapped in. It depends on how you define commit. Currently, it means the renderer requested the main resource, has begun receiving its body and informed the browser (through the DidCommitProvisionalLoad IPC). Therefore the function called CommitNavigation in NavigatorImpl is meant as find a renderer that will commit the navigation and have it commit it, and not this is the commit step. Hence why the test helper function that does those steps is called PrepareForCommit, the actual commit being done by SendNavigate. nit: s/Checks/Check - other than that I'm fine with the comment. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... File content/browser/frame_host/render_frame_host_manager.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:658: const CommonNavigationParams& common_params) { On 2014/12/31 13:39:19, carlosk wrote: > On 2014/12/30 16:57:46, clamy wrote: > > Just wondering, considering that this method is now not doing much, should it > > still exist, or should we just call SelectFrameHostForNavigation in > > NavigatorImpl::BeginNavigation? > > For now it needs to exist because of the CleanUpNavigation call that follows. > Once we sort out navigation cancellation and this call is made from the > NavigationRequest destructor, it should be possible to replace this call with > SelectFrameHostForNavigation. Acknowledged. https://chromiumcodereview.appspot.com/701953006/diff/610001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:750: CHECK(rfh_for_navigation); On 2014/12/31 13:39:19, carlosk wrote: > On 2014/12/30 16:57:46, clamy wrote: > > I would use a DCHECK here instead of a CHECK. CHECKs are normally reserved for > > security critical issues that require us to crash the complete browser rather > > than letting it go on. > > I think it's better to use CHECK here because this pointer is dereferenced in > the following if clause. Will we get a decent stack trace if it's a nullptr > there? Yes. You don't generally check a pointer you just assigned, because the browser will crash anyway if you dereference it. CHECK is meant for a boolean condition that requires the browser or the renderer to crash if not verified. So you could check that a member pointer of a class is not nullptr if a function absolutely requires (ie it makes no sense that the function would ever be called with this pointer set to null). It makes sense to DCHECK it though here, since then you would get the line that crashes right away on a debug build. https://chromiumcodereview.appspot.com/701953006/diff/630001/content/browser/... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/630001/content/browser/... content/browser/frame_host/navigator_impl_unittest.cc:616: // should be reused. nit: s/swapped-out/swapped out https://chromiumcodereview.appspot.com/701953006/diff/630001/content/browser/... File content/browser/frame_host/render_frame_host_manager.cc (right): https://chromiumcodereview.appspot.com/701953006/diff/630001/content/browser/... content/browser/frame_host/render_frame_host_manager.cc:609: // As we might be discarding a RenderFrameHost that is already swapped out, nit: Please reformulate the comment to avoid using we. https://chromiumcodereview.appspot.com/701953006/diff/630001/content/browser/... File content/browser/frame_host/render_frame_host_manager.h (right): https://chromiumcodereview.appspot.com/701953006/diff/630001/content/browser/... content/browser/frame_host/render_frame_host_manager.h:379: // Called (possibly many times) during a navigation to select and appropriate nit: s/many/several s/and/an
Thanks again; all done! https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:354: TestRenderFrameHost* last_speculative_rfh = On 2014/12/31 14:07:09, clamy wrote: > On 2014/12/31 13:39:19, carlosk wrote: > > On 2014/12/30 16:57:45, clamy wrote: > > > nit: why is it called last_speculative_rfh if no other speculative rfh was > > > created before? > > > > Because this will not be the case for much longer... Once we get redirects to > > update the speculative RFH. > > nit: Then could it be called final_speculative_rfh - that works whether we have > one or several. Done. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:359: contents()->CommitPendingNavigation(); On 2014/12/31 14:07:09, clamy wrote: > On 2014/12/31 13:39:18, carlosk wrote: > > On 2014/12/30 16:57:46, clamy wrote: > > > Could you use TestRenderFrameHost::SendNavigate here? > > > > Done here and for the following cases. And now more surely as we're checking > > fort the RFH that actually committed. > > > > But I'm in doubt about the page_id value: do redirects under the same site > > increase its value? I assumed not so left the value here at 0 as it's the 1st > > time it's being committed to |kUrl2|. I used this same rationale for the > > following cases. > > Yes the value should not be modified by redirects (only the commit of a new > navigation permanently increases the max value). Acknowledged. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:570: // is made active. On 2014/12/31 14:07:09, clamy wrote: > On 2014/12/31 13:39:18, carlosk wrote: > > On 2014/12/30 16:57:45, clamy wrote: > > > Maybe rephrase this as Finally, when the navigation has committed in the > > > speculative RenderFrameHost, it is swapped in. > > > > This doesn't sound very accurate either as the RFH did commit in the previous > > step (before SendNavigate). So I made it: > > > > Checks that the speculative RenderFrameHost was swapped in. > > It depends on how you define commit. Currently, it means the renderer requested > the main resource, has begun receiving its body and informed the browser > (through the DidCommitProvisionalLoad IPC). Therefore the function called > CommitNavigation in NavigatorImpl is meant as find a renderer that will commit > the navigation and have it commit it, and not this is the commit step. Hence why > the test helper function that does those steps is called PrepareForCommit, the > actual commit being done by SendNavigate. > > nit: s/Checks/Check - other than that I'm fine with the comment. Done. https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/610001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:750: CHECK(rfh_for_navigation); On 2014/12/31 14:07:09, clamy wrote: > On 2014/12/31 13:39:19, carlosk wrote: > > On 2014/12/30 16:57:46, clamy wrote: > > > I would use a DCHECK here instead of a CHECK. CHECKs are normally reserved > for > > > security critical issues that require us to crash the complete browser > rather > > > than letting it go on. > > > > I think it's better to use CHECK here because this pointer is dereferenced in > > the following if clause. Will we get a decent stack trace if it's a nullptr > > there? > > Yes. You don't generally check a pointer you just assigned, because the browser > will crash anyway if you dereference it. CHECK is meant for a boolean condition > that requires the browser or the renderer to crash if not verified. So you could > check that a member pointer of a class is not nullptr if a function absolutely > requires (ie it makes no sense that the function would ever be called with this > pointer set to null). > It makes sense to DCHECK it though here, since then you would get the line that > crashes right away on a debug build. Acknowledged and done. https://codereview.chromium.org/701953006/diff/630001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/630001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:616: // should be reused. On 2014/12/31 14:07:09, clamy wrote: > nit: s/swapped-out/swapped out Done. https://codereview.chromium.org/701953006/diff/630001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/630001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:609: // As we might be discarding a RenderFrameHost that is already swapped out, On 2014/12/31 14:07:09, clamy wrote: > nit: Please reformulate the comment to avoid using we. Done. https://codereview.chromium.org/701953006/diff/630001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/630001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:379: // Called (possibly many times) during a navigation to select and appropriate On 2014/12/31 14:07:09, clamy wrote: > nit: s/many/several > s/and/an Done.
I have few more changes to review in navigator_impl_unittest.cc, but this should be a good start. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (left): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:167: SendRequestNavigation(node, kUrl2); Why move away from this method? I like the fact that it stays a bit higher level and matches the flow of IPCs. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:213: EXPECT_EQ(RenderFrameHostImpl::STATE_DEFAULT, rfh->rfh_state()); Any reason for removing this check? https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:87: // Note: user must call ClearMessages on the sink before the commit happens. nit: s/user/caller/ https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:91: const FrameMsg_CommitNavigation* commitMessage = Don't use camelCase for variables, use hacker_case. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:115: EXPECT_FALSE(node->render_manager()->pending_frame_host()); This feels like a useless check. Pending RFH is always cleared on Commit. Such a check belongs after starting the navigation, but before it is committed. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:182: // The above situation regarding subframe navigations is valid here. This seems invalid, since top-level navigation will replace the top-level document and the subframes will no longer exist. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:318: ASSERT_TRUE(final_rfh); EXPECT_EQ(speculative_rfh, final_rfh)? https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_impl.cc (right): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_impl.cc:1405: // completing a RFH swap or unload handler. Can you give an example of what this case is? I can see only one legal state transition - STATE_SWAPPED_OUT to STATE_DEFAULT. If this is the case, we should CHECK the expectation here. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:682: // TODO(carlosk): Replace the default values with the right ones for nit: empty line before the TODO https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:727: } Don't we need to initialize the RenderFrame if it isn't live as well? https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:729: DCHECK(new_instance->GetProcess()->HasConnection()); What's the goal of this DCHECK? https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:749: speculative_render_frame_host_->GetProcess()->RemovePendingView(); What codepath does AddPendingView on the speculative RFH? https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1240: if (!new_render_frame_host) { nit: no {} needed for one liners. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1242: } Is there a specific reason why we don't call InitRenderFrame on the new RFH? https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1243: speculative_render_frame_host_.reset(new_render_frame_host.release()); Why not new_render_frame_host.Pass() instead of new_render_frame_host.release()? https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (left): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:372: RenderFrameHostImpl* GetFrameHostForNavigation(const GURL& url, Why renaming from Get to Select? Select implies returning an existing item, whereas this method will create one if needed. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:295: bool was_within_same_page); Why is this parameter added? It isn't used anywhere and all calls pass false to it. Let's not add it in this CL as it is irrelevant. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:375: // create a new renderer process if needed. nit: s/a new renderer process/a new RenderFrameHost (and potentially a new process)/ https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:379: // Called (possibly several times) during a navigation to select an Do we really expect this to be called more than twice? Once at the beginning and once when we are ready to commit. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:386: // Cancels any state for any ongoing navigation. nit: State cannot be cancelled, it can be cleaned up or invalidated. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:504: // navigation is redirected to a different site. nit: s/site/SiteInstance/ https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:655: // created early in a navigation so the renderer process can be started in nit: s/the renderer process/a renderer process/ s/in parallel/in parallel, if needed/ https://codereview.chromium.org/701953006/diff/650001/content/test/test_web_c... File content/test/test_web_contents.h (right): https://codereview.chromium.org/701953006/diff/650001/content/test/test_web_c... content/test/test_web_contents.h:97: // Returns the same result as a call to GetPendingMainFrame. nit: If it returns the same result, then we don't need it, do we? Let's add something like " when running in regular mode." https://codereview.chromium.org/701953006/diff/650001/content/test/test_web_c... content/test/test_web_contents.h:101: TestRenderFrameHost* GetFutureMainFrame() const; nit: I'm not a big fan of "Future" as it implies some sort of promise this will be the RFH. Sadly I don't have a much better suggestion either :(. "Potential" is arguably worse.
Thanks and PTAL at the replies. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (left): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:167: SendRequestNavigation(node, kUrl2); On 2015/01/06 00:03:17, nasko wrote: > Why move away from this method? I like the fact that it stays a bit higher level > and matches the flow of IPCs. The problem was that calling SendRequestNavigation doesn't set the NavigationEntry with the NavigationController, causing a DCHECK in TestWebContents::CommitPendingNavigation to fail. But I agree with the higher level thing (hence why I had previously replaced this and the next call with a helper method) so replaced the single call I had to CommitPendingNavigation with SendNavigate and it's working now. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:213: EXPECT_EQ(RenderFrameHostImpl::STATE_DEFAULT, rfh->rfh_state()); On 2015/01/06 00:03:17, nasko wrote: > Any reason for removing this check? Yes. I moved all the repeating post-navigation checks to NavigationFinishedState (that is the whole reason I created that test). https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:87: // Note: user must call ClearMessages on the sink before the commit happens. On 2015/01/06 00:03:17, nasko wrote: > nit: s/user/caller/ Done. I also updated the whole comment to (hopefully) make it clearer. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:91: const FrameMsg_CommitNavigation* commitMessage = On 2015/01/06 00:03:17, nasko wrote: > Don't use camelCase for variables, use hacker_case. Done. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:115: EXPECT_FALSE(node->render_manager()->pending_frame_host()); On 2015/01/06 00:03:17, nasko wrote: > This feels like a useless check. Pending RFH is always cleared on Commit. Such a > check belongs after starting the navigation, but before it is committed. That's exactly why this check is here: to confirm that the expectation of it having been cleared is true. The other checks you suggested (during the navigation) are done in SpeculativeRendererWorksBaseCase. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:182: // The above situation regarding subframe navigations is valid here. On 2015/01/06 00:03:17, nasko wrote: > This seems invalid, since top-level navigation will replace the top-level > document and the subframes will no longer exist. That's not the case here because the main frame navigation is not yet at that point. This is just checking that at this point nothing has been changed in the sub frame due to the main frame. I agree it looks counter intuitive though. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:318: ASSERT_TRUE(final_rfh); On 2015/01/06 00:03:17, nasko wrote: > EXPECT_EQ(speculative_rfh, final_rfh)? Done. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_impl.cc (right): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_impl.cc:1405: // completing a RFH swap or unload handler. On 2015/01/06 00:03:17, nasko wrote: > Can you give an example of what this case is? I can see only one legal state > transition - STATE_SWAPPED_OUT to STATE_DEFAULT. If this is the case, we should > CHECK the expectation here. clamy@ just got me through one: if a still-swapping-out RFH (with a slow unload handling) is swapped back in before it finishes unloading it will not be in the SWAPPED_OUT state but in the PENDING_SWAP_OUT instead. In fact this is the case being tested in NavigatorTestWithBrowserSideNavigation::SpeculativeRendererReuseSwappedOutRFH. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:682: // TODO(carlosk): Replace the default values with the right ones for On 2015/01/06 00:03:18, nasko wrote: > nit: empty line before the TODO Done. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:727: } On 2015/01/06 00:03:18, nasko wrote: > Don't we need to initialize the RenderFrame if it isn't live as well? I'm not sure of what you mean. Is that the renderer? I was assuming that was what CreateSpeculativeRenderFrameHost (which is based on the existing RFH creation code) or InitRenderView call chains would do. Or are you maybe referring to the currently active RFH? On this note clamy@ suggested I should add a snippet of code from ::Navigate that brings the current RFH back to life in case it's currently crashed so that we show a blank page instead of the sad one (has a comment that refers to Bug 1145340 which we couldn't find anywhere). https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:729: DCHECK(new_instance->GetProcess()->HasConnection()); On 2015/01/06 00:03:17, nasko wrote: > What's the goal of this DCHECK? I understand this checks for a connection with an existing renderer process. As the main reason of existence of a speculative RFH is to hold a live renderer for an ongoing navigation this DCHECK seems appropriate. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:749: speculative_render_frame_host_->GetProcess()->RemovePendingView(); On 2015/01/06 00:03:17, nasko wrote: > What codepath does AddPendingView on the speculative RFH? CreatePendingRenderFrameHost -> CreateRenderFrame https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1240: if (!new_render_frame_host) { On 2015/01/06 00:03:18, nasko wrote: > nit: no {} needed for one liners. Done. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1242: } On 2015/01/06 00:03:17, nasko wrote: > Is there a specific reason why we don't call InitRenderFrame on the new RFH? That's already done in CreateRenderFrame. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1243: speculative_render_frame_host_.reset(new_render_frame_host.release()); On 2015/01/06 00:03:17, nasko wrote: > Why not new_render_frame_host.Pass() instead of new_render_frame_host.release()? Because there were used with the pending_web_ui and I replicated them. Switched these two to Pass(). https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (left): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:372: RenderFrameHostImpl* GetFrameHostForNavigation(const GURL& url, On 2015/01/06 00:03:18, nasko wrote: > Why renaming from Get to Select? Select implies returning an existing item, > whereas this method will create one if needed. I discussed with clamy@ and this seemed like the best option. "Get" made it look like a getter, which this method is not as it changes internal state. It might create a new one and set is as the speculative. It might simply use the current one. And it returns whichever it chose just to inform the caller. To use "Select" seemed to imply more what you are saying. Other options used "Update" but clamy@ was not fond of it as it seemed as it was just updating an existing one. I have no better options and am open for suggestions... https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:295: bool was_within_same_page); On 2015/01/06 00:03:18, nasko wrote: > Why is this parameter added? It isn't used anywhere and all calls pass false to > it. Let's not add it in this CL as it is irrelevant. clamy@ asked for this to be added to be already in tune with the upcoming changes to cancelling a browser side navigation. It's currently used in a DCHECK in that method and there's a TODO there. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:375: // create a new renderer process if needed. On 2015/01/06 00:03:18, nasko wrote: > nit: s/a new renderer process/a new RenderFrameHost (and potentially a new > process)/ Done. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:379: // Called (possibly several times) during a navigation to select an On 2015/01/06 00:03:18, nasko wrote: > Do we really expect this to be called more than twice? Once at the beginning and > once when we are ready to commit. For every redirect once we begin monitoring them. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:386: // Cancels any state for any ongoing navigation. On 2015/01/06 00:03:18, nasko wrote: > nit: State cannot be cancelled, it can be cleaned up or invalidated. Changed to Clean up. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:504: // navigation is redirected to a different site. On 2015/01/06 00:03:18, nasko wrote: > nit: s/site/SiteInstance/ Done. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:655: // created early in a navigation so the renderer process can be started in On 2015/01/06 00:03:18, nasko wrote: > nit: s/the renderer process/a renderer process/ > s/in parallel/in parallel, if needed/ Done. https://codereview.chromium.org/701953006/diff/650001/content/test/test_web_c... File content/test/test_web_contents.h (right): https://codereview.chromium.org/701953006/diff/650001/content/test/test_web_c... content/test/test_web_contents.h:97: // Returns the same result as a call to GetPendingMainFrame. On 2015/01/06 00:03:18, nasko wrote: > nit: If it returns the same result, then we don't need it, do we? Let's add > something like " when running in regular mode." Updated the comment in that sense. https://codereview.chromium.org/701953006/diff/650001/content/test/test_web_c... content/test/test_web_contents.h:101: TestRenderFrameHost* GetFutureMainFrame() const; On 2015/01/06 00:03:18, nasko wrote: > nit: I'm not a big fan of "Future" as it implies some sort of promise this will > be the RFH. Sadly I don't have a much better suggestion either :(. "Potential" > is arguably worse. Well then... :) I changed it to GetNextMainFrameCandidate that I hope is better.
Patchset #26 (id:690001) has been deleted
https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:87: // Note: user must call ClearMessages on the sink before the commit happens. On 2015/01/08 16:05:55, carlosk wrote: > On 2015/01/06 00:03:17, nasko wrote: > > nit: s/user/caller/ > > Done. I also updated the whole comment to (hopefully) make it clearer. Acknowledged. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:182: // The above situation regarding subframe navigations is valid here. On 2015/01/08 16:05:55, carlosk wrote: > On 2015/01/06 00:03:17, nasko wrote: > > This seems invalid, since top-level navigation will replace the top-level > > document and the subframes will no longer exist. > > That's not the case here because the main frame navigation is not yet at that > point. This is just checking that at this point nothing has been changed in the > sub frame due to the main frame. > > I agree it looks counter intuitive though. Please add a comment saying that the main frame hasn't committed yet, so it is valid to have a subframe. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_impl.cc (right): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_impl.cc:1405: // completing a RFH swap or unload handler. On 2015/01/08 16:05:55, carlosk wrote: > On 2015/01/06 00:03:17, nasko wrote: > > Can you give an example of what this case is? I can see only one legal state > > transition - STATE_SWAPPED_OUT to STATE_DEFAULT. If this is the case, we > should > > CHECK the expectation here. > > clamy@ just got me through one: if a still-swapping-out RFH (with a slow unload > handling) is swapped back in before it finishes unloading it will not be in the > SWAPPED_OUT state but in the PENDING_SWAP_OUT instead. In fact this is the case > being tested in > NavigatorTestWithBrowserSideNavigation::SpeculativeRendererReuseSwappedOutRFH. Acknowledged. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:727: } On 2015/01/08 16:05:55, carlosk wrote: > On 2015/01/06 00:03:18, nasko wrote: > > Don't we need to initialize the RenderFrame if it isn't live as well? > > I'm not sure of what you mean. Is that the renderer? There are two objects - RenderFrameHost, which is browser side and is created by CreateSpeculativeRenderFrameHost, and RenderFrame, which is renderer side and is created by calling InitRenderFrame, which sends an IPC to the renderer. > I was assuming that was > what CreateSpeculativeRenderFrameHost (which is based on the existing RFH > creation code) or InitRenderView call chains would do. No, InitRenderView only initializes a RenderView object. You shouldn't depend on it possibly initializing RenderFrame. CreateSpeculativeRenderFrameHost does indeed init the RenderFrame by calling CreateRenderFrame, which does it. > Or are you maybe referring to the currently active RFH? No, I was referring to the RFH being created here. > On this note clamy@ suggested I should add a snippet of code from ::Navigate > that brings the current RFH back to life in case it's currently crashed so that > we show a blank page instead of the sad one (has a comment that refers to Bug > 1145340 which we couldn't find anywhere). It is a bug from before Chrome was open sourced, so it is in the Google internal database : ). https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:729: DCHECK(new_instance->GetProcess()->HasConnection()); On 2015/01/08 16:05:55, carlosk wrote: > On 2015/01/06 00:03:17, nasko wrote: > > What's the goal of this DCHECK? > > I understand this checks for a connection with an existing renderer process. As > the main reason of existence of a speculative RFH is to hold a live renderer > for an ongoing navigation this DCHECK seems appropriate. Process creation is asynchronous, so you shouldn't rely that it has completed by the time you reach this line. This DCHECK has full potential to fire for no obvious reason. While the ultimate goal is to optimize process creation, it is the wrong thing to ask for right here. Processes are an implementation detail of Chrome's choice how to isolate SiteInstances. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:749: speculative_render_frame_host_->GetProcess()->RemovePendingView(); On 2015/01/08 16:05:55, carlosk wrote: > On 2015/01/06 00:03:17, nasko wrote: > > What codepath does AddPendingView on the speculative RFH? > > CreatePendingRenderFrameHost -> CreateRenderFrame This method doesn't touch the pending RFH and we aren't using pending RFH in PlzNavigate at all. So my question still stands, where is the AddPendingView on the speculative RFH? https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (left): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:372: RenderFrameHostImpl* GetFrameHostForNavigation(const GURL& url, On 2015/01/08 16:05:56, carlosk wrote: > On 2015/01/06 00:03:18, nasko wrote: > > Why renaming from Get to Select? Select implies returning an existing item, > > whereas this method will create one if needed. > > I discussed with clamy@ and this seemed like the best option. "Get" made it look > like a getter, which this method is not as it changes internal state. It might > create a new one and set is as the speculative. It might simply use the current > one. And it returns whichever it chose just to inform the caller. While somewhat true, there is a coding convention in Chrome where accessors are hacker_cased, so it is clear they don't do any extra work. CamelCased methods do extra work or are part of public interface. Since this isn't a public API and there is already a pattern in Chrome that Get* can create the object, I think it is best to leave it unchanged. > To use "Select" seemed to imply more what you are saying. Other options used > "Update" but clamy@ was not fond of it as it seemed as it was just updating an > existing one. > > I have no better options and am open for suggestions... https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:379: // Called (possibly several times) during a navigation to select an On 2015/01/08 16:05:56, carlosk wrote: > On 2015/01/06 00:03:18, nasko wrote: > > Do we really expect this to be called more than twice? Once at the beginning > and > > once when we are ready to commit. > > For every redirect once we begin monitoring them. Why do we need to monitor redirects? We should be creating RFH at the initial request and at commit time, if it doesn't match the original. https://codereview.chromium.org/701953006/diff/650001/content/test/test_web_c... File content/test/test_web_contents.h (right): https://codereview.chromium.org/701953006/diff/650001/content/test/test_web_c... content/test/test_web_contents.h:101: TestRenderFrameHost* GetFutureMainFrame() const; On 2015/01/08 16:05:56, carlosk wrote: > On 2015/01/06 00:03:18, nasko wrote: > > nit: I'm not a big fan of "Future" as it implies some sort of promise this > will > > be the RFH. Sadly I don't have a much better suggestion either :(. "Potential" > > is arguably worse. > > Well then... :) > > I changed it to GetNextMainFrameCandidate that I hope is better. Yes, I like this better! Thanks! https://codereview.chromium.org/701953006/diff/710001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/710001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:703: if (!render_frame_host_->IsRenderFrameLive()) { Don't we need a check here that we are navigating cross-site? The else clause doesn't imply current_instance != new_instance.get().
Thanks once more. Replies and code updates are in. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:182: // The above situation regarding subframe navigations is valid here. On 2015/01/08 23:36:37, nasko wrote: > On 2015/01/08 16:05:55, carlosk wrote: > > On 2015/01/06 00:03:17, nasko wrote: > > > This seems invalid, since top-level navigation will replace the top-level > > > document and the subframes will no longer exist. > > > > That's not the case here because the main frame navigation is not yet at that > > point. This is just checking that at this point nothing has been changed in > the > > sub frame due to the main frame. > > > > I agree it looks counter intuitive though. > > Please add a comment saying that the main frame hasn't committed yet, so it is > valid to have a subframe. Done. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:727: } On 2015/01/08 23:36:37, nasko wrote: > On 2015/01/08 16:05:55, carlosk wrote: > > On 2015/01/06 00:03:18, nasko wrote: > > > Don't we need to initialize the RenderFrame if it isn't live as well? > > > > I'm not sure of what you mean. Is that the renderer? > > There are two objects - RenderFrameHost, which is browser side and is created by > CreateSpeculativeRenderFrameHost, and RenderFrame, which is renderer side and is > created by calling InitRenderFrame, which sends an IPC to the renderer. Yes, thanks for explaining. That's what I was referring to even though I didn't phrase it right. > > I was assuming that was > > what CreateSpeculativeRenderFrameHost (which is based on the existing RFH > > creation code) or InitRenderView call chains would do. > > No, InitRenderView only initializes a RenderView object. You shouldn't depend on > it possibly initializing RenderFrame. CreateSpeculativeRenderFrameHost does > indeed init the RenderFrame by calling CreateRenderFrame, which does it. I understand now. So, looking at the current code the only time *ever* where InitRenderFrame is called is from inside render CreateRenderFrame. As you mentioned this is already called when creating the speculative RFH. So my current best guess for your initial question is that no, we shouldn't initialize the RenderFrame here. WDYT? > > Or are you maybe referring to the currently active RFH? > > No, I was referring to the RFH being created here. Ack. > > On this note clamy@ suggested I should add a snippet of code from ::Navigate > > that brings the current RFH back to life in case it's currently crashed so > that > > we show a blank page instead of the sad one (has a comment that refers to Bug > > 1145340 which we couldn't find anywhere). > > It is a bug from before Chrome was open sourced, so it is in the Google internal > database : ). Ack. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:729: DCHECK(new_instance->GetProcess()->HasConnection()); On 2015/01/08 23:36:37, nasko wrote: > On 2015/01/08 16:05:55, carlosk wrote: > > On 2015/01/06 00:03:17, nasko wrote: > > > What's the goal of this DCHECK? > > > > I understand this checks for a connection with an existing renderer process. > As > > the main reason of existence of a speculative RFH is to hold a live renderer > > for an ongoing navigation this DCHECK seems appropriate. > > Process creation is asynchronous, so you shouldn't rely that it has completed by > the time you reach this line. This DCHECK has full potential to fire for no > obvious reason. > > While the ultimate goal is to optimize process creation, it is the wrong thing > to ask for right here. Processes are an implementation detail of Chrome's choice > how to isolate SiteInstances. It's a check that already happens in this whole process at RenderViewHostImpl::CreateRenderView, line 261. We get to that call through: RFHM::InitRenderView -> WCI::CreateRenderViewForRenderManager -> RVHI::CreateRenderView So it doesn't seem like it's going to fire when it shouldn't but as it's already done it seems OK remove it. WDYT? This makes me think that the actual creation of the process happens synchronously but not it's full initialization. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:749: speculative_render_frame_host_->GetProcess()->RemovePendingView(); On 2015/01/08 23:36:37, nasko wrote: > On 2015/01/08 16:05:55, carlosk wrote: > > On 2015/01/06 00:03:17, nasko wrote: > > > What codepath does AddPendingView on the speculative RFH? > > > > CreatePendingRenderFrameHost -> CreateRenderFrame > > This method doesn't touch the pending RFH and we aren't using pending RFH in > PlzNavigate at all. > So my question still stands, where is the AddPendingView on the speculative RFH? Doh, my bad! I meant to write: CreateSpeculativeRenderFrameHost -> CreateRenderFrame Which is the only way a speculative RFH can be created. And CreateRenderFrame does AddPendingView to the instances it returns. Sorry for the confusion. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (left): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:372: RenderFrameHostImpl* GetFrameHostForNavigation(const GURL& url, On 2015/01/08 23:36:37, nasko wrote: > On 2015/01/08 16:05:56, carlosk wrote: > > On 2015/01/06 00:03:18, nasko wrote: > > > Why renaming from Get to Select? Select implies returning an existing item, > > > whereas this method will create one if needed. > > > > I discussed with clamy@ and this seemed like the best option. "Get" made it > look > > like a getter, which this method is not as it changes internal state. It might > > create a new one and set is as the speculative. It might simply use the > current > > one. And it returns whichever it chose just to inform the caller. > > While somewhat true, there is a coding convention in Chrome where accessors are > hacker_cased, so it is clear they don't do any extra work. CamelCased methods do > extra work or are part of public interface. Since this isn't a public API and > there is already a pattern in Chrome that Get* can create the object, I think it > is best to leave it unchanged. > > > To use "Select" seemed to imply more what you are saying. Other options used > > "Update" but clamy@ was not fond of it as it seemed as it was just updating an > > existing one. > > > > I have no better options and am open for suggestions... Acknowledged. Reverted to "Get". https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:379: // Called (possibly several times) during a navigation to select an On 2015/01/08 23:36:37, nasko wrote: > On 2015/01/08 16:05:56, carlosk wrote: > > On 2015/01/06 00:03:18, nasko wrote: > > > Do we really expect this to be called more than twice? Once at the beginning > > and > > > once when we are ready to commit. > > > > For every redirect once we begin monitoring them. > > Why do we need to monitor redirects? We should be creating RFH at the initial > request and at commit time, if it doesn't match the original. This is a performance improvement change and the earlier we create the renderer the higher the chance it will be ready and waiting for the navigation to commit. So it's preferable to update it upon request and at every redirect as they will happen earlier than the commit. So instead of two updates, on request and commit, we will update on request and on every redirect so that upon commit we already have the appropriate RFH/renderer created. https://codereview.chromium.org/701953006/diff/710001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/710001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:703: if (!render_frame_host_->IsRenderFrameLive()) { On 2015/01/08 23:36:37, nasko wrote: > Don't we need a check here that we are navigating cross-site? The else clause > doesn't imply current_instance != new_instance.get(). We want to to make sure that the current RFH/renderer is alive when starting a navigation. This else clause (line 699) implies that we will NOT reuse the current RFH/renderer so this change should be enough: * If we are reusing the current one (the else at 699 is not run) we will make sure it's fully alive at line 731. * If not we check it here and act on it.
I think this is mostly ready to go from my side. Charlie, can you take a look at the latest patchset? https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:727: } On 2015/01/09 14:48:52, carlosk wrote: > On 2015/01/08 23:36:37, nasko wrote: > > On 2015/01/08 16:05:55, carlosk wrote: > > > On 2015/01/06 00:03:18, nasko wrote: > > > > Don't we need to initialize the RenderFrame if it isn't live as well? > > > > > > I'm not sure of what you mean. Is that the renderer? > > > > There are two objects - RenderFrameHost, which is browser side and is created > by > > CreateSpeculativeRenderFrameHost, and RenderFrame, which is renderer side and > is > > created by calling InitRenderFrame, which sends an IPC to the renderer. > > Yes, thanks for explaining. That's what I was referring to even though I didn't > phrase it right. > > > > I was assuming that was > > > what CreateSpeculativeRenderFrameHost (which is based on the existing RFH > > > creation code) or InitRenderView call chains would do. > > > > No, InitRenderView only initializes a RenderView object. You shouldn't depend > on > > it possibly initializing RenderFrame. CreateSpeculativeRenderFrameHost does > > indeed init the RenderFrame by calling CreateRenderFrame, which does it. > > I understand now. So, looking at the current code the only time *ever* where > InitRenderFrame is called is from inside render CreateRenderFrame. As you > mentioned this is already called when creating the speculative RFH. So my > current best guess for your initial question is that no, we shouldn't initialize > the RenderFrame here. > > WDYT? > > > > Or are you maybe referring to the currently active RFH? > > > > No, I was referring to the RFH being created here. > > Ack. > > > > On this note clamy@ suggested I should add a snippet of code from ::Navigate > > > that brings the current RFH back to life in case it's currently crashed so > > that > > > we show a blank page instead of the sad one (has a comment that refers to > Bug > > > 1145340 which we couldn't find anywhere). > > > > It is a bug from before Chrome was open sourced, so it is in the Google > internal > > database : ). > > Ack. No need to do anything extra here. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:729: DCHECK(new_instance->GetProcess()->HasConnection()); On 2015/01/09 14:48:52, carlosk wrote: > On 2015/01/08 23:36:37, nasko wrote: > > On 2015/01/08 16:05:55, carlosk wrote: > > > On 2015/01/06 00:03:17, nasko wrote: > > > > What's the goal of this DCHECK? > > > > > > I understand this checks for a connection with an existing renderer process. > > As > > > the main reason of existence of a speculative RFH is to hold a live > renderer > > > for an ongoing navigation this DCHECK seems appropriate. > > > > Process creation is asynchronous, so you shouldn't rely that it has completed > by > > the time you reach this line. This DCHECK has full potential to fire for no > > obvious reason. > > > > While the ultimate goal is to optimize process creation, it is the wrong thing > > to ask for right here. Processes are an implementation detail of Chrome's > choice > > how to isolate SiteInstances. > > It's a check that already happens in this whole process at > RenderViewHostImpl::CreateRenderView, line 261. We get to that call through: > > RFHM::InitRenderView -> WCI::CreateRenderViewForRenderManager -> > RVHI::CreateRenderView > > So it doesn't seem like it's going to fire when it shouldn't but as it's already > done it seems OK remove it. WDYT? If it is already done, then why keep it here? The code in CreateRenderView explicitly calls GetProcess()->Init(), so it checks that this has succeeded. > This makes me think that the actual creation of the process happens > synchronously but not it's full initialization. Process creation is asynchronous, otherwise we would be blocking the UI thread for the duration of it. After digging in code, I realized that the HasConnection() only checks browser-side existence of IPC channel, not that it is actually setup and ready. Logically, this DCHECK doesn't seem to fit with the spirit of the code in this method, so please remove it. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:749: speculative_render_frame_host_->GetProcess()->RemovePendingView(); On 2015/01/09 14:48:51, carlosk wrote: > On 2015/01/08 23:36:37, nasko wrote: > > On 2015/01/08 16:05:55, carlosk wrote: > > > On 2015/01/06 00:03:17, nasko wrote: > > > > What codepath does AddPendingView on the speculative RFH? > > > > > > CreatePendingRenderFrameHost -> CreateRenderFrame > > > > This method doesn't touch the pending RFH and we aren't using pending RFH in > > PlzNavigate at all. > > So my question still stands, where is the AddPendingView on the speculative > RFH? > > Doh, my bad! I meant to write: > > CreateSpeculativeRenderFrameHost -> CreateRenderFrame > > Which is the only way a speculative RFH can be created. And CreateRenderFrame > does AddPendingView to the instances it returns. > > Sorry for the confusion. Ah, that clarifies it. Thanks. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:295: bool was_within_same_page); On 2015/01/08 16:05:56, carlosk wrote: > On 2015/01/06 00:03:18, nasko wrote: > > Why is this parameter added? It isn't used anywhere and all calls pass false > to > > it. Let's not add it in this CL as it is irrelevant. > > clamy@ asked for this to be added to be already in tune with the upcoming > changes to cancelling a browser side navigation. It's currently used in a DCHECK > in that method and there's a TODO there. In general, we don't add code that isn't used in a CL, just because it might be used in the future. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:379: // Called (possibly several times) during a navigation to select an On 2015/01/09 14:48:52, carlosk wrote: > On 2015/01/08 23:36:37, nasko wrote: > > On 2015/01/08 16:05:56, carlosk wrote: > > > On 2015/01/06 00:03:18, nasko wrote: > > > > Do we really expect this to be called more than twice? Once at the > beginning > > > and > > > > once when we are ready to commit. > > > > > > For every redirect once we begin monitoring them. > > > > Why do we need to monitor redirects? We should be creating RFH at the initial > > request and at commit time, if it doesn't match the original. > > This is a performance improvement change and the earlier we create the renderer > the higher the chance it will be ready and waiting for the navigation to commit. > So it's preferable to update it upon request and at every redirect as they will > happen earlier than the commit. I'm sorry, but I do not agree with this. While it is indeed a performance improvement change, it is an optimization change too. The amount of work needed to tear down and spin up RFHs on redirects might negate whatever optimizations we aim to achieve. Also, there is cost in complexity of the codebase and potential for bugs. Based on these, I don't believe we should be creating speculative RFHs on redirects. > So instead of two updates, on request and commit, we will update on request and > on every redirect so that upon commit we already have the appropriate > RFH/renderer created. Unless we have hard data showing that this will buy is a tremendous performance improvement in real world browsing, I don't agree we should be doing it. https://codereview.chromium.org/701953006/diff/710001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/710001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:703: if (!render_frame_host_->IsRenderFrameLive()) { On 2015/01/09 14:48:52, carlosk wrote: > On 2015/01/08 23:36:37, nasko wrote: > > Don't we need a check here that we are navigating cross-site? The else clause > > doesn't imply current_instance != new_instance.get(). > > We want to to make sure that the current RFH/renderer is alive when starting a > navigation. This else clause (line 699) implies that we will NOT reuse the > current RFH/renderer so this change should be enough: > > * If we are reusing the current one (the else at 699 is not run) we will make > sure it's fully alive at line 731. > * If not we check it here and act on it. While the reasoning overall is correct, this code relies on many assumptions that might change in the future, which makes it more fragile. Since as is, it does seem to do the right thing, I'd say leave it as is and we'll take another look as both PlzNavigate and Site Isolation progress further.
Thanks. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:729: DCHECK(new_instance->GetProcess()->HasConnection()); On 2015/01/09 18:13:07, nasko wrote: > On 2015/01/09 14:48:52, carlosk wrote: > > On 2015/01/08 23:36:37, nasko wrote: > > > On 2015/01/08 16:05:55, carlosk wrote: > > > > On 2015/01/06 00:03:17, nasko wrote: > > > > > What's the goal of this DCHECK? > > > > > > > > I understand this checks for a connection with an existing renderer > process. > > > As > > > > the main reason of existence of a speculative RFH is to hold a live > > renderer > > > > for an ongoing navigation this DCHECK seems appropriate. > > > > > > Process creation is asynchronous, so you shouldn't rely that it has > completed > > by > > > the time you reach this line. This DCHECK has full potential to fire for no > > > obvious reason. > > > > > > While the ultimate goal is to optimize process creation, it is the wrong > thing > > > to ask for right here. Processes are an implementation detail of Chrome's > > choice > > > how to isolate SiteInstances. > > > > It's a check that already happens in this whole process at > > RenderViewHostImpl::CreateRenderView, line 261. We get to that call through: > > > > RFHM::InitRenderView -> WCI::CreateRenderViewForRenderManager -> > > RVHI::CreateRenderView > > > > So it doesn't seem like it's going to fire when it shouldn't but as it's > already > > done it seems OK remove it. WDYT? > > If it is already done, then why keep it here? The code in CreateRenderView > explicitly calls GetProcess()->Init(), so it checks that this has succeeded. > > > This makes me think that the actual creation of the process happens > > synchronously but not it's full initialization. > > Process creation is asynchronous, otherwise we would be blocking the UI thread > for the duration of it. > After digging in code, I realized that the HasConnection() only checks > browser-side existence of IPC channel, not that it is actually setup and ready. > > Logically, this DCHECK doesn't seem to fit with the spirit of the code in this > method, so please remove it. Ack and done. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:295: bool was_within_same_page); On 2015/01/09 18:13:07, nasko wrote: > On 2015/01/08 16:05:56, carlosk wrote: > > On 2015/01/06 00:03:18, nasko wrote: > > > Why is this parameter added? It isn't used anywhere and all calls pass false > > to > > > it. Let's not add it in this CL as it is irrelevant. > > > > clamy@ asked for this to be added to be already in tune with the upcoming > > changes to cancelling a browser side navigation. It's currently used in a > DCHECK > > in that method and there's a TODO there. > > In general, we don't add code that isn't used in a CL, just because it might be > used in the future. Talked to clamy@ and we agreed to revert it. https://codereview.chromium.org/701953006/diff/650001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:379: // Called (possibly several times) during a navigation to select an On 2015/01/09 18:13:07, nasko wrote: > On 2015/01/09 14:48:52, carlosk wrote: > > On 2015/01/08 23:36:37, nasko wrote: > > > On 2015/01/08 16:05:56, carlosk wrote: > > > > On 2015/01/06 00:03:18, nasko wrote: > > > > > Do we really expect this to be called more than twice? Once at the > > beginning > > > > and > > > > > once when we are ready to commit. > > > > > > > > For every redirect once we begin monitoring them. > > > > > > Why do we need to monitor redirects? We should be creating RFH at the > initial > > > request and at commit time, if it doesn't match the original. > > > > This is a performance improvement change and the earlier we create the > renderer > > the higher the chance it will be ready and waiting for the navigation to > commit. > > So it's preferable to update it upon request and at every redirect as they > will > > happen earlier than the commit. > > I'm sorry, but I do not agree with this. While it is indeed a performance > improvement change, it is an optimization change too. The amount of work needed > to tear down and spin up RFHs on redirects might negate whatever optimizations > we aim to achieve. > Also, there is cost in complexity of the codebase and potential for bugs. > Based on these, I don't believe we should be creating speculative RFHs on > redirects. > > > So instead of two updates, on request and commit, we will update on request > and > > on every redirect so that upon commit we already have the appropriate > > RFH/renderer created. > > Unless we have hard data showing that this will buy is a tremendous performance > improvement in real world browsing, I don't agree we should be doing it. I agree that backing this with data is the right thing to do so that's what we'll do once we get there. https://codereview.chromium.org/701953006/diff/710001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/710001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:703: if (!render_frame_host_->IsRenderFrameLive()) { On 2015/01/09 18:13:07, nasko wrote: > On 2015/01/09 14:48:52, carlosk wrote: > > On 2015/01/08 23:36:37, nasko wrote: > > > Don't we need a check here that we are navigating cross-site? The else > clause > > > doesn't imply current_instance != new_instance.get(). > > > > We want to to make sure that the current RFH/renderer is alive when starting a > > navigation. This else clause (line 699) implies that we will NOT reuse the > > current RFH/renderer so this change should be enough: > > > > * If we are reusing the current one (the else at 699 is not run) we will make > > sure it's fully alive at line 731. > > * If not we check it here and act on it. > > While the reasoning overall is correct, this code relies on many assumptions > that might change in the future, which makes it more fragile. > Since as is, it does seem to do the right thing, I'd say leave it as is and > we'll take another look as both PlzNavigate and Site Isolation progress further. Acknowledged.
Looks like you all made a lot of progress! Most of my comments are simple nits, so I'm pretty happy with this. I expect it will be ready after another round. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:273: EXPECT_FALSE(GetSpeculativeRenderFrameHost(rfhm)); On 2014/12/16 01:53:47, carlosk wrote: > On 2014/12/10 22:37:44, Charlie Reis wrote: > > On 2014/12/09 07:55:41, carlosk wrote: > > > On 2014/12/04 01:11:30, Charlie Reis wrote: > > > > Why is there no speculative RFH after it redirects cross site? Is that > > > planned > > > > for later? (Seems like we might as well create one while we're waiting > for > > > the > > > > new response.) > > > > > > > > If we're not planning to create one in this CL, then a TODO here might be > > > > worthwhile. > > > > > > Indeed that is a task for later on. The idea is to monitor redirects --- > that > > > now are conveniently tracked at the browser side -- to update the > speculative > > > RFH accordingly. But we have to be careful with this as we'll possibly be > > > creating quite some churn by creating and destroying RFH in bursts. > > > > Later is fine. Worth noting that we wouldn't get a "burst" for multiple > > redirects, at least. We'll get at most two speculative RFHs per navigation > > (once when it starts, and once after all the server redirects are done). > > So if I understand correctly when server redirects happen we only get the final > result? I guess we could still get some more when jumping from one server to the > next? [Just following up on an old thread. This probably doesn't matter anymore.] It was designed so that we don't choose a new process until all the server redirects have finished. There's at most one speculative RFH at the time the navigation is begun, and one more after all the server redirects. However, client redirects are a different story. Those actually commit a real page in a renderer process, and then immediately decide to navigate somewhere else. There could be an arbitrarily long chain of client redirects each requiring a process swap (up to a limit when Chrome says the redirect chain is too long). https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:98: rfh->GetRoutingID() == commit_message->routing_id(); nit: Wrong indent (should be 4 spaces). I'll defer to clang-format if it disagrees. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:109: EXPECT_EQ(SiteInstanceImpl::GetSiteForURL(browser_context(), kUrl), This is a good idea to test, but it's equally important to test the actual URL that commits. Please add a check that contents()->GetLastCommittedURL() is kUrl as well. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:158: // unless site-per-process is enabled. In that case as the subframe navigation nit: Comma after "In that case" https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:185: // As the main frame hasn't yet committed the subframe still exists. So the nit: The second sentence is a sentence fragment. s/So/Thus,/ https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:209: // As we're re-using the current RenderFrameHost, no speculative one should be English nit: "Since" or "Because" would be easier to read here than "As." "As we're..." sounds like the two things are happening at the same time, rather than one because of the other. (Same in the cases above, and apologies for English being such a terribly confusing language!) https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:314: EXPECT_FALSE(DidRenderFrameHostCommit(main_test_rfh())); This is very confusing for those of us familiar with the current navigation flow. Did...Commit sounds like it refers to the time after the renderer process has committed (i.e., DidCommitProvisionalLoad). That would make this impossible-- if the speculative RFH commits, it would become main_test_rfh(), and thus this line couldn't pass. I'm guessing it means something else (i.e., the RFH has *requested* that the renderer process commit the navigation, but it hasn't happened yet). If that's the case, let's rename the method to DidRenderFrameHostRequestCommit. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:358: // Then it commits. This adds to my confusion. The navigation has not committed here. Can you update this comment while you're here? https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:480: // navigating from one site to the another. nit: Drop "the" https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:536: EXPECT_EQ(init_site_instance_id, main_test_rfh()->GetSiteInstance()->GetId()); Please verify that init_site_instance_id and site_instance_id are not the same. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:558: // TODO(carlosk): once the speculative RenderFrameHost updates with redirects I agree with the TODO, but it's hard to follow what the test is doing in the meantime. Above the TODO, please add "For now, ensure that the speculative RFH does not change after the redirect." https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:571: // Once commit happens the speculative RenderFrameHost is already updated to Drop "already," since this seems to be the point in time when the speculative RFH is updated. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:73: if (base::CommandLine::ForCurrentProcess()->HasSwitch( We should probably mimic the case above and check for speculative_render_frame_host_ instead of the switch. (No need for braces.) https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:429: DCHECK(render_frame_host); This seems unnecessary to me, since the callers are all within the navigation logic and it's fairly obvious they won't pass in null. (We don't have DCHECKs in those methods either.) https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:435: // TODO(carlosk): this code doesn't properly handles in-page nor handle nor -> or https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:436: // interweaved navigation requests navigation. I don't know what this means. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:446: if (!cross_navigation_pending_) { Why isn't this block above the one you added? Is cross_navigation_pending_ never set to true in PlzNavigate mode? If not, we should document that in the .h file, since it's checked in a ton of places. We should (later) make sure that doesn't cause a problem, if it's true. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:467: // See https://crbug.com/75195. I have no problem with this change in general, but it's unrelated to this CL. Given how many revisions and rebases we've been through (and the chance that this might be reverted), we really should not be including any unnecessary churn in this CL. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:607: // As the RenderFrameHost might already be swapped out, check if that is Simplify: "Check if the RenderFrameHost is already swapped out, to avoid swapping it out again." https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:660: // Cleans up any state in case there's an ongoing navigation. nit: Clean https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:665: RenderFrameHostImpl* future_rfh = future_rfh -> dest_rfh Also, it's worth mentioning in a comment (or a DCHECK?) that this is either the current or speculative RFH, and thus it is already owned. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:677: RenderFrameHostImpl* rfh_for_navigation = nullptr; new_rfh would better match new_instance. Please also put their declarations together. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:692: // Will reuse the current RFH if its SiteInstance matches the new one from Drop "Will" https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:694: // is enabled the RFH is never kept when sites don't match. This isn't quite true, since we don't plan to isolate every site with --site-per-process. Let's rephrase the last sentence to "We only swap RFHs for subframes when --site-per-process is enabled." https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:729: if (!rfh_for_navigation->render_view_host()->IsRenderViewLive()) { Why not IsRenderFrameLive() on the RFH, as above? https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:744: scoped_ptr<RenderFrameHostImpl> rfh = UnsetSpeculativeRenderFrameHost(); As mentioned below, this should be: if (speculative_render_frame_host_) DiscardUnusedFrame(UnsetSpeculativeRenderFrameHost()); https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:757: if (speculative_render_frame_host_) { Seems like we shouldn't call this unless there is a speculative RFH (similar UnsetPendingRenderFrameHost). https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1167: // Create a non swapped out RFH with the given opener. No extra churn, please. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1396: WebUIImpl* future_web_ui; dest_web_ui = nullptr; https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:378: // Called (possibly several times) during a navigation to select an nit: select or create https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:380: RenderFrameHostImpl* GetFrameHostForNavigation(const GURL& url, The ownership of this RFH is unclear. Please document that the return value will already be owned by the RFHM, either as the current or speculative RFH. https://codereview.chromium.org/701953006/diff/750001/content/test/test_web_c... File content/test/test_web_contents.h (right): https://codereview.chromium.org/701953006/diff/750001/content/test/test_web_c... content/test/test_web_contents.h:102: TestRenderFrameHost* GetNextMainFrameCandidate() const; It seems a bit awkward to have this, especially since it's not listed near GetPendingMainFrame. We should either make GetPendingMainFrame behave this way (i.e., return the speculative RFH in PlzNavigate mode) or make the caller do the check. Since there's only one caller so far, I'm inclined to do the latter.
Thanks. Changes, replies and a few questions are all up. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:273: EXPECT_FALSE(GetSpeculativeRenderFrameHost(rfhm)); On 2015/01/12 23:30:51, Charlie Reis wrote: > On 2014/12/16 01:53:47, carlosk wrote: > > On 2014/12/10 22:37:44, Charlie Reis wrote: > > > On 2014/12/09 07:55:41, carlosk wrote: > > > > On 2014/12/04 01:11:30, Charlie Reis wrote: > > > > > Why is there no speculative RFH after it redirects cross site? Is that > > > > planned > > > > > for later? (Seems like we might as well create one while we're waiting > > for > > > > the > > > > > new response.) > > > > > > > > > > If we're not planning to create one in this CL, then a TODO here might > be > > > > > worthwhile. > > > > > > > > Indeed that is a task for later on. The idea is to monitor redirects --- > > that > > > > now are conveniently tracked at the browser side -- to update the > > speculative > > > > RFH accordingly. But we have to be careful with this as we'll possibly be > > > > creating quite some churn by creating and destroying RFH in bursts. > > > > > > Later is fine. Worth noting that we wouldn't get a "burst" for multiple > > > redirects, at least. We'll get at most two speculative RFHs per navigation > > > (once when it starts, and once after all the server redirects are done). > > > > So if I understand correctly when server redirects happen we only get the > final > > result? I guess we could still get some more when jumping from one server to > the > > next? > > [Just following up on an old thread. This probably doesn't matter anymore.] > > It was designed so that we don't choose a new process until all the server > redirects have finished. There's at most one speculative RFH at the time the > navigation is begun, and one more after all the server redirects. > > However, client redirects are a different story. Those actually commit a real > page in a renderer process, and then immediately decide to navigate somewhere > else. There could be an arbitrarily long chain of client redirects each > requiring a process swap (up to a limit when Chrome says the redirect chain is > too long). Understood. To confirm: the server redirects are "invisible" even when we hop from domain to domain (ie goo.gl -> bit.ly -> tinyurl.com -> ...)? https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:98: rfh->GetRoutingID() == commit_message->routing_id(); On 2015/01/12 23:30:51, Charlie Reis wrote: > nit: Wrong indent (should be 4 spaces). I'll defer to clang-format if it > disagrees. It disagrees. :) I've been trying to run it always before uploading a new patch set. I have the impression this behavior changed recently where it gives precedence to column align expressions. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:109: EXPECT_EQ(SiteInstanceImpl::GetSiteForURL(browser_context(), kUrl), On 2015/01/12 23:30:52, Charlie Reis wrote: > This is a good idea to test, but it's equally important to test the actual URL > that commits. Please add a check that contents()->GetLastCommittedURL() is kUrl > as well. Done. I wanted to be sure with this expectation the SI is the correct one as it is the most important piece in regards to the specific renderer process being used. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:158: // unless site-per-process is enabled. In that case as the subframe navigation On 2015/01/12 23:30:51, Charlie Reis wrote: > nit: Comma after "In that case" Done. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:185: // As the main frame hasn't yet committed the subframe still exists. So the On 2015/01/12 23:30:52, Charlie Reis wrote: > nit: The second sentence is a sentence fragment. > s/So/Thus,/ Done. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:209: // As we're re-using the current RenderFrameHost, no speculative one should be On 2015/01/12 23:30:52, Charlie Reis wrote: > English nit: "Since" or "Because" would be easier to read here than "As." "As > we're..." sounds like the two things are happening at the same time, rather than > one because of the other. (Same in the cases above, and apologies for English > being such a terribly confusing language!) Done. You didn't invent it (I assume) so no reason to be sorry. :) https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:314: EXPECT_FALSE(DidRenderFrameHostCommit(main_test_rfh())); On 2015/01/12 23:30:52, Charlie Reis wrote: > This is very confusing for those of us familiar with the current navigation > flow. Did...Commit sounds like it refers to the time after the renderer process > has committed (i.e., DidCommitProvisionalLoad). > > That would make this impossible-- if the speculative RFH commits, it would > become main_test_rfh(), and thus this line couldn't pass. I'm guessing it means > something else (i.e., the RFH has *requested* that the renderer process commit > the navigation, but it hasn't happened yet). > > If that's the case, let's rename the method to DidRenderFrameHostRequestCommit. Agreed and done. I was confused because the method that causes the IPC to be sent is called RenderFrameHostImpl::CommitNavigation. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:358: // Then it commits. On 2015/01/12 23:30:52, Charlie Reis wrote: > This adds to my confusion. The navigation has not committed here. Can you > update this comment while you're here? Changed to: Request the RenderFrameHost to commit. Also made similar changes to other comments. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:480: // navigating from one site to the another. On 2015/01/12 23:30:52, Charlie Reis wrote: > nit: Drop "the" Done. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:536: EXPECT_EQ(init_site_instance_id, main_test_rfh()->GetSiteInstance()->GetId()); On 2015/01/12 23:30:52, Charlie Reis wrote: > Please verify that init_site_instance_id and site_instance_id are not the same. Done. Good one. Also added a couple of these below for the next site id. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:558: // TODO(carlosk): once the speculative RenderFrameHost updates with redirects On 2015/01/12 23:30:52, Charlie Reis wrote: > I agree with the TODO, but it's hard to follow what the test is doing in the > meantime. Above the TODO, please add "For now, ensure that the speculative RFH > does not change after the redirect." Done. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:571: // Once commit happens the speculative RenderFrameHost is already updated to On 2015/01/12 23:30:52, Charlie Reis wrote: > Drop "already," since this seems to be the point in time when the speculative > RFH is updated. Done. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:73: if (base::CommandLine::ForCurrentProcess()->HasSwitch( On 2015/01/12 23:30:52, Charlie Reis wrote: > We should probably mimic the case above and check for > speculative_render_frame_host_ instead of the switch. (No need for braces.) Done. I was in doubt about this one because we were almost always using the switch guard. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:429: DCHECK(render_frame_host); On 2015/01/12 23:30:52, Charlie Reis wrote: > This seems unnecessary to me, since the callers are all within the navigation > logic and it's fairly obvious they won't pass in null. (We don't have DCHECKs > in those methods either.) Done. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:435: // TODO(carlosk): this code doesn't properly handles in-page nor On 2015/01/12 23:30:52, Charlie Reis wrote: > handle > nor -> or Done. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:436: // interweaved navigation requests navigation. On 2015/01/12 23:30:52, Charlie Reis wrote: > I don't know what this means. Fixed: /interweaved/interwoven This case might happen if one browser-initiated navigation is at the point of waiting for the renderer to commit when another browser-initiated navigation is started. Then we received here the reply from the renderer regarding the 1st navigation and the |render_frame_host| might not match the new speculative that belongs to the 2nd one. Both this case and in-page navigation might fail the DCHECK here. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:446: if (!cross_navigation_pending_) { On 2015/01/12 23:30:52, Charlie Reis wrote: > Why isn't this block above the one you added? Is cross_navigation_pending_ > never set to true in PlzNavigate mode? If not, we should document that in the > .h file, since it's checked in a ton of places. We should (later) make sure > that doesn't cause a problem, if it's true. It is not used by PlzNavigate so I documented that in the .h file. The only two methods that (I guess) are still in use with PlzNavigate where cross_navigation_pending_ is checked are RFHM::Stop and RFHM::ShouldCloseTabOnUnresponsiveRenderer. RFHM::OnBeforeUnloadACK also uses it but in a section not active with PlzNavigate (see DCHECK). https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:467: // See https://crbug.com/75195. On 2015/01/12 23:30:53, Charlie Reis wrote: > I have no problem with this change in general, but it's unrelated to this CL. > Given how many revisions and rebases we've been through (and the chance that > this might be reverted), we really should not be including any unnecessary churn > in this CL. Acknowledged and reverted. (FYI I was asked for this change) https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:607: // As the RenderFrameHost might already be swapped out, check if that is On 2015/01/12 23:30:52, Charlie Reis wrote: > Simplify: "Check if the RenderFrameHost is already swapped out, to avoid > swapping it out again." Done. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:660: // Cleans up any state in case there's an ongoing navigation. On 2015/01/12 23:30:53, Charlie Reis wrote: > nit: Clean Done. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:665: RenderFrameHostImpl* future_rfh = On 2015/01/12 23:30:52, Charlie Reis wrote: > future_rfh -> dest_rfh > > Also, it's worth mentioning in a comment (or a DCHECK?) that this is either the > current or speculative RFH, and thus it is already owned. Done the name change. And for the expectation you described I updated a DCHECK in GetFrameHostForNavigation and improved its doc comment in the .h file to reflect it. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:677: RenderFrameHostImpl* rfh_for_navigation = nullptr; On 2015/01/12 23:30:52, Charlie Reis wrote: > new_rfh would better match new_instance. Please also put their declarations > together. I went another route: current_instance -> current_site_instance new_instance -> navigation_site_instance rfh_for_navigation -> navigation_rfh I disliked "new" as they might not be actually new and the *_instance suffix was misleading because it invokes the OO concept. WDYT? https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:692: // Will reuse the current RFH if its SiteInstance matches the new one from On 2015/01/12 23:30:53, Charlie Reis wrote: > Drop "Will" Done. Also updated the rest a bit. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:694: // is enabled the RFH is never kept when sites don't match. On 2015/01/12 23:30:52, Charlie Reis wrote: > This isn't quite true, since we don't plan to isolate every site with > --site-per-process. Let's rephrase the last sentence to "We only swap RFHs for > subframes when --site-per-process is enabled." Done. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:729: if (!rfh_for_navigation->render_view_host()->IsRenderViewLive()) { On 2015/01/12 23:30:52, Charlie Reis wrote: > Why not IsRenderFrameLive() on the RFH, as above? Replaced. I think I copied these two snippets from somewhere else so they came as they were. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:744: scoped_ptr<RenderFrameHostImpl> rfh = UnsetSpeculativeRenderFrameHost(); On 2015/01/12 23:30:52, Charlie Reis wrote: > As mentioned below, this should be: > if (speculative_render_frame_host_) > DiscardUnusedFrame(UnsetSpeculativeRenderFrameHost()); The reason I did it this way was to cover the case of the web_ui being set but not the speculative RFH. But it doesn't seem like that's possible so I made the change as you suggested. But this made me be a bit more cautious with setting |should_reuse_web_ui_| so I made a little change to CreateSpeculativeRenderFrameHost. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:757: if (speculative_render_frame_host_) { On 2015/01/12 23:30:52, Charlie Reis wrote: > Seems like we shouldn't call this unless there is a speculative RFH (similar > UnsetPendingRenderFrameHost). Now this one sounds a bit too risky for the potential null dereference crash here (thinking defensive programming). I prefer not to cause a crash like this in a cleanup function, WDYT? https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1167: // Create a non swapped out RFH with the given opener. On 2015/01/12 23:30:52, Charlie Reis wrote: > No extra churn, please. Done. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:1396: WebUIImpl* future_web_ui; On 2015/01/12 23:30:52, Charlie Reis wrote: > dest_web_ui = nullptr; Done. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:378: // Called (possibly several times) during a navigation to select an On 2015/01/12 23:30:53, Charlie Reis wrote: > nit: select or create Done. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:380: RenderFrameHostImpl* GetFrameHostForNavigation(const GURL& url, On 2015/01/12 23:30:53, Charlie Reis wrote: > The ownership of this RFH is unclear. Please document that the return value > will already be owned by the RFHM, either as the current or speculative RFH. Done. https://codereview.chromium.org/701953006/diff/750001/content/test/test_web_c... File content/test/test_web_contents.h (right): https://codereview.chromium.org/701953006/diff/750001/content/test/test_web_c... content/test/test_web_contents.h:102: TestRenderFrameHost* GetNextMainFrameCandidate() const; On 2015/01/12 23:30:53, Charlie Reis wrote: > It seems a bit awkward to have this, especially since it's not listed near > GetPendingMainFrame. > > We should either make GetPendingMainFrame behave this way (i.e., return the > speculative RFH in PlzNavigate mode) or make the caller do the check. Since > there's only one caller so far, I'm inclined to do the latter. This was meant to help with the efforts of making tests pass with PlzNavigate enabled. We didn't consider the option of changing the behavior of GetPendingMainFrame as it might look inconsistent. But as you are OK with that it's certainly the easiest choice for us as we won't need to replace all of its occurrences in the future. Updated GetPendingMainFrame, removed GetNextMainFrameCandidate and updated the doc comment for GetPendingMainFrame in web_contents_tester.h.
Thanks, just a few last things. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:273: EXPECT_FALSE(GetSpeculativeRenderFrameHost(rfhm)); On 2015/01/13 15:54:12, carlosk wrote: > Understood. To confirm: the server redirects are "invisible" even when we hop > from domain to domain (ie goo.gl -> bit.ly -> http://tinyurl.com -> ...)? Invisible to RFHM and the UI thread, correct. The network stack handles them and lets the us know when the page is ready to commit. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:98: rfh->GetRoutingID() == commit_message->routing_id(); On 2015/01/13 15:54:12, carlosk wrote: > On 2015/01/12 23:30:51, Charlie Reis wrote: > > nit: Wrong indent (should be 4 spaces). I'll defer to clang-format if it > > disagrees. > > It disagrees. :) > > I've been trying to run it always before uploading a new patch set. I have the > impression this behavior changed recently where it gives precedence to column > align expressions. Acknowledged. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:446: if (!cross_navigation_pending_) { On 2015/01/13 15:54:12, carlosk wrote: > On 2015/01/12 23:30:52, Charlie Reis wrote: > > Why isn't this block above the one you added? Is cross_navigation_pending_ > > never set to true in PlzNavigate mode? If not, we should document that in the > > .h file, since it's checked in a ton of places. We should (later) make sure > > that doesn't cause a problem, if it's true. > > It is not used by PlzNavigate so I documented that in the .h file. > > The only two methods that (I guess) are still in use with PlzNavigate where > cross_navigation_pending_ is checked are RFHM::Stop and > RFHM::ShouldCloseTabOnUnresponsiveRenderer. RFHM::OnBeforeUnloadACK also uses it > but in a section not active with PlzNavigate (see DCHECK). Ok. Those cases will matter, but it sounds like you're tracking them, so that's fine for now. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:677: RenderFrameHostImpl* rfh_for_navigation = nullptr; On 2015/01/13 15:54:13, carlosk wrote: > On 2015/01/12 23:30:52, Charlie Reis wrote: > > new_rfh would better match new_instance. Please also put their declarations > > together. > > I went another route: > current_instance -> current_site_instance > new_instance -> navigation_site_instance > rfh_for_navigation -> navigation_rfh > > I disliked "new" as they might not be actually new and the *_instance suffix was > misleading because it invokes the OO concept. > > WDYT? *_site_instance instead of *_instance is fine. I probably would choose "dest_" instead of "navigation_" for brevity and consistency with existing names. I agree with "new" being potentially confusing. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:729: if (!rfh_for_navigation->render_view_host()->IsRenderViewLive()) { On 2015/01/13 15:54:12, carlosk wrote: > On 2015/01/12 23:30:52, Charlie Reis wrote: > > Why not IsRenderFrameLive() on the RFH, as above? > > Replaced. I think I copied these two snippets from somewhere else so they came > as they were. Oh, I see. I guess we left that case as IsRenderViewLive because the calls made in this block are about RenderViews. I suppose either way is fine by me, since I think they should be equivalent at this point. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:744: scoped_ptr<RenderFrameHostImpl> rfh = UnsetSpeculativeRenderFrameHost(); On 2015/01/13 15:54:13, carlosk wrote: > On 2015/01/12 23:30:52, Charlie Reis wrote: > > As mentioned below, this should be: > > if (speculative_render_frame_host_) > > DiscardUnusedFrame(UnsetSpeculativeRenderFrameHost()); > > The reason I did it this way was to cover the case of the web_ui being set but > not the speculative RFH. But it doesn't seem like that's possible so I made the > change as you suggested. > > But this made me be a bit more cautious with setting |should_reuse_web_ui_| so I > made a little change to CreateSpeculativeRenderFrameHost. Acknowledged. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:757: if (speculative_render_frame_host_) { On 2015/01/13 15:54:12, carlosk wrote: > On 2015/01/12 23:30:52, Charlie Reis wrote: > > Seems like we shouldn't call this unless there is a speculative RFH (similar > > UnsetPendingRenderFrameHost). > > Now this one sounds a bit too risky for the potential null dereference crash > here (thinking defensive programming). I prefer not to cause a crash like this > in a cleanup function, WDYT? I disagree. If we're calling this method with no speculative RFH, then something is wrong and it's better to crash early and get a report. Please make it consistent with UnsetPendingRenderFrameHost. https://codereview.chromium.org/701953006/diff/770001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/770001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:380: // be whether for the current or the speculative RenderFrameHost and the nit: Drop "whether"
Thanks again. All done. https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/370001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:273: EXPECT_FALSE(GetSpeculativeRenderFrameHost(rfhm)); On 2015/01/13 18:48:21, Charlie Reis wrote: > On 2015/01/13 15:54:12, carlosk wrote: > > Understood. To confirm: the server redirects are "invisible" even when we hop > > from domain to domain (ie goo.gl -> bit.ly -> http://tinyurl.com -> ...)? > > Invisible to RFHM and the UI thread, correct. The network stack handles them > and lets the us know when the page is ready to commit. Acknowledged. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.cc (right): https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:446: if (!cross_navigation_pending_) { On 2015/01/13 18:48:21, Charlie Reis wrote: > On 2015/01/13 15:54:12, carlosk wrote: > > On 2015/01/12 23:30:52, Charlie Reis wrote: > > > Why isn't this block above the one you added? Is cross_navigation_pending_ > > > never set to true in PlzNavigate mode? If not, we should document that in > the > > > .h file, since it's checked in a ton of places. We should (later) make sure > > > that doesn't cause a problem, if it's true. > > > > It is not used by PlzNavigate so I documented that in the .h file. > > > > The only two methods that (I guess) are still in use with PlzNavigate where > > cross_navigation_pending_ is checked are RFHM::Stop and > > RFHM::ShouldCloseTabOnUnresponsiveRenderer. RFHM::OnBeforeUnloadACK also uses > it > > but in a section not active with PlzNavigate (see DCHECK). > > Ok. Those cases will matter, but it sounds like you're tracking them, so that's > fine for now. Acknowledged. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:677: RenderFrameHostImpl* rfh_for_navigation = nullptr; On 2015/01/13 18:48:21, Charlie Reis wrote: > On 2015/01/13 15:54:13, carlosk wrote: > > On 2015/01/12 23:30:52, Charlie Reis wrote: > > > new_rfh would better match new_instance. Please also put their declarations > > > together. > > > > I went another route: > > current_instance -> current_site_instance > > new_instance -> navigation_site_instance > > rfh_for_navigation -> navigation_rfh > > > > I disliked "new" as they might not be actually new and the *_instance suffix > was > > misleading because it invokes the OO concept. > > > > WDYT? > > *_site_instance instead of *_instance is fine. > > I probably would choose "dest_" instead of "navigation_" for brevity and > consistency with existing names. I agree with "new" being potentially > confusing. Done: navigation_site_instance -> dest_site_instance I kept the navigation_rfh as it matches the method name. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:729: if (!rfh_for_navigation->render_view_host()->IsRenderViewLive()) { On 2015/01/13 18:48:21, Charlie Reis wrote: > On 2015/01/13 15:54:12, carlosk wrote: > > On 2015/01/12 23:30:52, Charlie Reis wrote: > > > Why not IsRenderFrameLive() on the RFH, as above? > > > > Replaced. I think I copied these two snippets from somewhere else so they came > > as they were. > > Oh, I see. I guess we left that case as IsRenderViewLive because the calls made > in this block are about RenderViews. > > I suppose either way is fine by me, since I think they should be equivalent at > this point. Acknowledged. https://codereview.chromium.org/701953006/diff/750001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.cc:757: if (speculative_render_frame_host_) { On 2015/01/13 18:48:21, Charlie Reis wrote: > On 2015/01/13 15:54:12, carlosk wrote: > > On 2015/01/12 23:30:52, Charlie Reis wrote: > > > Seems like we shouldn't call this unless there is a speculative RFH (similar > > > UnsetPendingRenderFrameHost). > > > > Now this one sounds a bit too risky for the potential null dereference crash > > here (thinking defensive programming). I prefer not to cause a crash like this > > in a cleanup function, WDYT? > > I disagree. If we're calling this method with no speculative RFH, then > something is wrong and it's better to crash early and get a report. Please make > it consistent with UnsetPendingRenderFrameHost. Done. https://codereview.chromium.org/701953006/diff/770001/content/browser/frame_h... File content/browser/frame_host/render_frame_host_manager.h (right): https://codereview.chromium.org/701953006/diff/770001/content/browser/frame_h... content/browser/frame_host/render_frame_host_manager.h:380: // be whether for the current or the speculative RenderFrameHost and the On 2015/01/13 18:48:21, Charlie Reis wrote: > nit: Drop "whether" Done.
Thanks! LGTM.
Thanks for pulling through this one! LGTM with few minor nits. https://codereview.chromium.org/701953006/diff/810001/content/browser/frame_h... File content/browser/frame_host/navigator_impl.cc (right): https://codereview.chromium.org/701953006/diff/810001/content/browser/frame_h... content/browser/frame_host/navigator_impl.cc:785: // renderer in parallel. nit: s/renderer/RenderFrameHost/ Charlie and I had a discussion yesterday and one of the outcomes is to avoid using "renderer" on its own, as it is very vague term. https://codereview.chromium.org/701953006/diff/810001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/810001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:327: // PlzNavigate: Test that redirects are followed and the speculative renderer nit: s/renderer/RenderFrameHost/ https://codereview.chromium.org/701953006/diff/810001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:380: // issued in the meantime. Also confirms that the speculative renderer is nit: s/renderer/RenderFrameHost/ https://codereview.chromium.org/701953006/diff/810001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:446: // renderer when the navigation can commit. Speculative renderers should not be nit: s/renderer/RenderFrameHost/ or s/renderer/RenderFrame/, depending on the context.
Thanks and thanks! Feeling pretty good here! :) https://codereview.chromium.org/701953006/diff/810001/content/browser/frame_h... File content/browser/frame_host/navigator_impl.cc (right): https://codereview.chromium.org/701953006/diff/810001/content/browser/frame_h... content/browser/frame_host/navigator_impl.cc:785: // renderer in parallel. On 2015/01/14 19:03:14, nasko wrote: > nit: s/renderer/RenderFrameHost/ > > Charlie and I had a discussion yesterday and one of the outcomes is to avoid > using "renderer" on its own, as it is very vague term. Done. Replaced it where you commented and in a few other places I found. https://codereview.chromium.org/701953006/diff/810001/content/browser/frame_h... File content/browser/frame_host/navigator_impl_unittest.cc (right): https://codereview.chromium.org/701953006/diff/810001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:327: // PlzNavigate: Test that redirects are followed and the speculative renderer On 2015/01/14 19:03:14, nasko wrote: > nit: s/renderer/RenderFrameHost/ Done. https://codereview.chromium.org/701953006/diff/810001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:380: // issued in the meantime. Also confirms that the speculative renderer is On 2015/01/14 19:03:14, nasko wrote: > nit: s/renderer/RenderFrameHost/ Done. https://codereview.chromium.org/701953006/diff/810001/content/browser/frame_h... content/browser/frame_host/navigator_impl_unittest.cc:446: // renderer when the navigation can commit. Speculative renderers should not be On 2015/01/14 19:03:14, nasko wrote: > nit: s/renderer/RenderFrameHost/ or s/renderer/RenderFrame/, depending on the > context. Done.
The CQ bit was checked by carlosk@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/701953006/830001
Message was sent while issue was closed.
Committed patchset #32 (id:830001)
Message was sent while issue was closed.
Patchset 32 (id:??) landed as https://crrev.com/39337115364bd37da597ae90a023b0a31df9b370 Cr-Commit-Position: refs/heads/master@{#311549} |
