Support #2418
openhelp with handlePathChange and the back button
0%
Description
Hello, I have code derived from the hangman example. This is in first application and I'm trying to understand the browser 'back' interaction. Here in the constructor for my application as per hangmanGame:
Wt::WApplication::instance()->internalPathChanged().connect(this, &myApplication::handlePathChange);
authWidget->processEnvironment();
...
And then in the handler I have put a message:
void myApplication::handlePathChange(const std::string &new_browser_path){
std::cout << "request to change path to (arg): " << new_browser_path << std::endl;
}
In google-chrome:
in my application after the user logs in I get a login event (good) where in the login even handler I change the internal path to 'page1' without generating another event (false last argument on internalPathChange), then show a a simple page, page1, that has a button for going to a second page. That comes up with the correctly with the new internal path showing in the browser as /?_=page1 and the correct page contents shows with the button. All is good.
Then when pressing the buttonn it is connected to another that method that change the internal path without generating an event (false last argument on internalPathChange) and the browswer then correctly shows as /?_=page2 with the correct contents. Still all is good.
Now while on page2 I hit the back button. The browswer then shows the link as /?_=page1 which is correct, however the contents is still that of page2. This is because the handler did not get invoked. In the stub showing above the message does not print, and in gdb if I set a break point on the handler, the debugger never hits the break point.
Now back in the browswer if I hit page refresh for a non-cashing refresh, the handler is still not invoked (no message and no break point trip), the browser still shows /?_=page1 --- however Wt shows the authentication widget again asking for a login and password (??). .. If I log in I am starting all over from the beginning of the application - the internal path change handler is never called.
Well now doing the experiment again, I go to page1 then to page2, hit the back button and the browser says page1 but is showing page2 and no handler event as before --- then I go ahead and hit the back button a second time. Now the browser just shows 127.0.0.1:9090 as the path (correct) and finally the path change handler is invoked. YES! However, I never got to update the page on the first click of the back button.
Now as a last example, I go to page1, then to page2, all it good. Then back to page1 (same behavior as before still showing page2 contents with a page1 link) then forward to page2 .. then the browser link window shows /?_=page2 as it should, and as the contents never changed it is correct. However, there is never a internal path change event handler invocation. I can go back and forth as many times as I like and the link shows correctly in the browswer, but I never get an internalPathChanged event - or at least the handler is never invoked.
What the heck am I doing wrong here?
Files
Updated by Koen Deforche almost 11 years ago
- File bug2418.cpp bug2418.cpp added
- Status changed from New to Feedback
- Assignee set to Koen Deforche
Hey,
Now while on page2 I hit the back button. The browswer then shows the link as /?_=page1 which is correct, however the contents is still that of page2. This is because the handler did not get invoked. In the stub showing above the message does not print, and in gdb if I set a break point on the handler, the debugger never hits the break point.
That sounds like a bug in Wt. What version of Wt is this? I couldn't reproduce it, see attached test case.
Now back in the browswer if I hit page refresh for a non-cashing refresh, the handler is still not invoked (no message and no break point trip), the browser still shows /?_=page1 --- however Wt shows the authentication widget again asking for a login and password (??). .. If I log in I am starting all over from the beginning of the application - the internal path change handler is never called.
This starts a new session. If you didn't remember you login it will thus get back to the login screen. And this is not considered an internal path change since the path didn't change within the new session.
Well now doing the experiment again, I go to page1 then to page2, hit the back button and the browser says page1 but is showing page2 and no handler event as before --- then I go ahead and hit the back button a second time. Now the browser just shows 127.0.0.1:9090 as the path (correct) and finally the path change handler is invoked. YES! However, I never got to update the page on the first click of the back button.
The browser is probably switching to a previous session. In a non-properly working application this will be confusing since to a user there is no real difference but the browser will do something entirely different (i.e. load a new session).
Regards,
koen
Updated by Thomas Lynch almost 11 years ago
Thank you for that example. You make it look so simple. I changed it to be more like my application .. and it still works.
FYI version, /usr/lib64/libwt.so -> libwt.so.35
I'll have to see if I can't make a test case out of the bigger application that has the problem (take out the patch and work backwards).