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




13 years ago
10 years ago


(Reporter: shoofy, Unassigned)



Firefox Tracking Flags

(Not tracked)





13 years ago
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 is an

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

13 years ago
Couldn't find a dupe of this. Confirming.
Severity: minor → normal
Component: General → Layout
Ever confirmed: true
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → layout
Hardware: PC → All
Version: unspecified → Trunk
The extension Smoothwheel makes this possible.

Comment 3

13 years ago
But it used to not need it.

Comment 4

13 years ago
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

13 years ago
looks like this was caused by bug 259615

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

with this is commented, (mwheel) scrolling works
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
Last Resolved: 13 years ago
Resolution: --- → WONTFIX
dbaron: in that case shouldn't we also fail for the panning mode? Is there a bug
on that?

Comment 8

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

Comment 9

13 years ago
I sent an email to the author of asking him to remove the scrollbars=no that prevents me from seeing most of the image.


13 years ago
Summary: Scrolling with mousewheel in IFrame with scrolling=no set → Can no longer scroll with mousewheel in IFrame with scrolling=no set
Duplicate of this bug: 318493
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.
To avoid posting in a closed bug, I filed two new bugs regarding this: bug 453639 and bug 460725.
You need to log in before you can comment on or make changes to this bug.