The test case at <http://home.arcor.de/martin.honnen/mozillaBugs/domLevel0/onfocusLocationHashTest1.html> sets the location.hash property of the right frame in the onfocus handler of the input controls in the left frame. That works fine to scroll the right frame to the anchor with Firefox 1.0, IE 6 and Opera 9. With later Mozilla versions, including Firefox 2.0 and Firefox trunk nightly (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070407 Minefield/3.0a4pre), it does not work, the right frame is not scrolled to the anchor when location.hash is being set.

Works: 2005091723 Fails: 2005091804 Regression window: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2005-09-17+22%3A00&maxdate=2005-09-18+05%3A00 Appears to be caused by bug 105894.

Indeed; in this case we're suppressing _all_ scrolls (and for all frames in the frame tree), whereas we should only suppress the actual focus scroll to the actual element being focused, or at least in only the one window...

I think that nsFocusScrollSuppressor is also suppressing the non-focus scroll now. PresShell::ScrollContentIntoView is always checking the result of GetSuppressFocusScroll. Probably, this is a cause of this bug. The ScrollContentIntoView should have an additional parameter which is |PRBool aByFocusSet| or something. And the caller of it which is called by SetHash's should set the new param to PR_FALSE. At that time, ScrollContentIntoView should not check the result of GetSuppressFocusScroll. But I'm not sure where is the caller which is called from SetHash.

Smaug, do you think you could look into this regression for 1.9.2? If not, please let me know.

The testcase works for me on trunk (not on 1.9.1). I guess this was fixed by the focusmanager. Marking WFM, though if someone confirms that it was really the focusmanagar patch which fixed this, RESOLVED FIXED would be more correct.