Closed Bug 1436906 Opened 7 years ago Closed 5 years ago

Page scrolled to bottom on load (or pageshow)

Categories

(Core :: DOM: Selection, defect, P2)

Product:
Core
Component:
DOM: Selection
Version:
58 Branch
Platform:
Desktop
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla67
Tracking Flags:
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- wontfix
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- wontfix
firefox62 --- wontfix
firefox64 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- verified

People

(Reporter: jscher2000, Assigned: masayuki)

References

(
URL
)

Details

(Keywords: parity-chrome, parity-edge, regression)

Attachments

(1 file)

Bug 1436906 - Make Selection::NotifySelectionListeners() not scroll when it moves focus
(deleted), text/x-phabricator-request
Details 
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180206200532

Steps to reproduce:

Open https://ttlc.intuit.com/ or any of the linked pages under "Browse Topics" on that page. The problem does not occur with pages that are lined under "Top FAQs" on that page.


Actual results:

A script causes Firefox to scroll to the bottom of the page. Same if you follow a link and use Back to return to the page. Same behavior in release and Nightly. Does not occur in other browsers (Chrome/IE11). This makes the pages very frustrating to browse.


Expected results:

Firefox should display the page at the top.

Per mozregression:

2018-02-08T17:59:33: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=22e1a32de5b88f1f56a156aefa95614b5cda204c&full=1
2018-02-08T17:59:33: DEBUG : Found commit message:
Bug 1318312 part.3 Selection should move focus at every selection change when it's called by JS r=smaug

Selection may be changed by methods of Selection or methods of Range retrieved by Selection.getRangeAt().  Selection::NotifySelectionListeners() is called after every selection change of each of them, so, this method must be a good point to move focus.

If new common ancestor of all ranges is editable and in an editing host, we should move focus to it.  Otherwise, if an editing host has focus but new common ancestor is not editable, we should move focus from the editing host.

For consistency with the other browsers, this patch doesn't move focus to other focusable element.

MozReview-Commit-ID: 6sNsuzwqECX

2018-02-08T17:59:33: INFO : The bisection is done.

This seems similar to but not fixed by bug 1377752 (Page is unexpectedly scrolled to the bottom)
Blocks: 1318312
Status: UNCONFIRMED → NEW
status-firefox58: --- → wontfix
status-firefox59: --- → fix-optional
status-firefox60: --- → affected
status-firefox-esr52: --- → unaffected
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
If somebody would create a minimized testcase, that'd be really helpful.
Component: Untriaged → Selection
Whiteboard: [parity-Chrome][parity-Edge]
[Triage 2018/03/23 - P3]
Priority: -- → P3
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome, parity-edge
Whiteboard: [parity-Chrome][parity-Edge]
I have used the following STR to retest the issue in question:

1. Launch browser.
2. Load: https://ttlc.intuit.com/
3. Click on any of the cards displayed in the "Browse Topics" section.
Actual: The user is redirected to the page, but auto-scrolled to the bottom of the page.
Expected: The user is redirected to the correct page and no auto-scroll is applied. The page is scrolled to the top (default).
status-firefox64: --- → affected
status-firefox65: --- → affected
status-firefox66: --- → affected
Keywords: testcase-wanted
OS: Unspecified → All
Hardware: Unspecified → Desktop
Priority: P3 → P2
Assignee: nobody → masayuki
Status: NEW → ASSIGNED

When Selection changed into an editing host,
Selection::NotifySelectionListeners() moves focus to the editing host.
In this case, we've scrolled to the focused element because it's our consistent
and traditional behavior. However, Chrome does not behave so. Therefore,
we should not scroll in this case for compatibility with Chrome.

(Although, I've not succeeded to run the WPTs on Chrome with
./mach wpt --product chrome due to (probably) under testing/web-platform/mozilla/tests,
as far as I've tested, Chrome won't scroll to focused editing host at least
when it gets focus because of Selection API.)

Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/f5c2da8845b4
Make Selection::NotifySelectionListeners() not scroll when it moves focus r=smaug
Blocks: 1529487

https://hg.mozilla.org/mozilla-central/rev/f5c2da8845b4

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox67: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla67

This fix has been verified on Nightly v67.0a1 from 2019-02-21 on Windows 10, Mac OS 10.13.6 and Ubuntu 16.04 LTS.

Status: RESOLVED → VERIFIED
status-firefox67: fixed → verified

Is this something to be considered for uplift or should it just ride the trains?

Flags: needinfo?(masayuki)
Flags: in-testsuite+

(In reply to Ryan VanderMeulen [:RyanVM] from comment #12)

Is this something to be considered for uplift or should it just ride the trains?

The patch should be safe, but this is not so urgent bug since we get only this report and bug 1490126. So, not many web apps are broken by this incompatible issue. Perhaps, for risk management, it's better to make it just ride the train.

Flags: needinfo?(masayuki)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: