Bug #13674
openInconsistant behavior with HTML fragment identifiers and internalPathEncoding
0%
Description
I noticed that Wt behaves inconsistent when using HTML anchors with fragment identifiers. Assume calling a page http://localhost/path#fragment
in the browser. The path http://localhost/path
is submitted to the server, gets set as the internal path, and gets handled by the application. After returning the result, the browser subsequently handles the fragment identifier fragment
and jumps to the appropriate element. So far, so good...
If I have an anchor <a href="#/path#fragment">link</a>
on the page and internalPathEncoding
enabled, clicking the link will change the internal path to /path#fragment
instead of just /path
. The fragment identifier is suddenly a part of the applications internal path - in contrast to to the first case. This leads to issues when handling the internal path in the application, since now an unexpected fragment identifier is part of the new internal path. It is, of course, possible to manually handle that case and extract the fragment identifier before processing the internal path, but having to deal with that inconsistent behavior doesn't seem to be ideal, as the needed logic to handle internal path changes would depend on the exact circumstances under which the path got updated.
I attached a small demo application to demonstrate the issue. Calling the page as mentioned in the first paragraph does not propagate the fragment identifier to the application, clicking the link does.
I think it might be best to handle that case internally, so that fragement identifiers are never part of the internal path, like them getting extracted before emitting the internal path changed signal, This would lead to consistent behavior. Since fragment identifiers are not submitted by the browsers, it furthermore seems like the only way to achieve consistent behavior.
Best,
Steven
Files
No data to display