Page MenuHomePhabricator

Chrome exhibits weird scrolling jumping with anchor in the URL
Closed, ResolvedPublic


Steps to reproduce (Chrome 41.0.2272.104 on Yosemite):

  1. Go, e.g., here
  2. Press cmd+l to select the location bar text.
  3. Scroll the page down.
  4. Attempt to click on a link.

Expected behavior: You navigate to the link you clicked on.

Actual behavior: The page jumps back to the original scroll location and the click goes away. Even though the location bar text is no longer selected, you can repeat steps 3 and 4 as many times as you want, until you click somewhere else on the page.

Comment: There are several other places where Phabricator seems to jump the scroll around--for instance, sometimes when you click a link to an inline comment, if you try to scroll away from the comment too slowly, the page will just jump back. (I don't have a good repro for it, so I'm not filing a bug for that one.) Almost always when the page is scrolled programmatically (i.e. not by setting the anchor), this behavior is not what I want. Is there a way to disable the jumping entirely (e.g. with a userscript)?

Event Timeline

bkuhn raised the priority of this task from to Needs Triage.
bkuhn updated the task description. (Show Details)
bkuhn added a subscriber: bkuhn.

I can't reproduce this on Chrome 41.0.2272.118 on Yosemite.

This is one of the issues I frequently have with Chrome.

Does it reproduce reliably for you?

Not "reliably" but I see it several times a day.

I can't do it reliably, but it happens to me also.

Hmm, just found an alternate repro that may work better?

  1. Go here
  2. Click on first task (this part should succeed)
  3. Swipe to go back
  4. Scroll down a bit
  5. Click on second task

Same thing should happen as before. It's pretty reliable for me.

You can also replace steps 4 and 5 with e.g.:

  1. Scroll up a bit
  2. Click into the "responsible users" text area

Those instructions don't repro for me, either.

(Focusing the "Responsible Users" area also works fine locally.)

@chad: Good call. I've been using trackpad/2-finger scrolling. Does not repro for me with keyboard scrolling, so may not work with mousewheel either.

(Other notes: tested in incognito window, still repro's. I'm on a 15 inch retina Macbook pro. I'm using the old/"reversed" scroll direction setting, though I doubt that makes a difference.)

I can't repro with a trackpad, mouse, or keyboard, and can't repro in a logged-in or incognito window.

Repros for me pretty reliably... maybe 70% of the time (after 2 or 3 tries it stops jumping and just goes). It's just a Chrome/Trackpad issue for me.

If I sat down next to you you could repro it reliably in like less than 10 minutes?

Right now yes, and I've restarted by browser and even tried Firefox (no repro) and Canary (repros).

What does the rest of your afternoon look like?

I'm just watching kids. You're welcome to come over.

Let me finish up a couple of things and I'll try to swing by around 4ish, if that's cool?

Holy cow, that's some dedication. Thanks, guys!

@bkuhn - its no big deal with the company helicopter and everything. :D

We possibly (?) have a sort-of-reliable (?) repro (?) for this issue (?) that I'm working on reducing.

One of the requirements for this repro case literally appears to be "the browser window must be on the primary laptop monitor, not a secondary display".

Alright, I think this is minimal:

<!DOCTYPE html>
    <style type="text/css">
      .outer {
        position: absolute;
        top: 0;
        bottom: 0;

      .inner {
        height: 100%;
        overflow-y: scroll;
    <div class="outer">
      <div class="inner">
          <br /><br /><br /><br /><br /><br /><br /><br /><br />
          <br /><br /><br /><br /><br /><br /><br /><br /><br />

          <a name="a"></a>
          <a href="#a" onclick="alert('A')">Hyperlink A</a>

          <br /><br /><br /><br /><br /><br /><br /><br /><br />

          <a name="b"></a>
          <a href="#b">Hyperlink B</a>

          <br /><br /><br /><br /><br /><br /><br /><br /><br />
          <br /><br /><br /><br /><br /><br /><br /><br /><br />
          <br /><br /><br /><br /><br /><br /><br /><br /><br />
          <br /><br /><br /><br /><br /><br /><br /><br /><br />
          <br /><br /><br /><br /><br /><br /><br /><br /><br />
          <br /><br /><br /><br /><br /><br /><br /><br /><br />

Setup instructions:

  • Save this file somewhere.
  • Open it in Chrome.
  • The browser window must be on your primary laptop monitor (maybe retina is the trigger?). This does not reproduce on a secondary (non-retina) monitor for me.
  • Resize the browser window so it's short enough that there's a scrollbar (near the left side of the document).
  • Mouse or trackpad work equally well.

Reproduction instructions:

  • Click "Hyperlink B".
  • Click "Hyperlink A".

Expected behavior:

  • URL changes to "#a" and an alert triggers. This is the behavior in Firefox and Safari.

Actual behavior:

  • Page scrolls back down to "#b" and the click is ignored.


  • Can you guys reproduce this by following those instructions?
  • Does anyone have a plausible explanation for this behavior other than "Chrome is haunted by evil spirits"?

This is what things should look like when you're set up:

Screen_Shot_2015-04-02_at_5.48.18_PM.png (1×2 px, 146 KB)

Then I scroll up so it looks like this:

Screen_Shot_2015-04-02_at_5.48.54_PM.png (1×2 px, 161 KB)

When I click, the bug reproduces.

Yep, the repro works for me. Sorry for blaming Phab! I guess it's just the only site I noticed it on since I use it so often.

Wow, gross. I have no idea what's going on.

epriestley renamed this task from Weird scrolling jumping with anchor in the URL to Chrome exhibits weird scrolling jumping with anchor in the URL.Apr 3 2015, 1:36 PM
epriestley triaged this task as Normal priority.
epriestley edited projects, added Google Chrome; removed PHUI.

We should probably investigate a workaround, as any Chrome fix is months away, even when acknowledged.

The only workarounds I can come up with are:

  • Remove anchors from the product; or
  • remove the durable column from the product.

In case it helps--calling window.scrollTo(window.scrollX, window.scrollY) right after I hit the back button appears to get my browser out of the broken state from the second repro (first one no longer works for me). Might it work to call that at various points when Chrome might have entered a broken state?

epriestley closed this task as Resolved.EditedMay 14 2015, 11:07 PM
epriestley claimed this task.

This should be resolved in HEAD because we no longer frame the page content. Chrome still has the underlying bug.