Closed
Bug 1259135
Opened 8 years ago
Closed 8 years ago
Schedule at https://www.rightscon.org/program/ does not scroll with the mouse wheel
Categories
(Web Compatibility :: Desktop, defect)
Web Compatibility
Desktop
Tracking
(firefox48 affected)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox48 | --- | affected |
People
(Reporter: botond, Assigned: adamopenweb)
Details
(Whiteboard: btpp-followup-2016-04-26 [sitewait])
STR: 1. Load https://www.rightscon.org/program/ 2. Scroll down to bring the schedule into view 3. With the mouse over the schedule, scroll with the wheel Expected results: The page scrolls. Actual results: The page does not scroll. If you move the mouse close to the left or right edge of the page instead of being over the schedule, it scrolls.
Reporter | ||
Comment 1•8 years ago
|
||
This happens with APZ disabled as well, and is broken at least as far back as Firefox 44. It does work in Chrome.
Component: Panning and Zooming → DOM: Events
Comment 2•8 years ago
|
||
On OS X, Chrome Canary shows the same behavior as Nightly. The part of the page that ignores scrolling is an iframe with scrolling=no. Outside of the iframe, JS processes MozMousePixelScroll events, preventDefaults them, and translates them into JS scrolling.
Reporter | ||
Comment 3•8 years ago
|
||
Should this be an evangelism bug, then?
Comment 4•8 years ago
|
||
I'm not 100% sure yet why scrolling over the iframe doesn't work. The MozMousePixelScroll listener of the outer document doesn't seem to be called, so it can't preventDefault the event, so our default handling should hand off the scroll from the unscrollable iframe to the outer page.
Comment 5•8 years ago
|
||
Olli, what do you think?
Flags: needinfo?(bugs)
Whiteboard: btpp-followup-2016-04-26
Comment 6•8 years ago
|
||
So the iframe which contains the schedule has scrolling=no. FWIW, I couldn't get the page to scroll at all in Edge when using wheel. And with IE the top level page scrolls, but the scheduled area doesn't. Per spec "If the Document is in a nested browsing context, and the browsing context container of that nested browsing context is a frame or iframe element, and that element has a scrolling attribute, and that attribute's value is an ASCII case-insensitive match for the string "off", "noscroll", or "no", then the user agent is expected to prevent any scroll bars from being shown for the viewport of the nested browsing context, regardless of the 'overflow' property that applies to that viewport." It is clear whether scrolling should still happen.
Component: DOM: Events → DOM: Core & HTML
Flags: needinfo?(bugs)
Comment 7•8 years ago
|
||
blink doesn't seem to allow scrolling overflow: hidden, but scrolling: no is handled differently there, apparently :/
Comment 8•8 years ago
|
||
Hmm, wait, I was testing something wrong. Blink doesn't seem to scroll it either, as was said in comment 2.
Updated•8 years ago
|
Component: DOM: Core & HTML → Desktop
Product: Core → Tech Evangelism
Assignee | ||
Comment 9•8 years ago
|
||
Let's try reaching out on twitter. https://twitter.com/MozWebCompat/status/735488419405672449
Assignee: nobody → astevenson
Status: NEW → ASSIGNED
Whiteboard: btpp-followup-2016-04-26 → btpp-followup-2016-04-26 [sitewait]
Comment 10•8 years ago
|
||
> @MozWebCompat Hi Mozilla! We've had a hard time fixing that problem, so we just got rid of the embedded program altogether. — http://twitter.com/nick_dagostino/status/735581458354589697 > @MozWebCompat Not sure what the problem was though :/ . We'd love to embed the program for next year but would like scrolling obviously! — http://twitter.com/nick_dagostino/status/735581666698264581 This is "fixed". Though I guess a thorough explanation would be useful for them.
Comment 11•8 years ago
|
||
Since they have removed the feature, we have to take some shortcuts to investigate.. Open devtools, run these commands in the console: var ifr = document.body.insertBefore(document.createElement('iframe'), document.body.firstChild); ifr.scrolling = 'no'; ifr.style.height = '1000px'; Observe how mouse scroll above this IFRAME does not work. Do the same on, say, example.com and observe how the mouse scroll *does* work. Now, run these commands on both sites: document.addEventListener('MozMousePixelScroll', function(e){console.log(e.type)}, false); document.addEventListener('DOMMouseScroll', function(e){console.log(e.type)}, false); document.addEventListener('scroll', function(e){console.log(e.type)}, false); Observe how mousewheel scrolling above the IFRAME will *not* fire those two former events - only "scroll" fires on example.com, no events at all on rightscon. The rightscon site sets overflow:hidden on the HTML element. This is why scroll actions "bubbling" up from the IFRAME has no effect. And Firefox does not fire DOMMouseScroll and MozMousePixelScroll on parent when IFRAME contents is the target of a mouse scroll, so we never trigger the JavaScript-based scrolling.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Updated•5 years ago
|
Product: Tech Evangelism → Web Compatibility
You need to log in
before you can comment on or make changes to this bug.
Description
•