1. Load http://bl.ocks.org/mbostock/3680999 2. Try scrolling the mouse wheel to zoom the example. 3. The whole page will scroll, and the example will not zoom. Refreshing the page seems to fix the problem and the example in the iframe zooms as intended (while preventing the default behaviour of scrolling the page). I suspect this is related to the use of <iframe scrolling="no">. Without this, it seems to work on first load. Reproduced in WebKit nightly: Version 7.0 (9537.71, 538+) - first noticed in Safari Version 7.0 (9537.71).
Same thing here, Safari 7.1.2 (9537.85.11.5). No wheel event even after refresh. Chrome, Firefox, Opera, IE 9 - 11 seem to work fine.
According to Line 4358 in WebCore/page/FrameView, this is expected behavior: (see <http://trac.webkit.org/browser/trunk/Source/WebCore/page/FrameView.cpp#L4358>). In short, if an iframe is marked as non-scrollable, wheel events are not processed by this element. I'm not sure I understand why the author chose to mark the iframe as non-scrollable, but then wants that element to intercept and handle scroll events. It seems like the right behavior is to let the iframe accept scroll events, then provide your desired scroll event handlers to intercept and handle these events. If the "scrollable='no'" was needed to support proper behavior in other browsers, it seems like this is a bug in those implementations. I'm marking this as 'INVALID', where that just means "works as expected".
I will admit that I don't like that it works after refreshing. It seems like this should always work or not work. :-\
Hello, thanks for looking into this! I'm afraid I disagree that this is working as expected: my understanding is that the "scrolling" attribute indicates whether or not a scrollbar should be shown for the iframe, not whether mouse wheel events should be blocked. This seems to be the interpretation of Chrome/Firefox/IE too. As far as I know, there isn't any other way to disable the scrollbar, and I think blocking mouse wheel events inadvertently prevents desired behaviour for pages within the iframe (mouse wheel is commonly used for zooming maps, for example).
(In reply to comment #4) > Hello, thanks for looking into this! > > I'm afraid I disagree that this is working as expected: my understanding is > that the "scrolling" attribute indicates whether or not a scrollbar should > be shown for the iframe, not whether mouse wheel events should be blocked. 'scrolling' isn't specified for iframe in the HTML5, so it's hard to know what behavior is best here. <https://html.spec.whatwg.org/multipage/embedded-content.html#the-iframe-element>. HTML4 doesn't specify how wheel events should be interpreted when the iframe has its scrolling attribute set to 'no'. It merely requires that no scrolling devices for the frame be provided, which we comply with. > This seems to be the interpretation of Chrome/Firefox/IE too. As far as I > know, there isn't any other way to disable the scrollbar, and I think > blocking mouse wheel events inadvertently prevents desired behaviour for > pages within the iframe (mouse wheel is commonly used for zooming maps, for > example). Does using the CSS3 "overflow:hidden" not work the way you would like? This might need to be combined with the iframe "seamless" attribute.
(In reply to comment #5) > > I'm afraid I disagree that this is working as expected: my understanding is > > that the "scrolling" attribute indicates whether or not a scrollbar should > > be shown for the iframe, not whether mouse wheel events should be blocked. > > 'scrolling' isn't specified for iframe in the HTML5, so it's hard to know > what behavior is best here. > <https://html.spec.whatwg.org/multipage/embedded-content.html#the-iframe- > element>. > > HTML4 doesn't specify how wheel events should be interpreted when the iframe > has its scrolling attribute set to 'no'. It merely requires that no > scrolling devices for the frame be provided, which we comply with. Right. Although it doesn't seem to be in any of the specs, I would argue that the "scrolling" attribute is about enabling/disabling the scrollbar only, and wheel events should still propagate to the iframe document. > > This seems to be the interpretation of Chrome/Firefox/IE too. As far as I > > know, there isn't any other way to disable the scrollbar, and I think > > blocking mouse wheel events inadvertently prevents desired behaviour for > > pages within the iframe (mouse wheel is commonly used for zooming maps, for > > example). > > Does using the CSS3 "overflow:hidden" not work the way you would like? This > might need to be combined with the iframe "seamless" attribute. It doesn't really help in our case on http://bl.ocks.org/ - because we want to disable the scrollbar for any iframe document (i.e. that we don't have control over). Using <iframe style="overflow:hidden"> doesn't work in current browsers. I appreciate that it's a bit of an edge case - if you *do* have control over the iframe document then it's not an issue as you can set overflow:hidden within the iframe document. I think the reason scrolling="no" was dropped for HTML5 is that overflow:hidden is the intended replacement, but unfortunately there isn't any browser support for it right now on the iframe itself. I think the ideal resolution here would be for scrolling="no" to avoid blocking the wheel event from propagating to the iframe document, i.e. it should only disable the scrollbar. This would essentially be the same as overflow:hidden (when it is eventually supported). This would be: a) consistent with other mainstream browsers: Chrome/Firefox/IE. b) consistent with the current behaviour on refreshing (!) c) preserve functionality for wheel-enabled JavaScript pages embedded in an iframe which wants to hide its scrollbars. Thanks!
(In reply to comment #0) > 1. Load http://bl.ocks.org/mbostock/3680999 > 2. Try scrolling the mouse wheel to zoom the example. > 3. The whole page will scroll, and the example will not zoom. > > Refreshing the page seems to fix the problem and the example in the iframe > zooms as intended (while preventing the default behaviour of scrolling the > page). (In reply to comment #6) > It doesn't really help in our case on http://bl.ocks.org/ - because we want > to disable the scrollbar for any iframe document (i.e. that we don't have > control over). Using <iframe style="overflow:hidden"> doesn't work in > current browsers. I ran into the same issue today and have a workaround for you. My situation is similar, except I'm providing an iframe with zoomable content for 3rd parties to embed (so I don't have control over the page embedding the content, unlike you). Also, I'm not using scrollable='no' and I still have an issue, except for me it doesn't go away after a refresh. Here's the workaround. 1. Follow your reproduction steps (loading http://bl.ocks.org/mbostock/3680999, not being able to zoom) 2. Open the Safari dev tools and run the following code: var f = function() {}; document.addEventListener("mousewheel", f); document.removeEventListener("mousewheel", f); 3. Now you can zoom the iframe. Just adding the event listener fixes the issue (even though it's never triggered). Another method (which I'm using) is to set onmousewheel="" on the iframe. Hope this helps, Hal
<rdar://problem/19387598>
Jason -- did you implement Hal's workaround? When I visit <http://bl.ocks.org/mbostock/3680999> with a current build, I don't see the problem anymore. I may have inadvertently fixed this with some other scroll latching changes I made in the past few months, but I'd like to confirm with you.
(In reply to comment #9) > Jason -- did you implement Hal's workaround? When I visit > <http://bl.ocks.org/mbostock/3680999> with a current build, I don't see the > problem anymore. No workaround has been implemented. > I may have inadvertently fixed this with some other scroll latching changes > I made in the past few months, but I'd like to confirm with you. I can confirm this is now working in WebKit Nightly (10600.8.9, r188900). The problem persists in latest Safari Version 8.0.8 (10600.8.9) on OS X 10.10.5, but I assume that's because the fix hasn't made it to a Safari release yet?
(In reply to comment #10) > (In reply to comment #9) > > Jason -- did you implement Hal's workaround? When I visit > > <http://bl.ocks.org/mbostock/3680999> with a current build, I don't see the > > problem anymore. > > No workaround has been implemented. > > > I may have inadvertently fixed this with some other scroll latching changes > > I made in the past few months, but I'd like to confirm with you. > > I can confirm this is now working in WebKit Nightly (10600.8.9, r188900). > The problem persists in latest Safari Version 8.0.8 (10600.8.9) on OS X > 10.10.5, but I assume that's because the fix hasn't made it to a Safari > release yet? Yes, though I need to make sure the fix gets into the Yosemite builds as well. I'll track down the specific fix that resolved this and update the bug. Thank you for looking into it!
This bug was corrected in Bug 142807 <http://trac.webkit.org/changeset/182215>. *** This bug has been marked as a duplicate of bug 142807 ***