# fix autoscroll on Firefox #2041

Open
opened this Issue Jun 26, 2012 · 35 comments

None yet

# update: retitling to describe current state

auto-scroll is super buggy in Firefox (like everything else), so it was disabled for 0.13. This Issue is open for re-enabling autoscroll of long output in Firefox if we can figure out how to make it not suck.

# Original description

since the notebook puts long outputs into a scrollable subcell it scrolls down to the end of the page on each shift+enter even when it should only scroll the following cell.

to reproduce ubuntu 12.04 daily build standard browser (ff 13 I think):
put make three cells containing this:
for i in range(500):
print i

execute them and then reexecute the first one, it then scrolls right down to the end of the page while I expect to land at the second one.

Member
commented Jun 26, 2012
 I see the expected behavior (scrolls to subsequent input) on Chrome 21, FF 12, OS X 10.7.4.
 I don't see it with chromium either, seems like a ff13 issue.
Member
commented Jun 26, 2012
 after updating, I think you are right - this is new in FF13
Member
commented Jun 26, 2012
 After a bit more poking around, I don't think this is related to the scrolled output, but focus in general. I can reproduce the same behavior with any case where it should scroll to the next input. FF 13 seems to always barely fit it in view
Member
commented Jun 26, 2012
 a bit of clarification: what I am seeing is not what is reported here, and is only a minor annoyance (newly focused cells sit at the bottom of the screen, rather than in the usual central place). The issue here is far more serious because the focused input has been scrolled off the screen, and I cannot reproduce this behavior at all.
Member
commented Jun 26, 2012
 @mcelrath, you've been poking around focus/scrolling issues a lot lately, any words of wisdom you may have on this one?
Member
commented Jun 26, 2012
 On 12.04 with firefox 13.0.1 (the system one), I see the following: the focus is right, just the scrolling is a little off. The page does indeed scroll to the bottom (as in, the scroll bar is flush bottom), but the focus is still on the correct (second) cell. I tested by adding multiple more identical cells, and that's indeed what is happening: on reexecution of the first cell, focus goes (correctly) to the second cell. but scroll goes all the way to the bottom. I tested and chrome does not jump for me. FF bug, maybe?
 Yes I'm aware of this and have attempted to fix it in my branch: https://github.com/mcelrath/ipython/tree/jumpy_output I will try to push my work so far on this soon (it is not there yet). The related issue is #1858. There are several problems: When substantial output is removed, what do you expect the position on the page to be? When executing a cell, a new cell is focused. The browser will attempt to put the corresponding 
Member
commented Jun 26, 2012
 @mcelrath, thanks for jumping in. As unpleasant as this may be in some cases, I'm afraid we're going to release 0.13 with it... I don't realistically see us diving deep into the heart of the JS in a rush, so I'd rather release with known annoyances than make a heroic attempt at a fix and have a big mess in our hands. So let's mark this as high-priority for 0.14, and hopefully without any time pressure @mcelrath and others can make good progress on this.
 Yes, even if I push a fix today, I think it should get more testing than we have time before the 0.13 release, as it's a pretty heavy rewrite of the focusing machinery.
Member
commented Jun 26, 2012
 Perfect, done.
 I tried @mcelrath branch and unfortunately it does not fix the jumping to the end of the page for me
 No @juliantaylor, as I mentioned, I have not pushed that yet...
 assuming I'm not the only one affected this issue should be a blocker for 0.13 it makes the notebook very unpleasant to use when you have scrolled outputs in it I see it on two completely different machines with ff13 and I could also reproduce it with ff12
Member
commented Jun 27, 2012
 This will happen if you have Autoscrolling disabled (Preferences/Advanced/General/Browsing), since we rely on focus() causing the element to be located properly, and we don't do any scrolling ourselves. I just re-enabled autoscrolling and the issue is gone.
Member
commented Jun 27, 2012
 I did my best to do a fresh install, and it seems that the default is 'off' for Linux and 'on' for OS X, because FF likes to ruin everything.
 autoscrolling on or off makes no difference for me, both setting have the issue, also smooth scolling on/off affected
Member
commented Jun 27, 2012
 Sorry, seems I was hasty. If this is a blocker, we should do one of: disable automatic scrolling, and figure it out in 0.14 disable it on Firefox I have neither the interest nor the time to debug an issue specific to a browser and platform before we cut 0.13.
Member
commented Jun 27, 2012
 Sorry - re-reading above, it sounds like @fperez is in favor of leaving it as-is for 0.13, but @juliantaylor thinks 0.13 shouldn't be allowed with this behavior. So our choices (since a real fix is not likely): disable auto-scroll disable auto-scroll only on Firefox leave it as-is for 0.13 These are all equally trivial, we just have to make a choice. Selfishly, I really don't care because this has no effect on my experience, but I know there are plenty of FF-on-Linux users ( for some reason :) ). Unless I hear otherwise (pinging @ellisonbg, @Carreau, @takluyver, @ivanov), I will go with @fperez's comments above as our most invested FF-on-Linux user, and leave this without change.
Member
 As a side note, I think we should scroll the div manually (using jQuery) as little as possible. I have found that it is very difficult to get that type of thing to play nicely with the browsers default scrolling behavior.
Member
commented Jun 27, 2012
 @ellisonbg - that is precisely what is failing. I believe that we make zero calls to scroll methods here, and our failure is in trusting FF to do what we expect. The only fix I can see is to add manual scrolling. Do you have an opinion on what we should do for 0.13?
Member
commented Jun 27, 2012
 disable auto-scroll only on Firefox I have very limited bandwidth right now unfortunately, but this sounds like the most reasonable solution... But I have to say: I haven't actually tried it, I'm just guessing. And note that I use FF for many things but not the notebook, precisely because the experience is generically not very good. I'm thinking we might want to create a Firefox label for FF-specific bugs, so at least we can point FF people to them eventually (I know we won't have the bandwidth to do much follow up on our own). Cheers, f
added a commit to minrk/ipython that referenced this issue Jun 27, 2012
 minrk disable auto-scroll on mozilla see #2041 for details 45090c2
referenced this issue Jun 27, 2012
Merged

#### disable auto-scroll on mozilla #2047

Member
commented Jun 27, 2012
 Thanks. PR #2047 issued, then. If we merge that, then we can bump this issue back to 0.14
Member
 Wow FF is a pain. When you say "disable auto-scrolling" will this mean long output on FF won't ever scroll? Not quite clear on what you are disabling.
Member
commented Jun 27, 2012
 Only disabling the automatic scrolling when long output arrives. Users can still scroll/unscroll to their hearts' content.
 Brian E. Granger [reply@reply.github.com] wrote: As a side note, I think we should scroll the div manually (using jQuery) as little as possible. I have found that it is very difficult to get that type of thing to play nicely with the browsers default scrolling behavior. FWIW, I find no alternative but to do extremely explicit scrolling in the UI. Browser scrolling is intended to keep a form element in view. All the form elements are hidden
Member
commented Jun 27, 2012
 There is another unfortunate degeneracy of terminology here: 'Scrolled output' means eliding the output into a scrolled area. No scrolling methods are involved. But it is Firefox's bizarre scrolling behavior that the scrolled output is running afoul of.
Member
 OK I think Mins fix is fine then. On Wed, Jun 27, 2012 at 3:15 PM, Min RK reply@reply.github.com wrote: There is another unfortunate degeneracy of terminology here: 'Scrolled output' means eliding the output into a scrolled area.  No scrolling methods are involved.  But it is Firefox's bizarre scrolling behavior that the scrolled output is running afoul of. Reply to this email directly or view it on GitHub: #2041 (comment) Brian E. Granger Cal Poly State University, San Luis Obispo bgranger@calpoly.edu and ellisonbg@gmail.com
Member
 FWIW, I find no alternative but to do extremely explicit scrolling in the UI. Browser scrolling is intended to keep a form element in view.  All the form elements are hidden
 Brian E. Granger [reply@reply.github.com] wrote: It is difficult, but I think the browser's scrolling can be overridden, in general. Do you have any ideas on how to do this? Yes. Browser-forced scrolling occurs in two instances: elements are added to or removed from the DOM. input form elements (CodeMirror's
Member
 On Wed, Jun 27, 2012 at 3:54 PM, Bob McElrath reply@reply.github.com wrote: Brian E. Granger [reply@reply.github.com] wrote: It is difficult, but I think the browser's scrolling can be overridden, in general. Do you have any ideas on how to do this? Yes.  Browser-forced scrolling occurs in two instances: elements are added to or removed from the DOM. input form elements (CodeMirror's
Member
 @minrk can we close this one?
Member
commented Jan 27, 2014
 Not really - the workaround is still there.
pushed a commit to mattvonrocketstein/ipython that referenced this issue Nov 3, 2014
 minrk disable auto-scroll on mozilla see #2041 for details 40dca14`
modified the milestone: wishlist, 3.0 Nov 14, 2014
Member
commented Nov 14, 2014
 Confirmed that it still affects FF 33, bumping to wishlist.
removed the prio-medium label Jan 14, 2015
commented Jul 31, 2015
 I see the expected behavior (scrolls to subsequent input) on FF 39 on a Mac--can we determine when the bug was fixed and re-enable autoscrolling for Firefox?