Closed nicegamer7 closed 3 years ago
Interesting. The first +10 make sure that the sensor elements are bigger than the parent to generate an invisible scrollbar. The others on scrollTop/scrollLeft make sure the invisible scrollbar is "scrolled", this way browser engines send a scroll
event once their dimensions have changed.
What browser are you using? I tried to reproduce in Chrome, but wasn't able to do so.
I'm using Chrome 80.
The way I've been changing the element's size has been through the developer tools device toolbar. I use the device toolbar to shrink the viewport, then I disable the device toolbar to go back to normal.
Interestingly enough, it seems this only happens with the viewport changing size. I've made a demo of the issue here.
Some notes on the demo:
Yes, I tried it using a button as well. Didn't work. Weird enough that it only happens in the devtools. Maybe a bug in Chrome? I'm not sure. In any case that doesn't seem to be a high priority issue when it works in any other important cases. That being said, we could easily increase those numbers without having a negative impact. So, if that really fixes that issue (and not postpones the issue to even bigger jump) I'm open to just increase those. But I need to reproduce it first, which I can't following your 2. point.
Sorry, you're correct. I'm not sure why but the demo doesn't demonstrate the bug. I'll try to come up with another one within the next couple days.
Regrettably, I haven't been able to reproduce the issue anywhere other than in my specific usage. This issue can be closed, and in the future if I ever can reproduce it, I will create a new issue.
Alright, then I'll close.
I've found an issue where if an element has a large change in size (for example, width increasing by 185px) it is ignored by ResizeSensor.
I've identified these lines as the issue, but as I'm not really sure about how the sensor works, I don't know if my fix is a good idea. The fix was to change the
+ 10
on each line to+ 200
.Any insight would be appreciated. Thanks.