Community
Participate
Working Groups
Orion 0.2M5 Chrome 9.0.597 1. Log into Orion. You're at the top level of your workspace. 2. Drill into a folder by clicking its name. 3. Click Back. 4. At this point I expected to be able to click Forward to return to the folder, but the Forward button is disabled. In Firefox/IE/Safari, step 4 works as I expected. Only Chrome seems to have this problem.
This isn't just a problem with the navigator. It also happens if you're going "Back" to coding.html#whatever in Step 3. Perhaps the input service is the culprit, since it's used in the nav and coding pages, and it does some hash management.
I'll take a look as part of bug 334195.
*** Bug 339392 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > This isn't just a problem with the navigator. It also happens if you're going > "Back" to coding.html#whatever in Step 3. Perhaps the input service is the > culprit, since it's used in the nav and coding pages, and it does some hash > management. The input service no longer exists, so I've ruled that one out. It is indeed specific to chrome and I suspect it's a bug in the dojo.hash implementation on Chrome. For fun, I tried a scenario with jazz and it has the same problem. For example, if you go to https://jazz.net/jazz/web/projects/Jazz%20Foundation#action=com.ibm.team.workitem.viewWorkItem&id=64273 Then click the tabs in the work item to view things like "links" or "history". Then use the browser history to go back. You'll see the exact same problem. I didn't find a bug report in my first attempts at searching, but I'll look deeper.
(In reply to comment #4) > Then click the tabs in the work item to view things like "links" or "history". > Then use the browser history to go back. You'll see the exact same problem. I swear I saw this but now can't reproduce. Will dig further.
Fixed. Long ago, we called hash from within the navigator when reloading the nav tree in loadResourceList. Somewhere along the way, we changed this to call dojo.hash(url, true) which keeps the hash change out of the history (maybe we had duplicate entries in the history?). There is a problem with using this parameter on Chrome. In fact, the documentation is a little vague, and seems to suggest that the true parameter doesn't mean "keep the hash change out of history" but means "please replace the current history state." "To update the hash without creating a new entry in the back history, pass true as the second (replace) param. This will update the URL to the new hash, and will replace the current history state:" So we were blowing away the history on Chrome when using this call. At any rate, it's not necessary to call hash from within the navigator anymore. The navigations from the table, favorites, and breadcrumbs are all real links anyway, so the hash gets changed and then this method is called on hash change. The fix is to remove the call altogether.
