1629096 - nsFocusManager should always respect scroll-padding/margin.

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Emilio Cobos Álvarez (:emilio)]

Attachment: t.html

Consider the attached test-case. Tab forward then backwards.

When tabbing forward, you always see the focused input. when tabbing backwards you don't. I don't think that's acceptable. That's what these properties are supposed to solve in the first place.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1629096 - Always honor scroll-margin / scroll-padding from nsFocusManager. r=hiro,masayuki

We should always do this, otherwise stuff may not end up being visible which is
not acceptable for focus navigation.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1629096 - Honor scroll-padding / margin in ns{ListControl,MenuPopup}Frame. r=hiro

Kinda drive-by, but I think this is sane and not risky... This is used for
<select size> / <select multiple>, and only scrolls the option into view (it
only scrolls a single scroll frame, the one inside the <select>).

If the author specifies scroll-padding / margin in there I don't see why we
shouldn't respect it when doing key selection / navigation / etc.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/df36546db7e4
Honor scroll-padding / margin in ns{ListControl,MenuPopup}Frame. r=hiro

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cf4823d69b53
Always honor scroll-margin / scroll-padding from nsFocusManager. r=masayuki

Comment 5

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/df36546db7e4
https://hg.mozilla.org/mozilla-central/rev/cf4823d69b53