Closed Bug 1259135 Opened 4 years ago Closed 4 years ago

Schedule at https://www.rightscon.org/program/ does not scroll with the mouse wheel

Categories

(Web Compatibility :: Desktop, defect)

defect
Not set

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.
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
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.
Should this be an evangelism bug, then?
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.
Olli, what do you think?
Flags: needinfo?(bugs)
Whiteboard: btpp-followup-2016-04-26
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)
blink doesn't seem to allow scrolling overflow: hidden, but scrolling: no is handled differently there, apparently :/
Hmm, wait, I was testing something wrong. Blink doesn't seem to scroll it either, as was said in comment 2.
Component: DOM: Core & HTML → Desktop
Product: Core → Tech Evangelism
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]
> @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.
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: 4 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.