Open
Bug 1239534
Opened 9 years ago
Updated 2 years ago
The first scroll with mouse wheel is laggy (causes huge delay) in Debugger and Style Editor
Categories
(DevTools :: Source Editor, defect)
DevTools
Source Editor
Tracking
(firefox42 affected, firefox43 affected, firefox44 affected, firefox45 affected, firefox46 affected, firefox-esr38 affected)
People
(Reporter: arni2033, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
text/html
|
Details |
>>> 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)
Comment 1•9 years ago
|
||
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)
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)
Comment 3•9 years ago
|
||
Gabriel, can you confirm this is an issue with codemirror?
Flags: needinfo?(gl)
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)
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
status-firefox42:
--- → affected
status-firefox43:
--- → affected
status-firefox44:
--- → affected
status-firefox45:
--- → affected
status-firefox-esr38:
--- → affected
Comment 6•9 years ago
|
||
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
Blocks: DOMMouseScroll-vs-webdevs
Updated•6 years ago
|
Product: Firefox → DevTools
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•