Bug 535063 (RHQ-1799)

Summary:	Left Nav: If focus already exists on elsewhere in left nav, clicking an expander instead navigates user to focused area.
Product:	[Other] RHQ Project	Reporter:	Corey Welton <cwelton>
Component:	Usability	Assignee:	Corey Welton <cwelton>
Status:	CLOSED WONTFIX	QA Contact:	Corey Welton <cwelton>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	1.2	Keywords:	SubBug
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	All
URL:	http://jira.rhq-project.org/browse/RHQ-1799
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-08-20 15:22:35 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	565628

Description Corey Welton 2009-03-17 18:30:00 UTC

Steps to repro:

1. Login and navigate to a large treeview containing a variety of different expanders.
2. Click on the text for one of these inventory items -- "Network Adapter", for instance.
3. Wait for that page to render; hit the browser back button.
4. When returned to the tree, click one of the "(v)" down arrows to expand an inventory item.  
5. View results

Current results:
* Focus remains on the previously viewed inventory item.
* Clicking the down arrow does not expand current inventory item.  Instead, it submits an OnClick for the old inventory item -- user is taken back to the page previously viewed.

Expected results:
* Focus is given to the correct inventory object and it is expanded

Comment 1 Joseph Marques 2009-03-18 11:51:15 UTC

corey, can you find a bug *without* using the back button, or does this oddity only occur when using the back button?  if this only happens when you use the back button, i'm inclined to close this jira out because there are MANY parts of the UI that will not work with the back button (either because of ajax-y nature of the components and partial page rerenderings, or that fact that we're submitting forms and get repost warnings, etc).  we are not attempting to solve these types of back button issues, because it should be the responsibility of the richfaces component writers.  and, since those components don't have natural back button handling to the degree you're looking for, issues of this type will always fall into either the "won't fix" or "not an issue" bucket.

Comment 2 Corey Welton 2009-03-18 12:59:59 UTC

Saying that "we do not support the back button" is not a valid response in any web application.  The back button is there.  Users will use it.  In this case I'd even posit that it's a fairly valid use case -- this was part of normal usage, versus any sort of "test-to-fail" effort.

If there is a problem with the libraries we are using, it seems to me that we should be considering workarounds for these deficiencies.  

I will move this to the usability queue for now.

Comment 3 Corey Welton 2009-03-18 13:12:18 UTC

Perhaps of some use:

http://www.oracle.com/technology/pub/articles/dev2arch/2006/01/ajax-back-button2.html?_template=/ocom/print

Comment 4 Joseph Marques 2009-03-21 10:59:01 UTC

it's a short-coming of the underlying framework.  i'll investigate whether it's possible to intercept these requests and properly manipulate the dom history to better support back-button functionality.  however, this won't be happening in the 1.2 timeframe.

Comment 5 Red Hat Bugzilla 2009-11-10 20:46:52 UTC

This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1799

Comment 6 wes hayutin 2010-02-16 16:56:40 UTC

Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs.

keyword:
new = Tracking + FutureFeature + SubBug

Comment 7 wes hayutin 2010-02-16 17:01:52 UTC

making sure we're not missing any bugs in rhq_triage

Comment 8 Corey Welton 2010-08-20 15:15:25 UTC

Closing per 19-Aug triage -- this bug will be made obsolete per UI redesign.