Closed Bug 187043 Opened 22 years ago Closed 14 years ago

Iframes should only scroll with mousewheel when focused, not when the mouse is over them

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

x86
All
defect
Not set
minor

Tracking

()

RESOLVED INVALID

People

(Reporter: weeber51, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20021226
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20021226

I use my mousewheel for scrolling through documents, and Mozilla seems to
generally scroll the frame that the cursor is positioned over. So on most pages,
the page scrolls, on pages with frames, the frame containing the cursor is
scrolled. But it seems to me that, at the least, the behavior for iframes should
be different. Since iframes are contained within pages rather than being pretty
much top-level, they are much more like form text boxes than frames as far as
end-users are concerned. When scrolling a page, it's unpredictable when the
cursor may fall inside an iframe. It seems undesirable that, while scrolling
through a page, the scrolling suddenly may stop and instead an iframe
scrolls--just as it would be undesirable for a form text box to scroll instead
of the page when the mouse happens to lie inside one. So I would suggest
breaking consistency with frames and following scrolling text boxes and other
scrolling elements (like divs): instead of scrolling iframes when the mouse is
over them, scroll when they have focus.

Otherwise, maybe all frames should follow this behavior, in which case iframes
would be consistent with frames and other scrolling elements. But this would
bring back the old hassle in NN where you had to click a frame before you could
scroll through it.

For me, Bugzilla has been the biggest culprit. Whenever I submit a bug
(http://bugzilla.mozilla.org/enter_bug.cgi?product=Browser), that annoying
iframe in step 1 always grabs my scrolling! I do all my duplicate checking
through the query page, so I'd much rather skip through step 1, but instead I
have to scroll before the iframe loads, use the keyboard, scroll to the end of
the iframe, or move my mouse to a margin outside the iframe to fill my bug report.

(My, wouldn't it be embarassing if THIS bug was a duplicate?)

Reproducible: Always

Steps to Reproduce:
1.Goto http://bugzilla.mozilla.org/enter_bug.cgi?product=Browser
2.Try to scroll down the page (after the iframe has loaded)

Actual Results:  
Scrolling of page stops when iframe scrolls under mouse, and iframe scrolls.

Expected Results:  
Smooth, continuous scrolling of page.
*** Bug 308540 has been marked as a duplicate of this bug. ***
i think the current behavior works fine.

saves unnecessary clicking.
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
Same issue on Linux.  It even extends to other scrolling elements such as <select>:

  https://bugzilla.mozilla.org/attachment.cgi?id=49410

There seem to be two points of view here:

* Some like mousewheel scrolling scroll the element under the pointer,
  which leads to annoying behaviour when the element being scrolled changes.

* Some like mousewheel scrolling to scroll the element that has
 (keyboard) focus, which requires a little more clicking. 

An improvement that could be made over the scroll-element-under-pointer design is to only change the scrolling element (scroll focus) when the *mouse is moved* to another element, not when an element moves (due to scrolling) under the mouse.  This is similar to the focus-follows-mouse policy used by some window managers.
OS: Windows 2000 → All
(In reply to comment #4)

> An improvement that could be made over the scroll-element-under-pointer design
> is to only change the scrolling element (scroll focus) when the *mouse is
> moved* to another element, not when an element moves (due to scrolling) under
> the mouse.  This is similar to the focus-follows-mouse policy used by some
> window managers.

This has pretty much been implemented in trunk.  Although the trunk policy is to change scroll focus when the mouse is moved *within* an element as well as *to* the element.

Assignee: jag → nobody
We designed current behavior intentionally. So, this is not unexpected bug.

However, if you find some problems like bug 49410, please file them.
Status: NEW → RESOLVED
Closed: 14 years ago
Component: XUL → Event Handling
QA Contact: jrgmorrison → events
Resolution: --- → INVALID
(In reply to comment #6)
> We designed current behavior intentionally. So, this is not unexpected bug.
> 
> However, if you find some problems like bug 49410, please file them.

bug 312831 is right bug. sorry for the spam.
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.