show ‘one moment please’… refresh your page, then detect it before doing anything else, and then redirect to the specific page… insane?
image.png3073×984 329 KB
Here’s an example of what happens. In fact, there is a progress bar going… But how do I know when the progress bar is not displayed (and no actions are pending) so that we can safely and silently redirect? Image:
image.png2298×1416 206 KB
What I find is that – on my desktop system – if I set that final pause to be 2000 ms, this gives the progress bar time to complete and the redirect will in fact happen without a nag. However, this isn’t the right way to do things as the time required is dependent on a huge number of factors.
Watching: Gmail changes you made may not be saved
So, I guess the question is: How do I detect the same state that httl.com.vn/en’s “Leave Site?” dialog is detecting? (That is, the state of no workflow actions being pending.)
neerja November 6, 2018, 10:08pm #29
keith For most apps, this is straightforward but if you have an app where timing of multiple actions is critical and the completion of it is not intuitive, please share that test app so we have a reproduction case.
JohnMark November 6, 2018, 10:11pm #30
If process time is the challenge, you must do everything you can to create your workflows on schedule API. The progress bar has to be under 2 seconds, not 15 seconds or more.
keith November 6, 2018, 10:48pm #31
It’s not stuck or anything. It completes in a second or two. It’s just we cannot know when the processes represented by that bar are complete. (But annoyingly, httl.com.vn/en knows and so throws the Leave Site warning.)
Basically I need the equivalent of “await” for the previous workflow steps. Often, inserting pauses is a sufficient way to mimic that, but apparently not in this particular example.
JohnMark November 6, 2018, 11:17pm #32
I didn’t try that one, maybe it can help? I’m in patching mode!
edit: just bought. Works great.
keith November 6, 2018, 10:55pm #33
It’s the same app and page I noted in the bug report,
neerja. The only thing I can think here that might be messing up the synchronous nature of this workflow is the Schedule API Workflow step. (Question: Do those steps return a value? I’m away from my machine at the moment, but that’s my next thing to look at.)
JohnMark November 6, 2018, 11:36pm #34
According to the plugin, it sounds to have a returned value.
events:
edit : just realized they have two products:
keith November 7, 2018, 1:51am #35
Actually (mostly for
neerja one more thing: There’s something that’s gotten completely lost in this discussion…
You will note that in my original post and my bug report, I talk about TWO workflow steps.
The first is NAVIGATE to external page. That step ALWAYS succeeds silently and NEVER throws the “Leave Site?” dialog. (Using Navigate is useful, but Navigate can only change the URL displayed in the container, not the container’s parent. So, if my widget if hosted in an iFrame I need to also / instead of use a second technique – Run JavaScript – that allows me to access the parent window to do the redirect/replacement).
Why is it that Navigate always works and never causes the “Leave Site?” dialog to appear? This is just a wild-ass guess, but I assume that internally, Navigate is awaiting the completion of any promises that are outstanding in the page.
The fact that Navigate does not trigger the warning and that my alternative redirect options do is what lead me to surmise that the triggering had something to do with accessing parent.window.
The thing that does cause the “Leave Page?” dialog to be triggered is redirect technique #2:
If I need to redirect not just in the iFrame, but in the hosting container (that is, the browser of the user who is visiting one of my customers’ pages, upon which my widget is iFramed), I cannot use Navigate. Navigate does not enable opening a URL in a new tab (which is the same thing as “the container of my current reference container”).
See more: Cmj New Music Report – Comment Accéder Au Webmail
So I must use Run JavaScript to execute that redirection. There are several ways to do this, but all behave the same way. Currently, I’m executing parent.window.location.replace(“redirect_url”); but other similar functions all have the same behavior.
Run JavaScript does not have easy access to pending promises. So it would seem that, even if I put a pause in front of the Run JS action in my workflow, and in front of all other steps in my workflow, there are still some things are awaiting completion that I cannot easily await.
(I get that there’s a somewhat hacky solution: I’ve seen that the progress bar has a class and I suppose one could run a function to make sure that element does not exist / wait until that element goes away before proceeding with the redirect.)
But that seems like a very un-httl.com.vn/en-like solution to the problem of delaying a workflow step until we are no longer awaiting completion of previous actions, right?
In fact, I can’t find a native httl.com.vn/en way to make such a delay happen. Outside of inserting pause actions (which for whatever reason does not properly delay execution), the only thing left is to make workflow steps dependent on some prior step.
I’m pretty sure that the one that’s the hang up is “Schedule API Workflow”. While this is undocumented, it seems that Schedule API Workflow DOES return a value as the results of its step. The data type is text, but the text is always null AFAICT. Also, that null value seems to be returned immediately (that is, the return value is not just information free in itself, but also gives us no timing information).
So in the experiment of, “OK, well let’s ensure that all downstream actions are only executed when Schedule API Workflow has completed” is not something we can do. Because looking at “results of step x ‘Schedule API Workflow’” always just shows us a null value.
Here’s the example: Step 9 kicks schedules an API Workflow:
The console reports that our custom state is null. In fact, this value is printed to the console almost immediately. And, even though all of our preceding steps MUST have executed (all of them are involved in assembling the data that we are now sending to the API Workflow), we now know that it is, in fact step 9 that’s the fly in the ointment here.
Step 9 gives us a return value of null immediately and, so, all downstream workflow steps are free to continue. These steps are very lightweight and seem to complete a short time before step 9 is actually done, causing us to reach step 17 nearly instantaneously:
As you can see, we’ve already gotten to the point where the JavaScript redirect is triggered (by a Custom Event that I’ve not shown above). The blue progress bar (though it will not take long to complete) must represent our friend Step 9.
Now, in the demonstration above, we’re triggering the JavaScript redirect. Here’s the OTHER version. Let’s say that I now change my preferences such that we will execute the Navigate redirect instead (and, in fact, I’ve just done that in my backend). Here’s what happens in that case:
In this case, the JS redirect will not fire, but the Navigate redirect will. Here are those workflow steps in the separate Custom Event workflow triggered by the boolean state (step 17) of the workflow we examined above:
What I observe in that case is that, in fact, there’s a slight delay before the redirect happens. It’s clear that “Open an external website” is aware of pending processes and only proceeds once those things are complete.
So, a couple of potential httl.com.vn/en enhancements that would solve my issue (and possibly the issues of others who have run into this behavior):
Give “Open an external website” an option for “open in parent’s window” (this would be helpful – and not problematic in terms of popup blocking – when the current container is an iFrame).
Give us a version of pause that is process-aware. Basically, a workflow action that does whatever it is that the internal code of “open in parent’s window” is doing prior to actually executing the redirect action.
See more: How To Prevent Emails From The Same Sender Being Grouped, Stop The Email Threading Madness
After having given this a really close look, I do agree that it’s unwise to be able to override “Leave Site?” but on the flip-side, we need some sort of httl.com.vn/en-native way to do that same evaluation and only trigger fancy redirection actions once safe to do so (if we desire to do them silently, which we do!).
Categories: Mail