Bug #13067
openThe internalPath show incorrectly in the browser Inspect Network
0%
Description
Hello,
I've encountered a strange issue when using internalPath.
If you open a website built with Wt (it doesn't matter whether it's Wt version 3 or Wt version 4, I've tested both) in a browser, and go to the Network tab in Inspect, then filter the logs related to our site, you’ll see that for every change in internalPath, no value is recorded in the Path or URL columns.
However, if you log in to the site using the WAuth system in Wt, the logs are correct, and the internalPath is recorded properly in the Path or URL. (This correction remains valid as long as we do not refresh the browser or use the browser's back button. Navigation between the site's pages should only be done using the site's menu buttons.)
As soon as we refresh the browser (even though we are still logged in), the issue returns, and once again all logs are recorded without the internalPath in the Network tab.
I have tested this issue in both Wt 3 and Wt 4, and the problem persists.
I also reviewed the site "emweb.be" that built with Wt 4, and it had the same issue.
I have attached screenshots from this site that show the problem.
In normal cases, without logging in to the site, all logs are recorded with an empty internalPath.
(Images 1-3)
But as soon as we log in to the site, the internalPath is correctly recorded in the logs. (To keep this corrected state, we should not refresh the browser or press the back button; navigation should only be done using the site's menu and anchors.)
(Images 4-7)
As soon as we refresh the browser, even while logged in, the logs are recorded with an empty internalPath.
(Additionally, if the Path and URL columns are not visible in the Network tab of Inspect, you can right-click on the columns and enable the Path and URL columns.)
Files
Updated by Matthias Van Ceulebroeck about 2 months ago
- Target version set to 4.11.2
I believe this is a side-effect of loading the page with bootstrapping. You access any page, at which point the application is not yet aware of what its deployment path is.
I will investigate this a little further, since I do think that image 3 and 4 do exhibit unexpected behaviour.
Updated by Romain Mardulyn 3 days ago
- Status changed from New to InProgress
- Assignee set to Romain Mardulyn
Updated by Romain Mardulyn 1 day ago
- Status changed from InProgress to Review
- Assignee deleted (
Romain Mardulyn)