thinking about this problem over the weekend:
1. the current flow is that the IFrame basically changes location, right before it does - it sends the message to the parent. The parent does pushState, so you effectively have two states - the state actually generated by the click event and the second one that was created by the pushState.
2. I thought of a stupid workaround, basically hooking into the popState event and going back one extra time if it sees it was originally pushed by the code (pretty easy). The problem is that it looks like the popState event only gets called during the second (good) back command is issued. Still thinking about how to approach it.
3. This is what someone else did (it's a bit convoluted, basically removes the original request, creates a new cloned iframe off-DOM and then reconnects it, so it doesn't get entered into the history stack).
https://stackoverflow.com/questions/397 ... wo-entries
history state (due to pushState) issues
- axew3
- w3all User
- Posts: 2883
- Joined: Fri Jan 22, 2016 5:15 pm
- Location: Italy
- Contact:
Re: history state (due to pushState) issues
i will try to dedicate something today if possible, to fix this and the loop: substantially to me, the suggested way about this in my previous post, is the unique necessary: assign the correct url when you land into wp page forum, which do not happen now: so if you land into a topic, then you follow navigating, then you return back, you'll return back only until the first click, because the one of where you landed, isn't pushed in the code as is.
The other aspect to check, is just the overall_footer added code: is it avoiding to pass the value to parent, when instead should do?
These aspects i will check only, i'm sure these are the unique things we'll have to fix.
The other aspect to check, is just the overall_footer added code: is it avoiding to pass the value to parent, when instead should do?
These aspects i will check only, i'm sure these are the unique things we'll have to fix.
- axew3
- w3all User
- Posts: 2883
- Joined: Fri Jan 22, 2016 5:15 pm
- Location: Italy
- Contact:
Re: history state (due to pushState) issues
So tested the think, and all should now be fixed. A more deep test can confirm.
The code is running also into this online, just updated the page-forum with this last version here in attach.
The problem was that the code, when landing into any page, was not pushing the url to history.
In the attached and modified page-forum that is running right now also here online, has been added the following code on bottom, right before the closing </script > tag:
note that the
jQuery( window ).load(function() { instruction wrap the code: if you remove, the url is NOT correctly pushed to history.
Also note that i copied/cloned the w3allNormalize_phpBBUrl function, used on overall_header and overall_footer, and added into page forum on header, ready to be used also here in this context, so on page forum, to push correct values, and i named it w3allNormalize_phpBBUrl_onParent (you can see it on top where js of the header output is).
this is the new page-forum:
ps: the last jQuery('#w3_toogle_wrap_loader').attr( \"class\", \"w3_no_wrap_loader\" ); line of code, of course is not related this problem, i have just put it there because i still experience the problem on removing the preloader screen sometime, which i have not still well understand why/when it occur). Or to better say, it come out due to possible js errors, both on wp templates or phpBB. A way to resolve this will be applied soon.
p.s your subsequent question is maybe: why if it is not wrapped inside jQuery( window ).load(function() { won't work?
My answer is: i do not know exactly, but as you also argued before, i assumed that the history push was not doing his work correctly may because fired too soon. There are many possible answers for this. But i will not go to confuse you further more with my assertions.
I imagined it could come out due to the fact that the timing when the instruction execute, may goes to conflict with something else or because it was running before something else, that was rewriting the thing in some way. Now it work.
The code is running also into this online, just updated the page-forum with this last version here in attach.
The problem was that the code, when landing into any page, was not pushing the url to history.
In the attached and modified page-forum that is running right now also here online, has been added the following code on bottom, right before the closing </script > tag:
Code: Select all
jQuery( window ).load(function() { // wrapped here, or won't push correctly
var w3all_landed_url = '".$w3all_url_to_cms."';
var w3all_landed_url_clean = w3allNormalize_phpBBUrl_onParent(w3all_landed_url);
// PUSH phpBB URLs when wp page load first time //
var w3all_passedurl = window.btoa(unescape(encodeURIComponent(w3all_landed_url_clean)));
var w3all_passedurl_push = '".$w3allhomeurl."/".$wp_w3all_forum_folder_wp."/?".$w3all_iframe_custom_w3fancyurl."=' + w3all_passedurl;
history.pushState({w3all_passedurl: w3all_passedurl_push}, \"\", w3all_passedurl_push);
jQuery('#w3_toogle_wrap_loader').attr( \"class\", \"w3_no_wrap_loader\" );
})
jQuery( window ).load(function() { instruction wrap the code: if you remove, the url is NOT correctly pushed to history.
Also note that i copied/cloned the w3allNormalize_phpBBUrl function, used on overall_header and overall_footer, and added into page forum on header, ready to be used also here in this context, so on page forum, to push correct values, and i named it w3allNormalize_phpBBUrl_onParent (you can see it on top where js of the header output is).
this is the new page-forum:
ps: the last jQuery('#w3_toogle_wrap_loader').attr( \"class\", \"w3_no_wrap_loader\" ); line of code, of course is not related this problem, i have just put it there because i still experience the problem on removing the preloader screen sometime, which i have not still well understand why/when it occur). Or to better say, it come out due to possible js errors, both on wp templates or phpBB. A way to resolve this will be applied soon.
p.s your subsequent question is maybe: why if it is not wrapped inside jQuery( window ).load(function() { won't work?
My answer is: i do not know exactly, but as you also argued before, i assumed that the history push was not doing his work correctly may because fired too soon. There are many possible answers for this. But i will not go to confuse you further more with my assertions.
I imagined it could come out due to the fact that the timing when the instruction execute, may goes to conflict with something else or because it was running before something else, that was rewriting the thing in some way. Now it work.
-
- User w
- Posts: 10
- Joined: Wed Jan 27, 2021 2:24 pm
Re: history state (due to pushState) issues
The version on this site still exhibits the problem.
Please see here:
https://www.youtube.com/watch?v=dJ9tOCy ... e=youtu.be
The issue is not just on the front forum page, it is on every A href click.
BTW, very cool on the recorder!
Please see here:
https://www.youtube.com/watch?v=dJ9tOCy ... e=youtu.be
The issue is not just on the front forum page, it is on every A href click.
BTW, very cool on the recorder!
-
- User w
- Posts: 10
- Joined: Wed Jan 27, 2021 2:24 pm
Re: history state (due to pushState) issues
BTW, you can use the history state to make sure that you're not in a loop. If you see that the last state is the exact same location, you're running in a loop.
- axew3
- w3all User
- Posts: 2883
- Joined: Fri Jan 22, 2016 5:15 pm
- Location: Italy
- Contact:
Re: history state (due to pushState) issues
the problem was into any landed page: for landed page, i mean the very first phpBB page loaded due to explicit direct url to a post, a topic or index.php. Now it has been resolved. And return ever the corect result, but not on address bar, ok now it is clear the meaningThe issue is not just on the front forum page, it is on every A href click.
Thank you for the video explain, perfect, i will go to check how to resolve asap and return back here!
yes! the recorder will be useful/nice!