Infinite (and unnecessary) error/unauthorized loop on browser / History back

[Clay Harris]

Hi, I posted to StackOverflow when I first came across this, and haven't been able to resolve it.  In short though (since multiple iterations / updates in SO may be confusing):

I added a new Presenter/View, with a nametoken and ProxyPlace.  It is nested inside another presenter with a header, and places its content using setInSlot(PresenterWidget).  PlaceRequest navigation works fine going to it, but when History.back() is called or the browser's back button is used from the page, I get the stacktrace listed in the SO post - basically your standard infinite error/unauthorized place loop.  But I don't know why - the Error and Unauthorized places are both bound to a presenter that works (I can browse to it using the nametoken) and has no gatekeeper.  

The real issue is that there is no reason for this to occur in the first place, except that for some reason an error occurs in the placemanager (using custom, or DefaultPlaceManager).  The app navigates back and operates normally, most of the time.  But occasionally in firefox, one of my presenters breaks, and its lifecycle stages don't get called, I'm assuming because the placemanager broke.

I've been fighting this off and on for a while now, and it's really driving me up the wall.  What am I missing??

Thanks,

Clay Harris

[Clay Harris]

Just realized I'm getting the infinite loop error any time I use the browser back button, not just on the page I thought was causing it.  So basically - it's worse than I thought and I have even less of an idea what's going on, hah.

[Maxime Mériouma-Caron]

Hi Clay!

Basically that error happens when you are trying to reveal an error place when you are in the process of revealing an error place. Most common reason is an invalid nametoken. If you're using the DefaultPlaceManager and the ErrorPlace binding, ensure that the ErrorPlace's nametoken is valid.

On Tuesday, April 28, 2015 at 10:17:44 AM UTC-4, Clay Harris wrote:

[Clay Harris]

Hi Maxime, I didn't think about possible concurrent reveals!  Definitely worth looking into.  Not sure how it would happen, but worth looking into.

The errorplace is definitely valid though.  I made sure it, and the supposedly invalid nametoken being passed into revealErrorPlace, were valid.  As a short term fix I just overrode revealErrorPlace, and log instead of doing anything, as it wasn't working anyway, and just created log spam that was rather unhelpful.  

It looks like my whole module is trying to reveal the error place when the browser back button is used, though the app is working fine otherwise.  We have another module that isn't doing that at all.  Any idea what could cause that?

--
You received this message because you are subscribed to the Google Groups "GWTP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gwt-platform...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Christian Goudreau]

Those errors are most of the time linked to how ErrorPlace and Unauthorize place are being used. Sometimes it may be that the place trying to be revealed with the revealDefaultPlace use the default gatekeeper and that the user doesn't have access to it, then it fall back to Unauthorized place which is either the default place (if it's unbound which can be secured and then, you get an infinite loop) or that the unauthorized place doesn't exist and then error place is being revealed. From the stack trace in your stackoverflow question, you have trace of unauthorized place in it.

If you want us to help you more, we may need to look into your code and we could do that through our support package (NDA is included) http://www.arcbees.com/#!/support . No worries about the packages, we can craft one specifically for this support case. Just write directly to me if you're interested: christian.goudreau@arcbees.com

Cheers,

Christian Goudreau | CEO - Président

M: 1.877.635.1585

ArcBees | Blog | Facebook | LinkedIn