Closed
Bug 1269066
Opened 9 years ago
Closed 8 years ago
[APZ] It's possible to accidentally (a) scroll frame while dragging a splitter and (b) cause splitter twitching
Categories
(Core :: Panning and Zooming, defect, P3)
Tracking
()
People
(Reporter: arni2033, Assigned: kats)
References
Details
(Keywords: correctness, regression, Whiteboard: [gfx-noted])
Attachments
(1 file)
>>> My Info: Win7_64, Nightly 49, 32bit, ID 20160429030215
STR:
1. Open data:text/html,<style>body{height:10000px} , scroll to the middle of the page
2. Open devtools, dock it to the bottom side of window
3. Start dragging toolbox splitter to the top, then, while mouse is placed above the page content,
rotate mouse wheel up or down w/o interrupting dnd.
AR: The splitter twitches to the same direction you rotated mouse wheel
ER: Splitter shouldn't be affected by mouse wheel
This is regression from bug 1213095 (I'm leaving keyword "regression" for now). Regression range:
> https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=20619c132abb081f017de02162ffe083601c0085&tochange=d7c04b4c6cffc62ed92f8cc2c5e5dbb4f49a7a23
Summary: It's possible to accidentally (a) scroll frame while dragging a splitter and (b) cause splitter to twitching → [APZ] It's possible to accidentally (a) scroll frame while dragging a splitter and (b) cause splitter to twitching
Summary: [APZ] It's possible to accidentally (a) scroll frame while dragging a splitter and (b) cause splitter to twitching → [APZ] It's possible to accidentally (a) scroll frame while dragging a splitter and (b) cause splitter twitching
|
||
Updated•9 years ago
|
|
|
||
Comment 3•9 years ago
|
||
Backing out the Part 4 patch from bug 1213095 (i.e. the main fix in that bug) does seem to make this go away.
|
||
Updated•9 years ago
|
Assignee: nobody → botond
Version: unspecified → 46 Branch
|
Assignee | |
Comment 4•9 years ago
|
||
I can repro this on Windows, using a 47 beta build. On the latest 48/49 builds I can't seem to, using the same profile. Arni, are you still seeing this on Nightly? I think it may have been fixed already on trunk and perhaps uplifted to 48.
Flags: needinfo?(arni2033)
|
|
Assignee | |
Comment 5•9 years ago
|
||
(Also, you have 4 days left to file 11 more bugs, if you want to reach 1000 bugs in one year! :p)
|
|
||
Comment 6•9 years ago
|
||
I found a fix window on Linux using mozregression: looks like this was fixed by bug 1272757.
|
|
||
Comment 7•9 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #6)
> I found a fix window on Linux using mozregression: looks like this was fixed by bug 1272757.
Which is interesting because bug 1272757 is supposed to fix a regression introduced by bug 1242690, which landed in 48, but *this* bug is present in 46 and 47 as well.
|
|
Assignee | |
Comment 8•9 years ago
|
||
Marking fixed by bug 1272757, and I requested uplift on that bug.
Status: NEW → RESOLVED
Closed: 9 years ago
Depends on: 1272757
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
>>> My Info: Win7_64, Nightly 49, 32bit, ID 20160522030240
1) As said in comment 6, it was greatly improved in bug 1272757 [1]
However, when I was searching for fix, I accidentally reproduced it on a "good" build.
Then I tried it again several times, and found out that it's but still reproducible.
It's possible to scroll the web page in 5% of cases. Devtools toolbox twitches only in 1% of cases.
2) I think that STR in comment 0 are blocked by the same mechanism as bug 1269067
("when left mouse button is pressed, and mouse is moving => scrolling doesn't work").
Once bug 1269067 is fixed, this bug should be re-tested.
3) I reported this bug with 2 "parts" - (a), which is neutral glitch, and (b), which is clearly bad.
That's because even part (a) is impossible on non-APZ, and I thought that you may want to fix (a) as it seemed that (b) is caused by (a). I don't know your plans regarding (a), but it still happens:
(I)
1. Open bookmarks sidebar on this page
2. Hover mouse over vertical resizer, hold left mouse button, move mouse to the center of this page
3. Stop moving mouse. Rotate mouse wheel down/up
(II)
1. Open https://www.mozilla.org/en-US/firefox/nightly/firstrun/
2. Open devtools -> inspector, focus <body> node, select ruleview tab.
3. Hover mouse over vertical resizer, hold left mouse button, move mouse to the center of ruleview tab
4. Stop moving mouse. Rotate mouse wheel down/up
> [1] fix range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=837ef3fa5ae3b80d86081a2d00ae464a5ccdfc51&tochange=db473770c2eb45fb5fe70342571f7152f44a00fb
Flags: needinfo?(arni2033) → needinfo?(bugmail.mozilla)
|
|
Assignee | |
Comment 10•9 years ago
|
||
Ok, we can leave this open to investigate the remaining issue (a) for now. It might be hard/impossible to fix - when the resizer is dragged it's going to lag behind the mouse because of APZ, and if we scroll during that lag then the hit-test will land on the content. Still, I'll take a closer look at some point to verify there's nothing else going on.
Assignee: botond → nobody
Status: RESOLVED → REOPENED
Flags: needinfo?(bugmail.mozilla)
Resolution: FIXED → ---
Target Milestone: mozilla49 → ---
|
|
Assignee | |
Updated•8 years ago
|
I'd rather not drag this by "wontfix"-ing it one by one release. Do we think we'll ever want to, and be able to fix it? If so, please reopen, and fix in 50 or 51.
Assignee: nobody → bugmail
Status: REOPENED → RESOLVED
Closed: 9 years ago → 8 years ago
Flags: needinfo?(bugmail)
Resolution: --- → WONTFIX
|
|
Assignee | |
Comment 12•8 years ago
|
||
I can't think of any decent way to fix this. I'm ok with leaving this as WONTFIX.
Flags: needinfo?(bugmail)
|
|
Assignee | |
Updated•8 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•