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
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.
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.
Perhaps of some use: http://www.oracle.com/technology/pub/articles/dev2arch/2006/01/ajax-back-button2.html?_template=/ocom/print
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.
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1799
Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs. keyword: new = Tracking + FutureFeature + SubBug
making sure we're not missing any bugs in rhq_triage
Closing per 19-Aug triage -- this bug will be made obsolete per UI redesign.