307976 - Can no longer scroll with mousewheel in IFrame with scrolling=no set

Status: RESOLVED WONTFIX

(Core :: Layout, defect)

Description

[Aaron]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 (No IDN) Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 (No IDN) Firefox/1.4

I don't know if this is intentional, but it used to be that if an Iframe had
scrolling=no set, to remove the scroll bars, you could still use the mousewheel
to scroll up and down. I liked this for things like news tickers that used
IFrames and went too slowly and such. In FF 1.5b1 you can't do this. The only
way to scroll these is to press and hold the mouse wheel and drag it around,
which is much less precise and much harder to control the speed. The second
IFrame on http://www.htmlcodetutorial.com/frames/_IFRAME_SCROLLING.html is an
example.

Reproducible: Always

Steps to Reproduce:
1. place mouse over IFrame
2. Rotate mouse wheel downwards


Actual Results:  
Nothing happened

Expected Results:  
Iframe should have scrolled.

Comment 1

[Adam Guthrie]

Couldn't find a dupe of this. Confirming.

Comment 2

[Ria Klaassen (not reading all bugmail)]

The extension Smoothwheel makes this possible.

Comment 3

[Aaron]

But it used to not need it.

Comment 4

[Aaron]

I notice that this has not been fixed in the nightlies. I also can't find
anywhere that suggests that there are any plans to fix this. Is this going to be
fixed or just ignored?

Comment 5

[logan]

looks like this was caused by bug 259615

http://lxr.mozilla.org/mozilla/source/content/events/src/nsEventStateManager.cpp#1758

1758     nsPresContext::ScrollbarStyles ss =
1759       nsLayoutUtils::ScrollbarStylesOfView(scrollView);
1760     if (NS_STYLE_OVERFLOW_HIDDEN ==
1761         (aScrollHorizontal ? ss.mHorizontal : ss.mVertical)) {
1762       continue;
1763     }

with this is commented, (mwheel) scrolling works

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think this should be wontfix:  scrolling=no should mean it (for scrolling by
the user, at least).  When users scroll something that has no visible scrolling
mechanism, it's easy for them not to understand what they did, especially if it
means that a part of the page that used to have something in it suddenly becomes
blank.

Comment 7

[Hixie (not reading bugmail)]

dbaron: in that case shouldn't we also fail for the panning mode? Is there a bug
on that?

Comment 8

[Adam Guthrie]

*** Bug 316288 has been marked as a duplicate of this bug. ***

Comment 9

[Jesse Ruderman]

I sent an email to the author of http://www.boingboing.net/2006/06/03/hideous_company_send.html asking him to remove the scrollbars=no that prevents me from seeing most of the image.

Comment 11

[Carlo Alberto Ferraris]

Even if this was closed, the problem outlined in comment #7 still is there in fx3 (both via autoscrolling and via keyboard scrolling).
Moreover, in comment #6, dbaron itself noted that "scrolling=no should mean it (for scrolling by the user, at least)". The problem is that this patch also affects extension developers (like me) by binding the visibility of the scrollbars to the "scrollability" of the page: in fact setting overflow:hidden and window.scrollbars.visibile = false yields the same result (no scrollbars and no wheel scrolling). But while for the former the current behaviour is correct (according to the CSS specs), for the latter it is not IMO.
The first part of this comment fully belongs to this bug, while the second may need a separate bug. If that's the case, I'll fill it ASAP.

Comment 12

[Carlo Alberto Ferraris]

To avoid posting in a closed bug, I filed two new bugs regarding this: bug 453639 and bug 460725.