*Affected Versions:
Nightly 89.0a1

Tested On:
MacOS 10.15, MacOS 11 (M1)

Steps to reproduce:

1. Log in to Office 365
2. Open any created Excel document
3. Swipe up and down, right-left

Expected Results:
The elastic overscroll effect should not be enabled inside Excel Documents. (Safari behavior as well)

Actual Results:
The overscroll effect is enabled inside excel documents and it is not quite the best visual experience for users working in excel sheets. Recording: https://drive.google.com/file/d/1KEQSO5kODF0BretVIYUOkYKrS14MLTfS/view?usp=sharing

Notes:
Not reproducible in Google Sheets.
Not reproducible with Safari.
Not reproducible if I disable overscroll.

Is there an office 365 account that we can use to login and test this?

Yes, please check the direct messages on Element/Matrix.

The overscroll seems to get disabled some of the time when I open the devtools, but not always. Curious.

overscroll-behavior: none property should be explicitly specified? I wonder how Safari disallow overscrolling.

Per discussion with Martin, this should be a release blocker, but the fix for 89 can take the form of a site-specific intervention (e.g. always disable overscroll on this domain) rather than a fix of the underlying cause (which remains to be determined, and may even end up being an issue on the site side).

I'm going to venture a guess that we have some sort of infrastructure / process in place to make such site-specific interventions. Martin, do you know who I could talk to about this to coordinate?

The webcompat team might have some ideas here. They maintain a set of site interventions. Maybe :karlcow can help?!

Question what is the domain this site intervention should happen?

• https://www.office.com/?auth=1
• or https://onedrive.live.com/
• or https://excel.officeapps.live.com

What is happening for Corporate instances?

We need to find out on which element overscroll-behavior: none this should be added.

(In reply to Karl Dubost💡 :karlcow from comment #7)

We need to find out on which element overscroll-behavior: none this should be added.

In local testing on office.com, adding overscroll-behavior: none to the following element successfully disabled the overscroll:

<div id="m_excelWebRenderer_ewaCtl_sheetContentDiv" class="ewr-sheetcontainer ewr-grdblkcontainer ewa-scrollbars" role="presentation" style="user-select: none; height: 438px; width: 1222px;">

Question what is the domain this site intervention should happen?

That's a good question. My suggestion would be https://onedrive.live.com/ and https://*.sharepoint.com. I hope this will cover most cases.

We need to find out on which element overscroll-behavior: none this should be added.

I can confirm the element that Botond has identified.

This intervention should be temporary and hopefully no longer required in Fx90. Also, note that it only needs to apply on OS X as that's our first target.

I was trying to reproduce to see what's going on there but I couldn't. Now I noticed opening devtools prevents overscrolling regardless whether the devtools window is inside the same browser window or not. I remember Timothy told us he saw this behavior in a site (I don't recall the site name).

It was this site, see comment 3.

lol. I am idiot. :)

Anyway, I found a way to reproduce this issue on Safari. There is an event listener for "scroll" event on the element in comment 8; The listener is;

function(t) {
  return i.call(n, new Sys.UI.DomEvent(t))
}

Disabling this event listener makes this issue happen on Safari.

So the difference about scroll event between Safari and us is Safari does fire scroll events during overscrolling, we don't. That's the reason why Safari doesn't overscroll with the scroll event handler.

As far as I can tell Chrome does seem like it doesn't overscroll at all in child scroll containers?

That's correct. Chrome behaves differently here and always overscrolls the top level page.

I have no clear opinion on what behavior is more desirable at the moment. Safari's behavior appeals a bit more to me, but a stable experience is preferable. Are there technical reasons that would make us prefer one way over the other?

(In reply to Hiroyuki Ikezoe (:hiro) from comment #13)

So the difference about scroll event between Safari and us is Safari does fire scroll events during overscrolling, we don't. That's the reason why Safari doesn't overscroll with the scroll event handler.

Huh, that's interesting.

I'm not sure I understand the logic behind it. If you suppress overscroll for elements with scroll event handlers, then it seems like no one gets a chance to observe the scroll events fired during overscroll. So why fire them?

As far as I can tell Chrome does seem like it doesn't overscroll at all in child scroll containers?

(In reply to Martin Balfanz [:mbalfanz] from comment #14)

That's correct. Chrome behaves differently here and always overscrolls the top level page.

I have no clear opinion on what behavior is more desirable at the moment. Safari's behavior appeals a bit more to me, but a stable experience is preferable. Are there technical reasons that would make us prefer one way over the other?

If you mean not overscrolling in child containers (subframes), then no, it would be technically straightforward for us to switch to that.

However, I'll note that the existence of the overscroll-behavior CSS property seems to reflect a desire to do things like overscroll subframes. In particular, the contain value of this property prevents scroll handoff to the parent frame, while allowing local effects like overscroll. If subframes never overscrolled, there would be no reason for this property value to exist.

(In reply to Botond Ballo [:botond] from comment #15)

(In reply to Hiroyuki Ikezoe (:hiro) from comment #13)

So the difference about scroll event between Safari and us is Safari does fire scroll events during overscrolling, we don't. That's the reason why Safari doesn't overscroll with the scroll event handler.

Huh, that's interesting.

I'm not sure I understand the logic behind it. If you suppress overscroll for elements with scroll event handlers, then it seems like no one gets a chance to observe the scroll events fired during overscroll. So why fire them?

I haven't checked the behavior on the office site, I just checked it in a simple test case, so in the simple test case it's actually overscrolling.

(In reply to Martin Balfanz [:mbalfanz] from comment #14)

That's correct. Chrome behaves differently here and always overscrolls the top level page.

I have no clear opinion on what behavior is more desirable at the moment. Safari's behavior appeals a bit more to me, but a stable experience is preferable. Are there technical reasons that would make us prefer one way over the other?

If you mean not overscrolling in child containers (subframes), then no, it would be technically straightforward for us to switch to that.

However, I'll note that the existence of the overscroll-behavior CSS property seems to reflect a desire to do things like overscroll subframes. In particular, the contain value of this property prevents scroll handoff to the parent frame, while allowing local effects like overscroll. If subframes never overscrolled, there would be no reason for this property value to exist.

I guess, for completeness, I should mention that not having to support subframe overscrolling would mean there are certain bugs (e.g. bug 1701831) that we would no longer encounter and would not need to fix. (However, it's still not an outcome I would advocate for on that basis.)

(In reply to Hiroyuki Ikezoe (:hiro) from comment #10)

Now I noticed opening devtools prevents overscrolling regardless whether the devtools window is inside the same browser window or not.

I just realized that the reason for this is likely that we disable APZ for some subframes when the devtools is open.

Timea, once the updated intervention in bug 1707795 makes it into a nightly build, could you please try it and see if it resolves this issue? (If so, we'll proceed to uplift the intervention to 89.) Thanks!

Yes, we will verify it once it lands on Nightly and let you know. Keeping the NI? on me.

Confirming that overscroll is now disabled for excel documents on the latest Nightly 90.0a1 (2021-05-11) (64-bit) (Build ID: 20210511093339). Tested on MacOS 10.15, thanks for the fix! Will close this issue once the site intervention will be uplifted to Beta 89. Please also change the status flags to fixed for this issue as well so QA can further mark it as verified.

Request for Uplift from PM Team.

Let's dupe this over to bug 1707795, which added the webcompat intervention. I filed bug 1710754 to track any further platform-level work which may allow the intervention to be removed in the future.