New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CLOSED] Fix the CEF scroll bug on Windows #9413
Comments
Comment by nethip
|
Comment by MarcelGerber A more detailed description might help: So, I guess AFAICT, the thirdparty software mentioned above was installed to fix this very problem. I don't know of any other software that hooks the mouse, so with users that didn't explicitly install one of the aforementioned tools, there shouldn't be any issue either. If anyone can think of a better approach, please go ahead. cc |
Comment by JeffryBooher Just to be clear: Everyone I talked to that experienced this issue had a different result; for some it was 24 lines of code scrolling but for me the delta wasn't as severe but it was definitely noticeable. The delta could have been differences between OS versions, System Settings, Hardware and even system timing. Enabling Off-Screen rendering is definitely worth a shot but it may introduce other issues that may complicate the issue. It will definitely require quite a bit of testing. I think if everyone upvotes the CEF issue then Marshall will fix the problem for everyone. |
Comment by MarcelGerber Reading through https://code.google.com/p/chromiumembedded/wiki/GeneralUsage#Off-Screen_Rendering, I no longer think enabling offscreen rendering is a good idea ("Off-screen rendering does not currently support accelerated compositing so performance may suffer as compared to a windowed browser"). I think the differences in impact are not caused by OS differences (it's a Win-only bug, and I don't see why that should make a difference in Chrome's lazy scroll implementation), but rather on differing font sizes & font (would probably be better to give distance in px; for me, it's 400px; one way to get this is to scroll all the way up, scroll one tick down and then issue But as I just saw the CEF issue is Update 11.03.15: |
Comment by nethip IMO we should wait and see if this gets fixed in the next release of CEF. |
Comment by ghost Where do we find the CEF? |
Comment by MarcelGerber
|
Comment by peterflynn
|
Comment by MarcelGerber I've tested this for some time a while ago and it all seemed to work well, but at some point I wondered why it it suppressed the first and sometimes the second event, and even though that didn't cause any issue, I wonder if that had to do with a bigger issue (like, CEF not always firing doubled scroll events). Also, I assume you've read the wall(s) of text above, correct? There's some risk of CEF not firing doubled scroll events in all scenarios (possibly depending on mouse drivers, software like KatMouse, Compatibility mode, ...). Obviously, we haven't heard of the one's where scrolling just works (so we don't know how many they are) and if, with this fix merged, only every other wheel tick takes effect, the UX would greatly decrease for them. I don't quite get though why Marshall, the CEF maintainer, almost completely ignores this issue, which is currently the second-most upvoted issue on the board. Yeah, it's propably some work to figure out what's wrong, but there's plenty of interest in fixing this bug, too (this exact same bug has also caught me in the Windows Spotify client, and it's annoying there too). |
Comment by MarcelGerber
|
Comment by MarcelGerber I've just added another commit so this is now preference-based (it even supports on-the-fly changes), so it's now ready to land from my side. |
Comment by peterflynn
If someone has applied a KatMouse patch specific to Brackets to halve the scroll rate in order to work around this bug, there's no reason they'd need to leave that patch in place now that Brackets is 'fixed.' It doesn't seem like this fix should interfere with any other use of those mouse hack tools. I'm not saying we should give up on fixing the CEF bug. But realistically even if it was fixed today it would probably be 2+ months before we could get that fix into the hands of users. That's why I think we should merge this as a stopgap. |
Comment by peterflynn This pref change seems fair though. I'm ok with merging this -- |
Comment by nethip
|
Comment by peterflynn
|
Comment by MarcelGerber
|
Comment by peterflynn Closing since this was superseded by #10930, which is now merged into |
Issue by MarcelGerber
Tuesday Mar 03, 2015 at 19:28 GMT
Originally opened as adobe/brackets#10681
This fix is a little hacky and it will have weird effects for those using thirdparty software like X-Mouse or KatMouse (as suggested in #10214), but I confirmed it fixes #10214 and it isn't too wonky.
Obviously, a CEF-side fix would be way better, but apparently the issue doesn't have much priority...
MarcelGerber included the following code: https://github.com/adobe/brackets/pull/10681/commits
The text was updated successfully, but these errors were encountered: