Closed Bug 376785 Opened 17 years ago Closed 15 years ago

setting location.hash of frame does not scroll the frame to the anchor

Categories

(Core :: DOM: Core & HTML, defect, P2)

x86
Windows XP
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
status1.9.2 --- beta1-fixed

People

(Reporter: martin.honnen, Assigned: smaug)

References

()

Details

(Keywords: regression, testcase)

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.
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...
Flags: blocking1.9.2?
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.
Assignee: general → Olli.Pettay
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P2
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.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Flags: in-testsuite?
Flags: in-testsuite? → in-testsuite-
You need to log in before you can comment on or make changes to this bug.