Detecting navigation between boards

Our team has been working on building a Trello Power Up, and we’re running into some issues trying to respond to cross-board navigation in Trello. We have some background processing that occurs in our plugin, and we display its progress in a Board Bar. When that processing is complete it results in a comment that gets posted to the relevant card. if you end up navigating away, it will interrupt the processing and cause it to not complete. We have a window.onbeforeunload event listener that prompts the user in the case where the browser is closed or navigates to an external URL. We’re also handling the case where the Board Bar gets closed prematurely with a callback attached there.

However, when navigating to another Trello URL, it doesn’t trigger a beforeunload event or trigger the Board Bar closed-callback. Is there some other way we could respond to this navigation change?

It would be best if there was at least some event we could respond to, that way we could clean up the background processing task instead of just having it error when it tries to complete on the wrong board.

Can you go into more detail about how a user is navigating to another Trello URL? Are you specifically talking about the use of t.navigate()?

I’ve added a button to our example Power-Up’s board bar that navigates away and there is also an unload event listener that console.logs: Glitch :・゚✧

You can check it out live here: Trello

Clicking on the button gets the console.log to fire.

In general, if you’re doing something that is taking enough time that it can’t be done within the timeframe of a Power-Up being active on a page, we recommend that you move the processing to a backend service of some sort. We discourage folks from trying to put in blocking alerts/notifications.

I was just referring to a user’s navigation, specifically selecting a different board from the dropdown menu. The examples you posted show what I was missing, though. The unload event fires, but beforeunload does not. Also, I was attaching the listener in the main javascript file for the power up, and not in the board bar. Changing to an unload event handler fixed the issue. Thanks, @bentley!

Now I’m running into an issue with using the unload event to respond to user navigation. We want to have separate handling for when a user closes the board bar (clicking the ‘x’ to close), versus navigating away from the board. However, the unload event fires on both actions and it happens before the callback function is fired (which is how we’re handling manual closing of the board bar). So if we cancel processing on unload, it doesn’t matter what happens in the callback since the background process will have already been discontinued at that point. Any thoughts on how this might be handled?

Right, the callback is called only after we’ve already torn the DOM down.

Unfortunately, I don’t think that there is a better, more obvious way to work with this.

Again, our general recommendation is to push long-running processing to an async service.