Mozilla/5.0 (Android; Linux armv71; rv2.0b10pre) Gecko/20110120 Firefox/4.0b10pre Fennec/4.0b4pre 1. go to : http://people.mozilla.org/~bstover/iframe3.html 2. scroll down to "test link" link 3. click on the "test link" Expected: the window scrolls to 0, 1000 Actual: the screen greys; panning will redraw Note: 1. the page also has an iframe with the same scroll in the iframe, if you click on that link the iframe will clear.

I'm seeing similar issues with URI fragment links, e.g.: http://people.mozilla.com/~mbrubeck/test/in-page-link.html Regression from bug 479862?

try commenting out the code at the end of dragStop, which should disable the affects of bug 479862: http://mxr.mozilla.org/mobile-browser/source/chrome/content/browser.js#1180

(In reply to comment #2) > try commenting out the code at the end of dragStop, which should disable the > affects of bug 479862: > http://mxr.mozilla.org/mobile-browser/source/chrome/content/browser.js#1180 Commenting out these lines fixes the bug, so this is confirmed as a regression from bug 479862.

Reproducing this is somewhat finnicky; here are steps that work 100% of the time for me on desktop and device: 1. Open http://people.mozilla.com/~mbrubeck/test/in-page-link.html 2. Click on "in-page link" to scroll to the bottom. 3. Pan the page up and down a bit. 4. Click on "back to top". Here's what I think is happening: (a) When you click on the links in these test cases, the browser fires a "scroll" event in the content process. (b) At the same time, on mouseup we call dragStop in. Since bug 479862, dragStop calls _updateCSSViewport which sends a Content:ScrollTo message. (c) The Content:ScrollTo receiver generates a scroll event of its own and sets ContentScroll.ignoreScroll = true, which causes ContentScroll to ignore the next "scroll" event. (d) I think that ignoreScroll is causing us to ignore the scroll event from step (a), which we should *not* ignore. It looks like only one "scroll" event is received; maybe they are coalesced somewhere?

The "Content:ScrollTo" handler (child process) checks to see if the scrollTo position is the same as the current position. I guess the client script scrollTo moved the page, so the page _has_ moved, just not moved by panning.

This fixes the bug by not touching the viewport or sending any ScrollTo messages on a simple click (where dx = dy = 0).

Comment on attachment 506554 [details] [diff] [review] patch sounds ok for now. I do think we should figure out if we can remove the | ignoreScroll | code though.

I think Matt hit it on the nose. I had a similar patch to Mark's that stored the last known scroll offset instead of a flag to ignore scrolling to account for this behavior.

This patch busted bug 479862. Turns out dx and dy are always zero.

If I backout this patch, I can't seem to reproduce on desktop linux build

(In reply to comment #11) > If I backout this patch, I can't seem to reproduce on desktop linux build I can reproduce this on Linux desktop after backout, using the steps in comment 4.

Comment on attachment 507035 [details] [diff] [review] followup This should work, but I have an alternate patch that uses PanFinish and doesn't need to keep the dx and dy around.

Uses the PanFinish event, which is only fired after a pan, not a click.

Comment on attachment 507037 [details] [diff] [review] panfinish patch Great!

pushed: http://hg.mozilla.org/mobile-browser/rev/da68f67cc6ad

If I go to http://people.mozilla.org/~bstover/iframe3.html and click on "test link" nothing happens. Is this ok?

In Firefox 4 and Google Chrome, clicking on the "test link" on http://people.mozilla.org/~bstover/iframe3.html scrolls to the start of the page (no idea why)

I've tested on Fennec trunk: Mozilla /5.0 (Android;Linux armv7l;rv:6.0a1) Gecko/20110512 Firefox/6.0a1 Fennec/6.0a1. So which is the correct behavior? Is this fixed?

No, I don't think the correct behavior is currently occuring. You should probably file a new bug. Probably something similar as what Firefox 4 desktop and Chrome desktop should be occuring.

Filed bug 656871. I'm closing this bug.