Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 336261

Summary:	[client] [Chrome] Forward button doesn't work in navigator
Product:	[ECD] Orion	Reporter:	Mark Macdonald <mamacdon>
Component:	Client	Assignee:	Susan McCourt <susan>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	bokowski, simon_kaegi
Version:	0.2
Target Milestone:	0.2
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Mark Macdonald

2011-02-03 11:57:47 EST

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.

Comment 1 Mark Macdonald

2011-02-04 09:54:30 EST

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.

Comment 2 Susan McCourt

2011-02-07 12:38:03 EST

I'll take a look as part of bug 334195.

Comment 3 Mark Macdonald

2011-03-09 12:01:39 EST

*** Bug 339392 has been marked as a duplicate of this bug. ***

Comment 4 Susan McCourt

2011-04-04 19:06:21 EDT

(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.

Comment 5 Susan McCourt

2011-04-04 19:10:45 EDT

(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.

Comment 6 Susan McCourt

2011-04-05 13:00:08 EDT

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.