Add Site intervention for live.com for excel sheets to remove the overscroll-behavior
Categories
(Web Compatibility :: Interventions, task)
Tracking
(firefox89+ verified, firefox90 verified)
People
(Reporter: karlcow, Assigned: twisniewski)
References
()
Details
(Whiteboard: [webcompat:sitepatch-applied])
Attachments
(2 files)
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details | Review |
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details | Review |
- Go to www.office.com
- Open a sheet with content
- Scroll down and up with inertia
Actual:
There is a white part being displayed. An overscroll effect that should be deactivated with overscroll-behavior: none
.
To determine which element this should happen.
Comment 1•4 years ago
•
|
||
Hey Thomas, wanted to check in to see how this is going. Do you know when this intervention might become available for QA to test on the Beta channel?
I ask because QA considers the overscroll behaviour on this site (particularly bug 1705699) a release blocker for the overscroll feature that we are hoping to ship in 89.
Note, I believe we identified the relevant element in bug 1705699 comment 8.
Please let me know if there's anything else I can do to help!
Assignee | ||
Comment 2•4 years ago
|
||
Apologies, I did not know that we wished to ship this for Firefox 89 (I'm currently working on site patches for Firefox 91).
If we're adamant about shipping in 89 (or 90), please let me know and I'll begin working on a patch which we could uplift. Assuming there are no complications, it should not take more than a day or two to get a patch here.
Comment 3•4 years ago
|
||
(In reply to Thomas Wisniewski [:twisniewski] from comment #2)
Apologies, I did not know that we wished to ship this for Firefox 89 (I'm currently working on site patches for Firefox 91).
Apologies for not communicating this more clearly.
If we're adamant about shipping in 89
I think we'd really like to ship overscroll in 89, yeah. At this stage we have only two release-blocker issues remaining, this one, and another which which has a fix in progress.
please let me know and I'll begin working on a patch which we could uplift. Assuming there are no complications, it should not take more than a day or two to get a patch here.
That would be greatly appreciated :)
Assignee | ||
Comment 4•4 years ago
|
||
Comment 6•4 years ago
|
||
bugherder |
Comment 7•4 years ago
|
||
To test this on Nightly, is there anything I need to do to "activate" the intervention? Or should it automatically be enabled for the affected sites?
Comment 8•4 years ago
•
|
||
Yeah, I just tested locally, and it's not working as expected.
I just noticed that the target element in question is inside an iframe, the iframe adress is "ttps://excel.officeapps.live.com/x/_layouts/xlviewerinternal.aspx?XXXX". So we should specify the "*.officeapps.live.com" I believe.
EDITED: Dropped "h" word from the address to avoid being linked.
Assignee | ||
Comment 9•4 years ago
|
||
Yes, the change should work without any changes. Based on Hiro's comment we will likely only need to add that subdomain to this list:
https://searchfox.org/mozilla-central/source/browser/extensions/webcompat/data/injections.js#441
I can update the patch, but I won't be able to confirm personally as my attempts to log into Office365 refuse to work. If anyone with an Office account wants to test on their own with a local m-c build, I will essentially just be changing that line to:
matches: ["*.officeapps.live.com/*", "*://onedrive.live.com/*", "*://*.sharepoint.com/*"],
Are we aware of any other (sub)domains we ought to be concerned about? I'm always hesitant to over-apply these site interventions, but given the CSS class involved (.ewr-sheetcontainer
) it seems as though it might be better to just apply it to all live.com subdomains:
matches: ["*.live.com/*", "*://*.sharepoint.com/*"],
Assignee | ||
Comment 10•4 years ago
|
||
Alright, I have managed to get a patch together which gets the CSS rule working. So it should be good with that (unless there are other domains we have to add later).
Assignee | ||
Comment 11•4 years ago
|
||
Comment 12•4 years ago
|
||
Assignee | ||
Updated•4 years ago
|
Comment 13•4 years ago
|
||
Thank you Thomas! With the additional change I've confirmed overscrolling is disabled.
Comment 14•4 years ago
|
||
bugherder |
Comment 15•4 years ago
|
||
Thanks for this fix! QA can also confirm that overscroll is now disabled for excel documents on the latest Nightly 90.0a1 (2021-05-11) (64-bit) (Build ID: 20210511093339). Marking is as verified for Nightly but please Uplift it to Beta89 when you have the chance, thank you!
Comment 16•4 years ago
|
||
Comment on attachment 9221187 [details]
Bug 1707795 - adjust the webcompat fix to disable overscroll effects on Excel spreadsheets; r?denschub
Beta/Release Uplift Approval Request
- User impact if declined: Users are able to overscroll Excel spreadsheets in Office 365 when they shouldn't (they can't in other browsers)
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This patch just injects an
overscroll-behavior: none
CSS property into Office 365 domains targeting the scrollable element in Excel sheets to disable overscroll for it. Therefore, its effect is targeted and cosmetic. - String changes made/needed:
Updated•4 years ago
|
Comment 17•4 years ago
|
||
Requested uplift per discussion with Thomas.
Please note that this fixes bug 1705699 which is tracked for 89.
Comment 19•4 years ago
|
||
[Tracking Requested - why for this release]: Carrying over tracking flag from bug 1705699 which was fixed by this and which I duped over to this.
Comment 20•4 years ago
•
|
||
Comment on attachment 9221187 [details]
Bug 1707795 - adjust the webcompat fix to disable overscroll effects on Excel spreadsheets; r?denschub
Approved for 89 beta 12, thanks.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 21•4 years ago
|
||
bugherder uplift |
Comment 22•4 years ago
•
|
||
Since issue is verified as fixed in our latest Beta 89.0b12 (20210513185752) on MacOS 10.14 and MacOS 11.2.3 can we close this issue ?
Thomas can you please remove the leave-open tag and update the Status flag to Fixed? so we can mark it as Verified ?
Assignee | ||
Comment 23•4 years ago
|
||
Yes, I believe this is now fixed on the necessary channels. Thanks for checking!
Comment 24•4 years ago
|
||
Thanks, Tom! Updating the status to verified-fixed based on Comment 23.
Updated•3 years ago
|
Description
•