"Scroll of Lorem Ipsum" does not scroll by scrollbar if text is selected with Ctrl+A

NEW
Unassigned

Status

()

Core
Event Handling
2 years ago
2 years ago

People

(Reporter: arni2033, Unassigned)

Tracking

Trunk
x86_64
All
Points:
---

Firefox Tracking Flags

(firefox46 wontfix, firefox47 wontfix, firefox48 affected, firefox49 affected)

Details

(Whiteboard: btpp-active)

(Reporter)

Description

2 years ago
>>>   My Info:   Win7_64, Nightly 47, 32bit, ID 20160229030448
Also happens on Firefox 44.
STR:
1. Open attachment 8710335 [details] (from bug 1241394), press Ctrl+Shift+R
2. Doubleclick any word on the page
3. Press Ctrl+A to select all text
4. Hover mouse over the scrollbar, hold left mouse button, move mouse to the bottom of the screen

AR:  The testcase does not scroll. Mouse cursor displays "Prohibited" icon.
ER:  Should be scrolled to the bottom.

It works in Chrome if I disable CSS rule   ::-webkit-scrollbar{ display: none; }
Hi,

I've managed to reproduce this issue on the latest Firefox release (44.0.2) and the latest Nightly (47.0a1) on Windows 10, Mac OS X 10.11 and Ubuntu 14.04. It seems this is a regression of Bug 936092.

Last good revision: 63c495f3e709f936de5e026cb4a81aa232b2ea0c
First bad revision: 1eec2c8789c1f3865e339fce65a83d5f668cdea4

Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=63c495f3e709f936de5e026cb4a81aa232b2ea0c&tochange=1eec2c8789c1f3865e339fce65a83d5f668cdea4

Thanks,
Cipri
Component: Untriaged → Event Handling
Keywords: regression
Thanks for the regression window, Cipri!
Flags: needinfo?(bugs)
Whiteboard: btpp-followup-2016-03-18

Comment 3

2 years ago
Oh, interesting.
Assignee: nobody → bugs
Flags: needinfo?(bugs)
Whiteboard: btpp-followup-2016-03-18 → btpp-active

Updated

2 years ago
status-firefox48: --- → affected
status-firefox49: --- → affected

Comment 4

2 years ago
Based on comment1, this has been around for a while, setting Fx46 to affected.
status-firefox46: --- → affected

Comment 5

2 years ago
smaug, when do you think you'll be aqble to look at this?
status-firefox46: affected → wontfix
status-firefox47: affected → wontfix
Flags: needinfo?(bugs)

Comment 6

2 years ago
The regression range is wrong.
https://hg.mozilla.org/mozilla-central/rev/ab0490972e1e is showing the behavior, and that is before e10s-dnd.
Investigating some more.
Flags: needinfo?(bugs)

Comment 7

2 years ago
So I went back to FF32 and the behavior is the same.
Can't see this being a regression.
Assignee: bugs → nobody
Keywords: regression
With e10s disabled this issue is reproducible on all Nightly builds. I've gone as far back as Nightly 15.0a1 and it was still reproducible on the OSs that I have mentioned in comment 1.

With e10s enabled however, because the reporter said that the issue is reproducible on the latest Nightly at that time (47.0a1), I did not think to try with e10s disabled. As such, I've found that builds up until 2015-03-29 are bad, builds between 2015-03-30 and 2015-04-09 are good because of a fix from comment 8's pushlog and builds after 2015-04-10 are again bad because of comment 1's pushlog.

Comment 9

2 years ago
well, the issue wasn't in e10s before drag-and-drop was implemented for e10s.
I've also investigated this further and because I found an initial good build, I've tried to find a fix for the issue, which is somewhere in the following pushlog:
First good revision: 26d6392b5403 (2015-03-30)
Last bad revision: 385840329d91 (2015-03-29)
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=385840329d91&tochange=26d6392b5403

As such I think the regression from comment 1 is still valid.
Flags: needinfo?(bugs)
OS: Unspecified → All
Hardware: Unspecified → x86_64
When looking for regression range, remember that profile is possibly automatically switched to e10s mode. I was looking at the non-e10s regression range, and FF32 (a build from May 2014) had the issue.
Flags: needinfo?(bugs)
You need to log in before you can comment on or make changes to this bug.