fix: multiple fast navigate calls

[caalador]

Fix issue where a slow connection
and fast navigate calls throws
exception due to faulty blocker
state change.

Fixes #20404

[github-actions]

Test Results

1 158 files  ±0  1 158 suites  ±0   1h 34m 15s ⏱️ - 1m 38s
7 513 tests ±0  7 460 ✅ ±0  53 💤 ±0  0 ❌ ±0 
7 887 runs  +8  7 824 ✅ +8  63 💤 ±0  0 ❌ ±0 

Results for commit e60dba1. ± Comparison against base commit d418c0e.

♻️ This comment has been updated with latest results.

[mshabarov]

The patch looks good.
Smoke tested it, couldn't spot anything weird.
However, I couldn't reproduce the original issue.

Another pair of eyes would be beneficial.

[caalador]

Easiest way to replicate original issue is to have a hilla layout and 2 flow layouts, setting the network throttling to slow 4g , then navigating to a flow view from a flow view through the layout menu and clicking 2 times on the menu item.

[mshabarov]

We talked with @platosha on Friday, this patch slightly changes how navigation works: with a slow network, when you first time click on the menu link and immediately click on the second one, the application will ignore the second navigation and basically all other navigations until the first one completes.
Maybe it's better to queue these navigations and apply the latest in the end. Flow navigation works like this IIRC.
@platosha promised to see how we can do it.
@caalador do you think it's better to queue like I described?

[caalador]

We could push the navigate to queuedNavigate instead of canceling the navigation. I think we have enough information to do that.

The issue is that when the programmer uses react-router navigate() directly when on a Flow view it bypasses all the features for navgation we have except for the blocker and this will start multiple blockers at the same time setting the blocker state multiple times for the same instance as the latter one overwrites the previous one without checking if it is blocking already or not.

[mshabarov]

Thanks for the tip, the exception has eventually appeared for me and after the latest changes I don't see it anymore and the multiple navigations are queued and handled as I expected - the last click wins in the end.

I think we can try adding a test that simulates the same steps, I wonder if these codes works:

public class UseBlockerIT extends ChromeDeviceTest {

    @Test
    public void test() {
        ChromeDriver driver = (ChromeDriver) getDriver();
        DevTools devTools = driver.getDevTools();
        devTools.send(Network.enable(Optional.empty(), Optional.empty(), Optional.empty()));
        devTools.send(Network.emulateNetworkConditions(
                false, // offline
                100,   // latency (ms)
                750000, // download through (bits per second)
                250000, // upload throughput (bits per second)
                Optional.of(ConnectionType.CELLULAR4G), // connection type
                Optional.empty(),
                Optional.empty(),
                Optional.empty()
        ));
        // open a page
        // click twice
        // check for errors
        // check the latest navigation
    }
}

If Flow repo is not a suitable place for it, could we add it to platform test module?

[caalador]

Couldn't get the test to fail for multiple fasts clicks when clicking programmatically.
Setting network_conditions before open made the test really slow indicating that it probably does work, but it doesn't help with the test. Adding either a timeout 0 or animation frame makes the second click throw due to undefined so it is too late.

[mshabarov]

I'm worrying about maintenance for this: future Chrome updates can be incompatible with the ChromeDriver, so we have to bump this version all the time.
If the test always passes, maybe we can disable it, so it will show case the failing scenario, but won't run in CI.

[caalador]

Removed test and added doc on the view class.

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud