2003060409 trunk 1. Go to URL and click on the "Search" button. 2. Click on any result in the list. 3. Press the "Back" button to go back to the result list. 4. Press "Back" again to go to search page. RESULTS: Session history gets horked. Sometimes back button disables itself, other times it stays enabled, but clicking back does nothing.

I think this is affecting the JSRS remote scripting library at http://www.ashleyit.com/rs/ . I also think I tracked down when it broke. I tested Mozilla Firebird builds from 5/23 and 5/25 (no win32 build was created on 5/24). The build from 5/23 works fine and the one from 5/25 doesn't. So, somewhere in these changes is where the bug happened.. http://tinyurl.com/eaj3 Here's a good test page: http://www.ashleyit.com/rs/jsrs/select/php/select.php Note that in order to reproduce the bug, you might need to visit this page with a brand new brower window. That is, shut down all browsers entirely, open up a new browser, and go to that page. Then go through the select boxes and after each time selecting something and getting some results to select in the next select box, check the contents of the "back" button. They should be filling up with links to source of the <iframe> navigation which should never happen. When fully working, the back button should stay grayed out the entire time. This is also affecting a servlet application framework called Barracuda ( http://barracudamvc.org/ ) which uses JSRS to, optionally, disable the back button upon form submits. It would be very bad to have a release of Mozilla that breaks functionality that has been working for so long. this also seems related to bug 207793 . I will test it out after I submit this message. Jake

hmmm... maybe bug 207793 isn't related? I'm not seeing a difference between the 5/23 and 5/25 builds....unless I'm not understanding how to reproduce the test case in that bug? Jake

This was working just fine in the last MozillaFirebird release (0.6) and all releases prior to that. In fact, any release based on Mozilla prior to build from 5/25 (or maybe 5/24) worked perfectly. The last good release was MozillaFirebird on 5/23. Should be easy to find the culprit with that information. I'm not setting the target milestone or priority because I don't own the bug (nor do I have any idea how to fix it), but I am moving severity to major since it breaks behavior counted upon in all previous releases. Can someone please prioritize this and, hopefully, not let an official full release of Mozilla or MozillaFirebird out the door with this issue left unresolved? Jake

Well, now Mozilla 1.4, Mozilla 1.5alpha, and MozillaFirebird 0.6.1 have all been released with this bug. Let's not let this into any more official releases. This shouldn't be difficult to track down since I've pinpointed the date at which the bug seems to have appeared; 5/24 or 5/25 (since builds from 5/23 work fine). Can this bug please get some attention? Jake

Is bug 148794 related to this? Jake

Yes, please duplicate. Buttons are not really dead, you just have to click a lot of times to get back. The patch for #148794 broke more than it fixed, so it was taken out around 24 May.

*** This bug has been marked as a duplicate of 148794 ***

Reopening per bz's comment in bug 148794 comment 48 where he says that this issue is distinct from that bug. Unfortunately, I don't have a minimal testcase. Hopefully I or someone else can come up with one in short order. Jake