barba

barba copied to clipboard

The problem

When the server takes too long to answer from a fetch, the page gets refreshed instead of redirecting the user to the target page. It seems to be a regression since V2.8.0. I tested with versions 2.6.1 and 2.7.2 and both are working correctly. It's easy to reproduce by setting a very low timeout option value.

Description

See this screenshot using the version 2.8.0 where the problem occurs

See this screenshot using the version 2.6.1 without the problem

Steps to reproduce issue [ Good To Have ]

Broken demo

1. Go to: https://mamboleoo.be/barba/
2. Open devtools and simulate 3G slow connection
3. Click on test url
4. You stay on the same page instead

Working demo

1. Go to: https://mamboleoo.be/barba/old.html
2. Open devtools and simulate 3G slow connection
3. Click on test url
4. You are redirected to the target page

Environment

• Barba version that exhibits the issue: ^2.8.0
• Browser OS/version used: All

Thanks for having a look at this!

Hi @Mamboleoo,

Have you try to disable the default barba prefetch behavior? Just to see if its related.

Thanks :wink:

I updated the demo and the issue is still occurring even with prefetchIgnore: true :/ https://mamboleoo.be/barba/

Good catch, its a bug, thanks for pointing this out! :smiley:

@Mamboleoo,

Could you try with:

barba.init({
    debug: true,
    timeout: 100,
  });

Really weird but I can reproduce your issue only with no debug. With debug: true, it redirects as expected… 🙃🤔

@Mamboleoo,

Nervermind, got it… :)

Hi @Mamboleoo could you check if it's ok with 2.9.5? Thanks in advance

Looks like the problem still exists on 2.9.6, and like in @thierrymichel's case the issue doesn't occur when debug is set to true.

Not sure if this is intentional or not, but I also found that the page also gets refreshed instead of being redirected when clicking on a link to a page on the same site, but that page doesn't have barba wrapper nor container (let's say that I intentionally designed that page to not use barba). However, in this particular case the issue persists even with debug: true unlike in the timeout issue above.

@thierrymichel Sorry I just got back on the project where I'm using Barba. I'm testing version 2.9.7 and the bug seems to be still there. When using debug:true it doesn't refresh the page (so the expected behaviour) and I'm getting those console errors.

@Mamboleoo I am having the same issue. Did you manage to find a fix? Can you reopen this issue?

Hi @nicolas-cusan @Mamboleoo,

I just tested and it looks like this issue is patched, the reproductible repo of @Mamboleoo work as expected: the page redirect to the appropriate URL and doesn't refresh the current one.

Thanks for your feedbacks :wink:

@xavierfoucrier thank you for the heads up! Will there be a new npm release that includes the patch soon?

Hi @nicolas-cusan,

This have been patched months ago by @thierrymichel in https://github.com/barbajs/barba/commit/281c85fc7bbaf3d51ee58653468c48b2404152ea.

But as you leave a comment, I want to be sure of that. Can you share a reproductible repo where you are facing this issue?

Be sure to use the latest @barba/[email protected]

Thanks

@xavierfoucrier I do not have a reproductible repo that isolates that problem at the moment. I have the issue happening repeatedly on this website in production https://www.bold.ch/ (particularly on mobile). It uses @barba/[email protected]. The barba timeout is quite high at the moment so it does not happen often.

I will try to create a repo soon and share it here.

Thanks, waiting for your feedback with the minimal repo. :wink:

Hi @xavierfoucrier, long time.

I finally have a site where this is reproducible in a reliable way (still in development):

Steps to reproduce:

1. Go here: http://terra-vecchia.ch.antiqua.sui-inter.net/
2. Use the main menu to transition to the team page using barba (right column 4th item, see screenshot)
3. The page you are coming from will be reloaded

Background: The team page renders about a 100 records from the backend, the server response time is therefor really long (will be cached for production), but still this does represent the issue pretty well.

Thank you for taking a look!

Barba Version: 2.9.7

Hi @nicolas-cusan!

Yeah, about a year ago haha :smile:

Well, I understand your problematic, the fact is that if you don't want to touch anything and fix this, you will need to increase the timeout: there is nothing else that can tell Barba to wait for your page to load and not reload the whole page.

BUT.. the fact is that you could use something pretty different, like this workflow:

• the user click on the "Team" link
• the "Team" page loads without all your content stuff
• you display an animation or something telling the user that the content will take some time to load
• you preload your content using an async request inside the "Team" page

This way, Barba will not "timeout" your page, and there won't be any reload :sunglasses:

Hello @xavierfoucrier,

thank you so much for your fast reply! And thank you for your tips.

The issue is not so much the reload/lack of transition (some users do not even notice), but that the user ends up on the same page he was before. In older versions (1.x) a timeout would cause a full page load but the the user would end up at the target page (team in this case). The current behavior is kind of bad from a UX / progressive enhancement point of view as the user clicks a link and does not end up there (not even with a reload).

Is there a recommended way to force the link to go through if the request times out, even if it is without a transition?

For anybody having this issue, I ended up setting debug to true in production ¯_(ツ)_/¯.

I tried to use requestError to properly handle the behaviour with no luck. It seems that this part of the code always gets triggered no matter what when a timeout occurs and debugging is switched off. (Haven't had time to properly test it though).

Hey @nicolas-cusan,

Yes I probably would have asked you to test request error... Looks like we need to dive into this a little bit more and improve the default behavior.

I am reopening the issue and will discuss that with Thierry next time :wink: Thanks again for your feedback. :ok_hand:

Thank you for looking further into it! 🙌

Hey, any news on this? I can confirm @nicolas-cusan `s points and observations.

On timeout, I'd definitely expect a redirect to the target page, instead of reloading the current page. Wouldn't this just be a matter of replacing this with something like this.data.next.url? Could we perhaps make it configurable?

Having the same issue on a Wordpress theme equipped with BarbaJS. Running on localhost (fast DB) everything works fine, when using a remote DB (somewhat slower) this behaviour is shown.

Can also confirm that I have the same issue. Have implemented the fix in https://github.com/barbajs/barba/pull/653 and it seems to work.

I seem to experience a related issue. Page refreshes if the request is pending (but not on timeout)

I have a page with a very basic barbajs implementation here: https://www.reddigital.dev/

Steps to reproduce:

• Go to the network tab in your browser devtools and set the connection speed to Slow 3G
• When you hover over the "BLOG" menu link, barbajs initiates a request to /about
• While the request is still pending, clicking on the link only causes the current page to reload.
• If you wait for the timeout, ie for the request to be cancelled, the link behaves correctly.

So just to be super clear:

Clicking when the page is in this state will reload the current page

Clicking after the timeout behaves as expected

This happens on every hover + click. So for this site to work on a slow connection, the user has to hover over the link for 2 seconds before clicking on it.

Okay boys, I hacked it.

barba.init({
  timeout: 5000, // test with a value of 200 for example
  requestError: (trigger, action, url, response) => {
    if (action === 'click') {
      barba.force(barba.url.parse(url).path)
      /* stop script execution - https://stackoverflow.com/questions/9298839/is-it-possible-to-stop-javascript-execution */
      thisFunctionDoesNotExistInOrderToStopScriptExecution()
      }
    }
})

This is definitely not a correct solution, but a temporary fix.

Closed by https://github.com/barbajs/barba/pull/653.