fix autoscroll on Firefox #2041

Open
juliantaylor opened this Issue Jun 26, 2012 · 35 comments

Projects

None yet

6 participants

@juliantaylor

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.

@minrk
Member
minrk commented Jun 26, 2012

I see the expected behavior (scrolls to subsequent input) on Chrome 21, FF 12, OS X 10.7.4.

@juliantaylor

I don't see it with chromium either, seems like a ff13 issue.

@minrk
Member
minrk commented Jun 26, 2012

after updating, I think you are right - this is new in FF13

@minrk
Member
minrk 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

@minrk
Member
minrk 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.

@fperez
Member
fperez 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?

@fperez
Member
fperez 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?

@mcelrath

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:

  1. When substantial output is removed, what do you expect the position on the page to be?
  2. When executing a cell, a new cell is focused. The browser will attempt to put the corresponding <textarea> visible on the screen (CodeMirror hides this element).
  3. CodeMirror will attempt to put the next input cell on the screen also.
  4. jQuery may used to put the next selected cell on the screen.
  5. IPython waits 500ms, then removes the output of the current cell (in case your command is nearly instantaneous -- it will replace the output in a way that is intended to prevent scrolling).

Numbers 2-5 can be handled, though there is a lot of annoying overlapping functionality. #1 is a bit harder. If you remove half the output on an arbitrary webpage, there's no good way for the browser to know what you desire to remain on the screen. The approach I'm taking to this is to attempt to keep the selected input cell at a fixed location on the screen (which is NOT a fixed location within the height of the document -- hence the problem). This requires us to scroll differently, depending on whether output is removed above or below the selected cell. Consider executing a long-running cell, and scrolling to an arbitrary position in the document before the output is received. What do you expect to happen? To do this I have to calculate the scrollHeight of the selected cell, remove or add output, and scroll to put the selected cell back in the same place. I'm not convinced this can be done without visible flickering as the page scrolls then scrolls back. But I have prototype code that does this.

I'll also post a worksheet explaining the old behavior and (what I consider to be) desired behavior for several focus-related issues.

There's also new auto-scrolling long output cells that I need to pull and look at.

@fperez
Member
fperez 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.

@mcelrath

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.

@fperez
Member
fperez commented Jun 26, 2012

Perfect, done.

@juliantaylor

I tried @mcelrath branch and unfortunately it does not fix the jumping to the end of the page for me

@mcelrath

No @juliantaylor, as I mentioned, I have not pushed that yet...

@juliantaylor

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

@minrk
Member
minrk 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.

@minrk
Member
minrk 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.

@juliantaylor

autoscrolling on or off makes no difference for me, both setting have the issue, also smooth scolling on/off affected

@minrk
Member
minrk commented Jun 27, 2012

Sorry, seems I was hasty.

If this is a blocker, we should do one of:

  1. disable automatic scrolling, and figure it out in 0.14
  2. 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.

@minrk
Member
minrk 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):

  1. disable auto-scroll
  2. disable auto-scroll only on Firefox
  3. 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.

@ellisonbg
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.

@minrk
Member
minrk 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?

@fperez
Member
fperez commented Jun 27, 2012
  1. 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

@minrk minrk added a commit to minrk/ipython that referenced this issue Jun 27, 2012
@minrk minrk disable auto-scroll on mozilla
see #2041 for details
45090c2
@minrk
Member
minrk commented Jun 27, 2012

Thanks. PR #2047 issued, then. If we merge that, then we can bump this issue back to 0.14

@ellisonbg
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.

@minrk
Member
minrk commented Jun 27, 2012

Only disabling the automatic scrolling when long output arrives. Users can still scroll/unscroll to their hearts' content.

@mcelrath

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 <textarea>'s, and scrolling for them is in general wrong.

The three sources of scrolling: focus(), CodeMirror, and browser need to be
organized in to a single understandable mechanism. I still have a number of
cases where things move around, and I don't understand what is making them move.

I'm even leaning toward some animated scrolling/removing/adding of elements, so
it's more obvious to the user what is moving where.

It is difficult, but I think the browser's scrolling can be overridden, in
general.

Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe. If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself."
-- Friedrich Nietzsche

@minrk
Member
minrk 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.

@ellisonbg
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

@ellisonbg
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 <textarea>'s, and scrolling for them is in general wrong.

The problem is that if we add our own manual scrolling logic, I think
the browser will still try to scroll things itself. Maybe we can
disable that, but I don't know how.

The three sources of scrolling: focus(), CodeMirror, and browser need to be
organized in to a single understandable mechanism.  I still have a number of
cases where things move around, and I don't understand what is making them move.

Yes, the main place where browsers scroll is in reaction to focus
events. It would be nice to unify all of this. I should mention that
Mathematica has an extremely nice scrolling behavior. It would be
great to model ours after that.

I'm even leaning toward some animated scrolling/removing/adding of elements, so
it's more obvious to the user what is moving where.

We would first need to disable all auto-browser scrolling or we will
just fight with it.

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?

Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself."
   -- Friedrich Nietzsche


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

@mcelrath

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:

  1. elements are added to or removed from the DOM.
  2. input form elements (CodeMirror's <textarea>) are focused while off-screen.

#1 can be dealt with by being more explicit about how we add/remove things. I'm
experimenting with (a) animating the removal of elements in
OutputArea.prototype.clear_output_callback (b) animating adding of output and
(c) using replace() rather than append() or if that doesn't work, making the
output div have 'display: none', add everything, and then make it visible.
(work-in-progress) The problems I still have is that the height of elements
isn't always known when added, and if it's not known it can't be animated, and
that there are still element movements that I don't understand how they're
getting moved. This 'animation' is on the height of the output div, so it
appears to close and open and you can see what is moving where, holding the
focused input cell at a fixed location. I really don't like having half the
screen jump on an update, then I have to go hunting for what happened to my
cursor.

#2 can be dealt with by making sure that a focused cell is already on the screen
when we call CodeMirror's focus(). (I've already separated the 'select' and
'focus' mechanisms into two distinct calls) This is the easier of the two
cases and is essentially done.

I'm going to revert and re-write most of my changes in #1 because I made a mess,
but I'll try to push what I've done on #2 tonight.

Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe. If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself."
-- Friedrich Nietzsche

@ellisonbg
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:

  1. elements are added to or removed from the DOM.
  2. input form elements (CodeMirror's <textarea>) are focused while off-screen.

#1 can be dealt with by being more explicit about how we add/remove things.  I'm
experimenting with (a) animating the removal of elements in
OutputArea.prototype.clear_output_callback (b) animating adding of output and
(c) using replace() rather than append() or if that doesn't work, making the
output div have 'display: none', add everything, and then make it visible.
(work-in-progress) The problems I still have is that the height of elements
isn't always known when added, and if it's not known it can't be animated, and
that there are still element movements that I don't understand how they're
getting moved.  This 'animation' is on the height of the output div, so it
appears to close and open and you can see what is moving where, holding the
focused input cell at a fixed location.  I really don't like having half the
screen jump on an update, then I have to go hunting for what happened to my
cursor.

I have found that adding animations (even fast ones) slows down the UI
experience considerably. I think this is worth playing around with,
but we can't slow things down. Another thing to watch for is that I
think elements need to be in the DOM and visible for MathJax rendering
to work.

#2 can be dealt with by making sure that a focused cell is already on the screen
when we call CodeMirror's focus().  (I've already separated the 'select' and
'focus' mechanisms into two distinct calls)  This is the easier of the two
cases and is essentially done.

I should also mention that we need to be careful to call
code_mirror.refresh at the appropriate times. In general it needs to
be called after the code mirror editor is unhidden or resized/etc.

I'm going to revert and re-write most of my changes in #1 because I made a mess,
but I'll try to push what I've done on #2 tonight.

Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself."
   -- Friedrich Nietzsche


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

@ellisonbg
Member

@minrk can we close this one?

@minrk
Member
minrk commented Jan 27, 2014

Not really - the workaround is still there.

@mattvonrocketstein mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this issue Nov 3, 2014
@minrk minrk disable auto-scroll on mozilla
see #2041 for details
40dca14
@minrk minrk modified the milestone: wishlist, 3.0 Nov 14, 2014
@minrk
Member
minrk commented Nov 14, 2014

Confirmed that it still affects FF 33, bumping to wishlist.

@minrk minrk removed the prio-medium label Jan 14, 2015
@ebellm
ebellm 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment