Re: Deletion of the old navigation codepath in M65

[Camille Lamy]

Hi Chromites and Chrome embedders,

We have finally launched PlzNavigate on all platforms, so as we previously announced we will now fully deprecate the old navigation code path. https://chromium-review.googlesource.com/c/chromium/src/+/772231 will drop test support for the old navigation codepath. We will follow up by making PlzNavigate always on (ie IsBrowserSideNavigationEnabled will always return true), and removing --disable-browser-side-navigation and --enable-browser-side-navigation from the list of command line flags. Following that, we will be removing the old navigation codepath in the coming weeks.

Thanks all for your help in making this happen!

Camille

On Fri, Oct 27, 2017 at 4:30 PM Camille Lamy <cl...@chromium.org> wrote:

Hi Chromites and Chrome embedders,

We launched PlzNavigate (aka the new navigation rewrite) on Android and desktop on M61, and plan on having it launch on Android WebView on M63. If all goes well, this means that we will be able to remove the old navigation codepath after Android WebView M63 has been launched for two weeks (to monitor for stability).

Right now, the new navigation codepath is on by default, some most Chromium users should not have anything special to do. In fact it should make your life easier, since you will no longer have to support two navigation codepaths!

For embedders, what that means is that starting mid-December, we will remove the --disable-browser-side-navigation flag that still allows to access the old navigation code path, and then follow up with the removal of the old code. If you have any questions on how to support the new architecture, please reach us at plzna...@chromium.org.

Thanks all!

Camille

[Dirk Pranke]

Congrats!

-- Dirk

On Tue, Dec 19, 2017 at 9:02 AM, Camille Lamy <cl...@chromium.org> wrote:

Hi Chromites and Chrome embedders,

We have finally launched PlzNavigate on all platforms, so as we previously announced we will now fully deprecate the old navigation code path. https://chromium-review.googlesource.com/c/chromium/src/+/772231 will drop test support for the old navigation codepath. We will follow up by making PlzNavigate always on (ie IsBrowserSideNavigationEnabled will always return true), and removing --disable-browser-side-navigation and --enable-browser-side-navigation from the list of command line flags. Following that, we will be removing the old navigation codepath in the coming weeks.

Thanks all for your help in making this happen!

Camille

On Fri, Oct 27, 2017 at 4:30 PM Camille Lamy <cl...@chromium.org> wrote:

Hi Chromites and Chrome embedders,

We launched PlzNavigate (aka the new navigation rewrite) on Android and desktop on M61, and plan on having it launch on Android WebView on M63. If all goes well, this means that we will be able to remove the old navigation codepath after Android WebView M63 has been launched for two weeks (to monitor for stability).

Right now, the new navigation codepath is on by default, some most Chromium users should not have anything special to do. In fact it should make your life easier, since you will no longer have to support two navigation codepaths!

For embedders, what that means is that starting mid-December, we will remove the --disable-browser-side-navigation flag that still allows to access the old navigation code path, and then follow up with the removal of the old code. If you have any questions on how to support the new architecture, please reach us at plzna...@chromium.org.

Thanks all!

Camille

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMKsNvrxodzvWxoLy9%2BTYvhECoPK2%2BzwNOrF0HdZm417drbB1Q%40mail.gmail.com.

[Wez]

+1!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEoffTALA1P5LkTtyJRNz_H9cyRKZdbMq6WR33SYbcbH7Fmxnw%40mail.gmail.com.

[Ken Russell]

Awesome work pushing this through! Looking forward to seeing the old code path deleted, and the renderer-side-navigation test suites removed. :)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALekkJcR2EHKgSmSTqgjA42-LufKLSEwKWe6STrimVL%3DiUexEA%40mail.gmail.com.

[Camille Lamy]

Unfortunately, the code path is already gone, and it's not something that can be undone. We are working on resolving known issues, in particular with Chrome Driver. In any case, --disable-browser-side-navigation is not supported after M65.

On Sat, Feb 24, 2018 at 1:16 AM Roger Wong <rpw...@gmail.com> wrote:

So I'm a little out of my depth here, but I was directed here by a Chromedriver isPlans around provisional load changes





Remember to…



me

Feb 20

Hi Nasko and Daniel, I had a meeting with the password manager team today regarding their usage of DidStartProvisionalLoad. They agreed to move to the solution



Nasko Oskov

Feb 20

Marking the functions as deprecated sounds good to me. As far as new observer methods, I'd like if we can keep it consistent with the WCO methods, so they are f



me

Feb 20

I agree with the idea. So we'd get ReadyToCommitNavigation and DidCommitNavigation? For an additional one regarding asking the browser process to navigate, I'm



sue.

I have some concerns about removing this flag and code path based on my experience running Chromedriver 2.35 and Chrome 64 (see the chromedriver issue link for details).  

I've have been seeing issues running my test suite (which uses chromedriver) that use the new navigation codepath.  If I run with the "--disable-browser-side-navigation" flag then my tests pass successfully, but if I run without the flag, they fail, which sounds like there might be compatibility issues between webdriver/chromedriver and the new navigation path.

The chromedriver logs show several severe failures in the renderer and the calls afterwards (eg findelements) return empty results when the elements should have been found.

Have there been additional fixes since Chrome 64 that would have fixed the issue we've seen in the above Chromedriver issue?