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
web: behaviour: fix scroll on build history list #5392
Conversation
Hey @aoldershaw , I was able to get scrolling working on Chrome after the fix, but not on Firefox 🤔 - do you think it'd be hard to adapt for it too? the fix you provided doesn't seem to deal with anything that's platform dependent, which makes me wonder if it even worked before on Firefox at all 🤔 thanks! |
Hey @cirocosta, thanks for testing in multiple browsers! Weird that it doesn't work in Firefox - this is essentially just reverting the scrolling behaviour to 495904d. It also seems to not be the same scrolling issue as I set out to fix - on Chrome, you could scroll horizontally for a split second before having it forced back to the latest build, whereas on Firefox, it doesn't seem to move at all. I'll take a look! EDIT: can confirm that scrolling doesn't appear to work on 5.8.0 on FF |
@cirocosta turns out we were using a deprecated event Seems to work on Chrome and Firefox now |
scrolling looks good on both chrome/safari (on osx), but firefox (on osx) is very slow scrolling... takes a whole scroll to go back 1 or 1.5 builds. (might be a firefox issue?) still, slow scrolling beats no scrolling at all! |
Huh, weird...I hadn't noticed since I was just using my trackpad, but I am experiencing the same with a mouse. The EDIT: ah, it may be the case that the |
👀 look tomorrow |
Okay @jomsie, I've added some handling for |
#5383 This was broken by #5275 - in order to get ScrollToId to work, we needed to replace `getViewportOf` with `getElement`. However, due to elm/browser#86, the `viewport` and `scene` returned by `getElement` is of the document rather than the target. This could be fixed by using `.parentElem` instead of `.srcElem` in the `getX` and `getY` functions, since we manually update the `viewport` and `scene` to match the target for `.parentElem`. However, there is a noticable performance degradation needing to perform 3 browser `Tasks` (`getElement` * 2 + `getViewportOf` * 1) rather than performing just the one that's required for the other scroll behaviours. I introduced `scrollCoordsSimple` to handle this simple case, while leaving `scrollCoords` alone for the more complex case. Signed-off-by: Aidan Oldershaw <aoldershaw@pivotal.io>
Signed-off-by: Aidan Oldershaw <aoldershaw@pivotal.io>
#5383 onmousewheel is deprecated and non-standard, and was replaced with onwheel (source: https://developer.mozilla.org/en-US/docs/Web/API/Element/wheel_event). Despite it working on Chrome, it does not on Firefox Signed-off-by: Aidan Oldershaw <aoldershaw@pivotal.io>
#5383 Consider `deltaMode` in the `wheel` event for determining how much to scroll. Firefox is the only browser I've encountered that seems to generate events with DeltaModeLine (when scrolling with a mouse wheel, and not a trackpad). According to https://bugzilla.mozilla.org/show_bug.cgi?id=943034, the height of a line is based on the `font-size` of the scrollable element, which in this case is 20px. The page height is set to 800px, which is taken from https://github.com/facebookarchive/fixed-data-table/blob/3a9bf338b22406169e7261f85ddeda22ddce3b6f/src/vendor_upstream/dom/normalizeWheel.js#L23. Note that these values don't need to be exact - they should just feel natural. I've never actually seen a DeltaModePage event in practice, so I'm not sure if it will feel perfect, but oh well! Signed-off-by: Aidan Oldershaw <aoldershaw@pivotal.io>
Signed-off-by: Aidan Oldershaw <aoldershaw@pivotal.io>
i'll review this after lunch!!! |
@@ -28,6 +30,12 @@ type alias ScrollState = | |||
} | |||
|
|||
|
|||
type DeltaMode |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the things firefox makes you do 😆
@@ -394,12 +395,23 @@ update msg ( model, effects ) = | |||
case msg of | |||
ScrollBuilds event -> | |||
let | |||
scrollFactor = | |||
case event.deltaMode of | |||
DeltaModePixel -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a side comment, not super important, how'd you get the 20 / 800 for line / page?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Totally fair question! Tried to give some justification for it in the commit message I added that in.
tl;dr 20 for Line is based on the font-size of the scroll bar. The 800 for Page is totally arbitrary - I took it from some Facebook library
Note: I haven’t been able to produce a DeltaModePage event, so not sure if it feels natural, but it’s better than nothing!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm diggin' this, unfortunate about all the firefox stuff, but seems great.
Just one comment that is purely for my curiosity:
https://github.com/concourse/concourse/pull/5392/files#r407731952
Existing Issue
Fixes #5383 .
Changes proposed in this pull request
scrollCoordsSimple
function for dealing with simple cases of computing scroll position (that don't require knowing the coordinates of the source and parent elements)mousewheel
withwheel
, which fixes scrolling on Firefox (which seems to have been broken for a while)Note that this behaviour could be shoehorned in to the more complicated
scrollCoords
function, but there is a noticeable performance hit in scrolling due to the increased number of calls out toElm.Browser
.Contributor Checklist
Reviewer Checklist