If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

The first scroll with mouse wheel is laggy (causes huge delay) in Debugger and Style Editor

NEW
Unassigned

Status

()

Firefox
Developer Tools: Source Editor
2 years ago
a year ago

People

(Reporter: arni2033, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(firefox42 affected, firefox43 affected, firefox44 affected, firefox45 affected, firefox46 affected, firefox-esr38 affected)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Created attachment 8707699 [details]
testcase 1 - d3f13b20b98c56fc4227aea92752bc90.js.html

>>>   My Info:   Win7_64, Nightly 46, 32bit, ID 20160112030227
STR:
0. Set mouse option "when I rotate mouse wheel" in your OS to "scroll by 1 page"
1. Open attached "testcase 1" (inline JS I copied from a .js-file on Bugzilla)
2. If devtools are opened, close them
3. Open debugger (Ctrl+Shift+S), make sure that the (only) long file is selected in debugger
4. Click on the 1st line of that file (to make sure code is focused)
5. Hover mouse over the code area.
6. Rotate mouse wheel down once.

Result:       
 It takes long time to scroll down for the 1st time. 1st scroll lags every time about 1-2 seconds.

Expectations: 
 It shouldn't lag == there should be no delay before the 1st scroll.

Notes + "Workaround":
 Everything seem to work fine if instead of Step 6 above I do the following:
 6. Press PageDown
 7. Rotate mouse wheel up once (wait until the scroll is finished)
 8. Rotate mouse wheel down once
 In step 7 I still have to wait, but overall time spent for new Steps 6-8 is less than the delay
 described above. And I don't see any lags == delays during scrolling in Steps 7 and 8.

 So for now I think it's a CodeMirror bug. It just looks like CodeMirror somehow "initiates"
 the scrolling activity on the first scroll, and the delay depends on how much rows
 there are in the direction of scrolling. This is my first guess (and sorry for bad English)
Filing under "source editor". This seems to also happen on scratchpad.
It looks like the first mousewheel scroll is used by codemirror to lazily initialize some things and that causes that first scroll to freeze a little bit. Subsequent scrolls are smooth.

I think I was able to reproduce this on a codemirror instance outside of devtools. On jsbin: http://jsbin.com/xebayonezi/edit?js,output wait for it to load, focus the editor and try to scroll once.
The first scroll seems to be freezing too.

Can you reproduce this too?
Component: Developer Tools → Developer Tools: Source Editor
Flags: needinfo?(arni2033)
(Reporter)

Comment 2

2 years ago
Yes, I see the behavior. So, no matter how I navigate in an opened document (Left/Right arrow to move caret, PageUp/PageDown, changing scrollbar position by drag-n-drop/mouse click) - it doesn't lag. But the first scroll lags every try IF there's a lot of code lines in the direction of scrolling.

Suggested test:
 Do they use CodeMirror on JSBin? I just tested the latest CodeMirror version and I still see the bug
 For the test, I edited file /CodeMirror-master/CodeMirror-master/demo/complete.html by replacing
 those 35 lines of code by 1933 lines of .js-file in "tetscase 1", then opened "complete.html" and
 tried to scroll down

Results:
 I found out that on the first (and second!) scroll, function buildLineElement (/CodeMirror-master/
 CodeMirror-master/lib/codemirror.js:1021) is called for all 1933 lines of the code: I consequently
 set conditional breakpoints with condition "lineN > 400", "lineN > 1000", "lineN > 1800" to check it
// Hm, the best way to check it was to add logging in the source code... I haven't thought of that

 Anyway, when I set that mouse option in Step 0 to "scroll by N lines" or move caret, then codeMirror
 only calls the function above when the corresponding lines should appear in the viewport after scroll
 So this definitely is a bug.
Flags: needinfo?(arni2033)
Gabriel, can you confirm this is an issue with codemirror?
Flags: needinfo?(gl)

Comment 4

2 years ago
I talked to bgrins about this last week, and we concluded it was probably because of the pan zoom since it doesn't happen in Dev Edition which also recently had a CodeMirror upgrade.
Flags: needinfo?(gl)
(Reporter)

Comment 5

2 years ago
What made you think so? G-d, did you actually test it? It's happening for several years now, on Dev Edition and of course on Release! And I just found time to file it, that's the_only_reason you saw this report so lately.

I added "console.log(lineN);" to the function (see comment 2), and get 1933 console messages for the 1st scroll (sometimes even for 2nd scroll). Actually, 1933-24, because 24 lines are built initially
(Reporter)

Updated

2 years ago
status-firefox42: --- → affected
status-firefox43: --- → affected
status-firefox44: --- → affected
status-firefox45: --- → affected
status-firefox-esr38: --- → affected
There are 2 scroll-related problems with codemirror. I think Gabriel might have been thinking of what's described in bug 1239615 when he posted comment 4.
I think the present bug is slightly different, it's a ~1s sort of freeze on the first scroll only. So it looks more like a lazy initialization issue in codemirror than anything else.

Filed this at: https://github.com/codemirror/CodeMirror/issues/3768
(Reporter)

Updated

2 years ago
See Also: → bug 1251987
(Reporter)

Updated

2 years ago
See Also: → bug 1253484
(Reporter)

Updated

2 years ago
Blocks: 1257815
(Reporter)

Updated

a year ago
See Also: bug 1251987
You need to log in before you can comment on or make changes to this bug.