Open Bug 428350 Opened 16 years ago Updated 2 years ago

For tall iframes (taller than viewport), scrollwheel scrolling stops before bottom of frame is visible

Categories

(Core :: General, defect)

defect

Tracking

()

REOPENED

People

(Reporter: brian, Unassigned)

References

Details

(Keywords: regression, testcase)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5

For pages with large iframes, I can move my mouse over the iframe and start scrolling down with the scrollwheel, and the iframe will start scrolling.  However, if the bottom of the iframe scrollbar is reached while the actual bottom of the iframe is still off the bottom edge of the main window, scrolling will stop before I can read the end of the iframe's contents.

If I wait a few seconds, or click in the iframe, the scrollwheel will start to scroll the main page, but it would be nice to see the whole iframe without needing to do this.

Reproducible: Always

Steps to Reproduce:
1. Resize window so iframe extends off the bottom
2. Move mouse pointer over iframe and start scrolling down
Actual Results:  
Scrolling will stop before bottom of iframe is visible

Expected Results:  
Scrolling continues (i.e., the main window starts scrolling down) at least until the bottom of the iframe is visible.

This used to work in Firefox 1 and 2.  It seems related to the discussion in bug 187043 though I would argue that this particular case should still transfer the scrollwheel focus to the main window.  I've made a test case derived from Daniel Clemente's testcase on bug 192422, which I'll attach after submitting.
Derived from Daniel Clemente's testcase on bug 192422
Status: UNCONFIRMED → NEW
Ever confirmed: true
I can reproduce this bug in the Linux FF3 nightly from today (20080414).  
I can confirm that the bug isn't present in FF2 on Linux.

I wonder...
 - if this was an intentional change?
 - if this happens with textboxes as well?
Keywords: regression, testcase
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: general → general
Hardware: Macintosh → All
Version: unspecified → Trunk
I think I notice this in the nightlies on YouTube scrolling over the right iFrame while watching a video.  Once you hit the end, it transfers scrolling to the main page either on the top or bottom of the iframe.
This is interesting. I'll check this.
Blocks: 312831
I can not reproduce this issue on Mozilla/5.0 (Windows NT 6.3; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0

Can you still reproduce this issue?
Flags: needinfo?(dholbert)
Thanks for noticing! Yeah, this is WORKSFORME in current Nightly.

Notes:
 - Initially, the iframe is blank, in current nightly, and browser console shows "Blocked loading mixed active content "http://www.gnu.org/licenses/gpl.txt").  So: to actually test the bug, you have to do an "unsafe reload" by clicking the lock icon in URL bar, clicking the arrow, and then clicking "Disable protection for now".

 - After performing those steps (so that the iframe has a bunch of text in it): if I mousewheel-scroll while my cursor is hovering over the iframe, then when I hit the bottom of the iframe, then the full (the outer viewport) starts scrolling, which is the "Expected Results" from comment 0.

So, this is WORKSFORME in Nightly 48.0a1 (2016-04-18) (and probably older builds as well).
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(dholbert)
Resolution: --- → WORKSFORME
Actually, I misspoke -- the outer viewport only starts scrolling if I jiggle my cursor after hitting the bottom of the iframe.

If I don't move my cursor at all, then I still get ACTUAL RESULTS as described in comment 0. --> Reopening.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Here's a testcase that doesn't require an unsafe reload & which reproduces the bug. (As noted in my previous comment, you have to be very careful to *keep the mouse-cursor absolutely still* while mousewheel-scrolling, in order to trigger the bug.)

If it matters, I'm using 64-bit Ubuntu 16.04 Linux as my operating system, with a USB scrollwheel-mouse.
Yes Daniel, I agree. If the cursor is not moved then the page stops scrolling at the end of the iframe. Any idea on who to pass this off to?
Flags: needinfo?(dholbert)
Maybe masayuki, given the interest he expressed in comment 4. Punting needinfo to him.

(I know he's worked on event-handling code & input-methods stuff, and this seems to be in that neighborhood.)
Flags: needinfo?(dholbert) → needinfo?(masayuki)
# Sorry for the delay to reply.

Hmm, it's odd. This should've been fixed by bug 442774. Actually, try to test from bottom to top, scroll target is changed from the iframe to root scrollable element after 1 sec. I'm still not sure why the target isn't changed when you continue to scroll the whole page to the bottom-most on the iframe...
Flags: needinfo?(masayuki)
Oh, disabling APZ, that works!
Flags: needinfo?(mstange)
Can somebody clarify what this bug is about? What I'm gathering is:
 - In a current nightly, with APZ off, there is no bug.
 - In a current nightly, with APZ on, there is a bug. And the bug is that scrolling the iframe downwards with a mouse wheel isn't handed off to scroll the outer page once you hit the bottom of the iframe, even if you wait multiple seconds before scrolling again. *Unless* you move your mouse - if you do that, we scroll the outer page as expected.

Did I understand this correctly?
Flags: needinfo?(mstange)
I wonder whether the patch in bug 1265513 had any effect on this.
Your summary in comment 13 is correct, yes.
Kats, do you want to look into this?
Flags: needinfo?(bugmail.mozilla)
Summary: For tall iframes, scrollwheel scrolling stops before bottom of frame is visible → For tall iframes (taller than viewport), scrollwheel scrolling stops before bottom of frame is visible
(In reply to Markus Stange [:mstange] from comment #13)
>  - In a current nightly, with APZ off, there is no bug.
>  - In a current nightly, with APZ on, there is a bug. And the bug is that
> scrolling the iframe downwards with a mouse wheel isn't handed off to scroll
> the outer page once you hit the bottom of the iframe, even if you wait
> multiple seconds before scrolling again. *Unless* you move your mouse - if
> you do that, we scroll the outer page as expected.

I can't reproduce this with today's nightly on either Windows or Linux.
(In reply to Botond Ballo [:botond] from comment #17)
> I can't reproduce this with today's nightly on either Windows or Linux.

FWIW, I've also verified that APZ doesn't receive a stray mouse-move event that triggers the transaction timeout - that is, the timeout is triggered correctly even if no such mouse-move event is received.
OK, re-tested this today myself (on latest linux nightly) in light of new information RE APZ & "waiting multiple seconds" being a relevant thing to test.

My current results:
 (1) APZ has no effect for me (I see the same behavior regardless of layers.async-pan-zoom.enabled )
 (2) If I wait a few seconds between scroll operations, then I don't see any bugs.
 (3) If I'm impatient (continuously scrolling w/ mouse hovering the iframe), then I still see the bug (scrolling stops when the iframe is scrolled to its bottom, despite the fact that the outer viewport still has room to be scrolled).  But after one or two seconds of attempting to scroll, then the outer viewport will finally start to scroll.  So, it's a temporary issue.

So: the problem here, as I see it, is that there's this one-to-two-second "limbo" period when my mousewheel scroll-down operations mysteriously have no effect.

(Note: To ensure that my cursor doesn't move [e.g. during my few-second wait], I'm *picking my mouse up off of the table* when performing scrollwheel operations. AFAICT, this prevents any accidental cursor movement.)
Ah, ok. In that case, what you're seeing is the intended behavior. But maybe we should reduce the timeout.
Flags: needinfo?(bugmail.mozilla)
I was also unable to reproduce this on OS X, I haven't tried Linux yet.

(In reply to Daniel Holbert [:dholbert] from comment #19)
>  (2) If I wait a few seconds between scroll operations, then I don't see any
> bugs.

This is likely because a mousewheel transaction times out after mousewheel.transaction.timeout ms (currently 1500).

> So: the problem here, as I see it, is that there's this one-to-two-second
> "limbo" period when my mousewheel scroll-down operations mysteriously have
> no effect.

I think this is basically the intended behaviour, because we don't want to hand off the scroll right away as part of the same transaction.

> (Note: To ensure that my cursor doesn't move [e.g. during my few-second
> wait], I'm *picking my mouse up off of the table* when performing
> scrollwheel operations. AFAICT, this prevents any accidental cursor
> movement.)

I added a mousemove listener to the iframe document that logged Date.now() to the console to verify it wasn't getting hit.
So on Linux I see the same behaviour that dholbert is seeing. The only thing that we could change here is to reduce mousewheel.transaction.timeout; Masayuki, what do you think? If we're not going to reduce it then we should just close this bug as WFM.
Flags: needinfo?(masayuki)
Reducing to 0 doesn't make sense because the original purpose of the wheel transaction system is "blocking" unexpected scroll. In the testcase, that means that reaching scrollbar to the bottom-most (or top-most) outside the viewport shouldn't cause switching the scroll target to the parent *immediately*. I.e., users can know if the scrollable element reaches to the end of scrollable range by nothing scrolled.

However, I can agree with that 1.5 sec may be too long in this case. We can create new timeout only for this case (i.e., when users try to scroll outer scrollable element even after current target is scrolled).

Um, it might be possible to fix this bug with accumulating overflown delta values instead of creating another timeout, though.
Flags: needinfo?(masayuki)
Both of those options sound like more work than I'm willing to put into this at the moment. Leaving it if anybody else wants to do it, but I'd rather we just closed this bug as WFM.
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.