56.19 KB, text/html
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?
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.
Gabriel, can you confirm this is an issue with codemirror?
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.
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
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