605138 - Scripts from topix.net apparently causing page to scroll down when opening

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[WildcatRay]

Apparently, scripts from topix.net are causing the page to scroll down opening them. 

Examples:
http://www.dispatch.com/live/content/local_news/stories/2010/10/18/motorist-killed-when-car-police-cruiser-collide.html?sid=101
http://www.dispatch.com/live/content/local_news/stories/2010/10/18/18-bus-school-close.html?sid=101
http://www.dispatch.com/live/content/local_news/stories/2010/10/18/18-dump-dem.html?sid=101

It also appears to happen on this link:
http://newsbusters.org/blogs/tim-graham/2010/10/18/wapo-promotes-gospel-according-jimmy-they-find-carters-preachy-know-it-a

I cannot tell if they use topix scripts or just scripts similar to those on topix.

If you open any of these in Minefield/Trunk, the pages will open and then scroll down. Pages should only open. (I did not see this on IE9.)

I have tested in both Win7 and WinXP using the 32-bit builds in both safe mode and using a fairly new, no add-ons installed profile. Others have confirmed this bug, too. I think this started with the compartments landing.

The nightly build of 13-Oct does not show the problem. The nightly of 14-Oct does.

Comment 1

[WildcatRay]

FYI-May need to be logged in to the newsbusters.org web site to see this behavior.

Comment 2

[Alice0775 White]

Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/b829cf5debce
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101012 Firefox/4.0b8pre ID:20101013074132
Fails:
http://hg.mozilla.org/mozilla-central/rev/178f26e21cfc
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101011 Firefox/4.0b8pre ID:20101013081930
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b829cf5debce&tochange=178f26e21cfc

Comment 3

[d.a.]

Probably bug 597331

Comment 4

[Alice0775 White]

Happens on Linux too.
http://hg.mozilla.org/mozilla-central/rev/cfd18201f49b
Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101018 Firefox/4.0b8pre ID:20101018030619

In local build,
Build from 178f26e21cfc : fails
Build from 18d0545c5f0e : works
So, Landing of the following cset causes the problem.
changeset 178f26e21cfc	Ehsan Akhgari — Bug 597331 - Reframing a textarea sets the caret position to the end of its contents; r=bzbarsky a=blocking-final+

Comment 5

[Alice0775 White]

Attachment: semi-reduced html

Comment 6

[Alice0775 White]

Attachment: reduced sample

CSS file should be external CSS file.

Strange to say,
If CSS is written in script tag, the scroll does not happen.
And If removed SCRIPT tag, the scroll does not happen.

Comment 7

[(no longer active)]

Attachment: Reduced testcase

Here's the most reduced testcase for this bug.

Comment 8

[(no longer active)]

Attachment: Patch (v1)

Please note that this requires an API change (so that we can pass SCROLL_FIRST_ANCESTOR_ONLY to nsIPresShell::ScrollFrameRectIntoView if needed.  Can this land post b7, or on the b7 relbranch as well?

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Instead of one (or multiple) PRBool parameters, can we use a flags word please?

Comment 10

[(no longer active)]

Attachment: Patch (v2)

(In reply to comment #9)
> Instead of one (or multiple) PRBool parameters, can we use a flags word please?

Of course.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

You're still adding a boolean parameter to nsSelection::ScrollIntoView, which now has three boolean parameters. Can we flagize them too please?

Comment 12

[(no longer active)]

Attachment: Part 2: flagize nsTypedSelection::ScrollIntoView

(In reply to comment #11)
> You're still adding a boolean parameter to nsSelection::ScrollIntoView, which
> now has three boolean parameters. Can we flagize them too please?

Sure.

Comment 13

[(no longer active)]

Attachment: Part 2: flagize nsTypedSelection::ScrollIntoView

I had made a mistake in part 2 of this patch.  In nsTypedSelection::ScrollSelectionIntoViewEvent::Run, I had practically removed the aDoFlush and aIsSynchronous parameters and wasn't setting the corresponding flags.  This version of the patch fixes that problem.

Comment 14

[antonnio94]

This bug happens for me in this page: http://es.paperblog.com/25-anos-de-back-to-the-future-primera-parte-el-de-lorean-206615/

It's working fine on Chrome, IE9 and Opera.

Comment 15

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/8cb3a9d9f7f9
http://hg.mozilla.org/mozilla-central/rev/e4400c2c3a3d

Comment 16

[(no longer active)]

I pushed a follow-up to fix a Thunderbird build bustage:

http://hg.mozilla.org/mozilla-central/rev/142c7b20fd8c

Comment 18

[Eric Shepherd [:sheppy]]

These API changes do not impact any currently-documented interfaces, so I'm removing the doc needed keyword. These changes will be picked up when these interfaces get documented in the future.

Comment 19

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 605138 - Scroll to selection anchor, not focus, for view-source go to line. r=hsivonen,#dom-core

The flags argument was effectively 0 (true used to mean isSynchronous
until bug 605138, but since then there was no flag).

Keep the selection scroll async since it has been async since that bug,
and add some tests.

Comment 20

[Phabricator Automation]

Comment on attachment 9502411 [details]
Bug 605138 - Scroll to selection anchor, not focus, for view-source go to line. r=hsivonen,#dom-core

Revision D258398 was moved to bug 1978801. Setting attachment 9502411 [details] to obsolete.