Scroll bug?

[fishbot2000]

Originally reported by: chaos (Bitbucket)

---

Hi,

did you changed something within the last 3 days? Since today scrolling is buggy, that means sometimes scrolling stops and I have to reload qwebirc.

I don't know the reason yet, but it occurs only since today, so it may be a aftereffect of a update?

If not, i could try to locate the problem...

Browser: Firefox 3.5.2 on Mac OS X 10.5 Leopard

Regards

<>

---

• Bitbucket: https://bitbucket.org/qwebirc/qwebirc/issue/86

[fishbot2000]

Original comment by CoryChaplin (Bitbucket):

---

Hmm, that's funny because it works well here (Chrome25@kubuntu). Is there something I'm missing in the use case ?

[fishbot2000]

Original comment by jdcaron (Bitbucket):

---

Maybe my patch is not the most elegant solution but it works, it doesn't cause any issues anywhere else and it's also a very simple.

[fishbot2000]

Original comment by chrisporter (Bitbucket):

---

still seems to happen :(

[fishbot2000]

Original comment by chrisporter (Bitbucket):

---

merged in, thanks Cory!

[fishbot2000]

Original comment by CoryChaplin (Bitbucket):

---

Not quite sure your patch is the good way to approach this one Jean-Denis since all you're doing is checking for a 1 pixel offset. My patch fixes the case that was missed out in global behaviour.

[fishbot2000]

Original comment by n0risc (Bitbucket):

---

Thanks Jean-Denis Caron!

[fishbot2000]

Original comment by jdcaron (Bitbucket):

---

I got a patch for this issue:

#!js

jdcaron@debian:~/qwebirc-qwebirc-516de557ddc7$ diff js/ui/baseuiwindow1.js js/ui/baseuiwindow.js 
167,170c167
<     if(Math.abs((prev.y + prevheight) - prevbottom) <= 1)
<       return true;
<     else
<       return false;
---
>     return prev.y + prevheight == prevbottom;

I know how to reproduce this bug in Chrome every time, you need to get enough lines in a conversation to get a scroll bar, once you have that you need to make sure the scroll is not at the bottom. You then create a new tab and wait that a new line is added in the conversation, then when you go back to your conversation and scroll back at the bottom, when a new line is added the scrolling should not work as intended.

This issue is due to Chrome returning a parent.scrollTop value that is 1 pixel off, at least that is occuring in QwebIRC, I didn't test elsewhere, odd bug you tell me...

[fishbot2000]

Original comment by CoryChaplin (Bitbucket):

---

Maybe this fixes the issue ?

[fishbot2000]

Original comment by n0risc (Bitbucket):

---

yes, still present. Latest Google Chrome. embedded @ www.onsitepool.com

[fishbot2000]

Original comment by Anonymous:

---

Still present as of this writing.

[fishbot2000]

Original comment by Anonymous:

---

This problem is also present on Android platforms from Honeycomb on. ICS also displays this issue. Scrolling is not supported.

[fishbot2000]

Original comment by Anonymous:

---

Still present all the time, at least on FF and Safari on Lion, latest patches from apple and mozilla. The zoom workaround doesn't work.

[fishbot2000]

Original comment by Anonymous:

---

actually i don't know that this is the current version of qwebirc, so it may be fixed. i cannot find version info anywhere on your site

[fishbot2000]

Original comment by Anonymous:

---

nope, all my users are still having this issue.. love the webchat, but this is super annoying

[fishbot2000]

Original comment by retropc:

---

possibly fixed now?

[fishbot2000]

Original comment by troubled (Bitbucket):

---

I have also ran into this problem and thought that I would at least document what I have found and what I did to at least workaround the problem for others who might search (it's still an existing bug though).

If you do a browser zoom of sorts in at least chrome and firefox (tested on ubuntu 10.4) by doing ctrl +/-, the scrolling stops following the bottom of the screen. However, if you reset the screen zoom with ctrl-0, it seems to correct itself again.

I hope this at least gives you an idea of where to start looking and why you may be affected.

[fishbot2000]

Original comment by xaquseg (Bitbucket):

---

This problem is not Mac-exclusive, it happens on all platforms. My guess is some slight issue in the "are we at the bottom?" check, simplest way to solve this would be to add a few pixels of buffer to the check, in case of math errors. (or screwyness from browsers, I've seen the same issue from some of my own scripts)

[fishbot2000]

Original comment by chaos (Bitbucket):

---

I realized that the problem exists only on Mac.

I don't know the reason but maybe you could find the bug...