1611683 - Element.scrollIntoView does not follow spec handling "null", "{}" input arguments

Status: RESOLVED FIXED

(SeaMonkey :: General, defect, P3)

Description

[bblack]

+++ This bug was initially created as a clone of Bug #1389274 +++

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36

Steps to reproduce:

See spec test result here:

http://wpt.fyi/cssom-view/scrollIntoView-empty-args.html

Actual results:

The scroll goes to "nearest" or "end". I am not sure but either way it is incorrect.

Expected results:

In particular the tests fail when input is either "null" or {}. In this case according to the spec [1] the method should use default values in ScrollIntoViewOptions which is "center".

dictionary ScrollIntoViewOptions : ScrollOptions {
ScrollLogicalPosition block = "center";
ScrollLogicalPosition inline = "center";
};

[1] https://drafts.csswg.org/cssom-view/#dictdef-scrollintoviewoptions

Comment 1

[bblack]

We need a backport for 2.53

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Please don't play with bugzilla? Use the dev instance for that.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Oh unless this is really about seamonkey, carry on then, sorry.

Comment 4

[Boris Zbarsky [:bzbarsky]]

But then please don't cc random people....

Comment 5

[Frank-Rainer Grahl (:frg)]

bblack Just put an NI in the bug which needs a backport. Generates bugspam in old bugs like this one here.

Comment 6

[bblack]

Sorry, I was trying to open up a new bug. I clicked on New "... as a clone, in a different product" because I thought it was right for this one.
I took the others out of cc.
I didn't know that the old bug would take them over automatically.

Comment 7

[bblack]

Open it again, because hopefully the others will not be bothered anymore.

Comment 8

[bblack]

ScrollContentIntoView has all the features we need to make scrollbox.xml and tabbrowser.xml easier, more efficient and clearer.
However, not all of the passing parameters are passed through scrollIntoView, so we can't get them from Js.
FF has solved at least something with this patch after a few years, but too late for SM2.53 as opposed to SM2.57

But we should not only make whereToScroll available but also WhenToScroll in SeaMonkey.
FF has already had bug 403510 open for 12 years, although everything for it has been available in ScrollContentIntoView for at least 13 years, only the necessary flag is not passed on.

We should not follow this example and not continue to implement and adopt workarounds from FF when we can do it right, as in Bug 1606681.

Frank, what do you think.

Comment 9

[Frank-Rainer Grahl (:frg)]

Let me look at it. Clearing the dependent bugs for now to not generate further noise there.