User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

On this website right scrollbar is missing. Can't scroll down even with key Page Down.

https://informalia.eleconomista.es/informalia/actualidad/noticias/11186763/04/21/Isabel-Diaz-Ayuso-En-Madrid-puedes-cambiar-de-pareja-y-no-encontrartela-mas-pero-ella-se-ve-con-su-ex.html

Also CPU usage is very high.

The Bugbug bot thinks this bug should belong to the 'Core::Panning and Zooming' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

The body element has overflow hidden set on it. I get the same behaviour in Chrome.

So I can reproduce that the first time I load the site, and after clicking "accept" in the cookie banner, Firefox can't scroll but Chrome can.

Disabling ETP fixes it for me (after clearing site data etc so the cookie banner appears again).

I can't reproduce this, is it still broken for you?

I can still reproduce this issue, but it seems to me that it doesn't relate to ETP. So, the issue disappears even with ETP is on sometimes, and disabling ETP doesn't always fix this issue, I can still reproduce this.

Refreshing the page always fixes this issue regardless ETP is on or off.

And note that I can also reproduce this in Chrome.

(In reply to Tim Huang[:timhuang] from comment #7)

And note that I can also reproduce this in Chrome.

Sounds like a site issue then.

Agreed. I think the site has some JS that it intends to run, to remove the noscroll class from their body element (which is what is supposed to make the scrollbar show up by unapplying that class's overflow:hidden), but that JS fails to run in Firefox, probably because a JS exception is thrown in some ads-related code before the page gets to that point, and the page doesn't catch the exception, so JS execution stops. So, this isn't a layout/scrolling bug; it's a bug with whatever is causing the JS to throw an exception (possibly a site bug).

My testing results, FWIW:

• I can reproduce in Firefox (the first time I load the site ever, and the first time in a new private browsing session).
• I can sometimes reproduce in Firefox with ETP disabled (I only tested this in private browsing mode since that's the easiest way to reset the cookie-banner state; not sure if that matters).
• I cannot reproduce in Chrome (tried twice and it was fine both times)

Also: in Firefox, I see a number of JS exceptions/errors, not sure if they're relevant but here they are:

• I get some cross-origin load failures for google-ads domains, followed by Uncaught ReferenceError: gapi is not defined and Uncaught (in promise) Error: No config could be discovered in the page (this latter one seems to be there always, I think [?] but the former one only seems to show up when ETP is enabled)
• When I accept the cookie banner, I get Ads by Google is being shimmed by Firefox. See https://bugzilla.mozilla.org/show_bug.cgi?id=1713726 for details.
• If I have ETP nerfed to "Custom: [uncheck all blockable things]" in Firefox's settings, then I got expected results twice and failed the third time. When it failed, I checked the console and saw an uncaught exception/error with this info:

message: "adsbygoogle.push() error: Only one 'enable_page_level_ads' allowed per page."
name: "TagError"

So it seems like there's at least a site bug here, and possibly also a weird interaction with ETP. I'll reclassify as WebCompat for now.

Aha, I just reproduced in Chrome after a few tries. I got the same "only one" exception there (along with the missing scrollbar):

adsbygoogle.js:69 Uncaught O message: "adsbygoogle.push() error: Only one 'enable_page_level_ads' allowed per page."name: "TagError"pbr: true stack:  [...]

So that's pretty-clearly a site bug, when that happens. There might also be a separate ETP bad-interaction here, though which causes the seemingly-100%-reliable failure when ETP is enabled, with Uncaught ReferenceError: gapi is not defined in the console being possibly associated. Presumably Chrome would hit that failure as well if the site's google-ad-script failed to load.

ni=twisniewski in case he's interested to take a look; it looks like we're shimming google ads here but it's not quite working (otherwise gapi might be defined, I assume).

Yes, your analysis makes sense to me, Daniel. I will investigate improving the shim for Google Ads in bug 1723533 ASAP.

A shim fix for Google Ads just landed, and I no longer see the gapi error in strict ETP/private mode.

I was not able to reproduce the issue on Firefox Nightly normal mode (with any ETP options), but reproduced it on first access on private mode and only once on Chrome when first accessing the site.

Tested with:
Browser / Version: Firefox Nightly 98.0a1 (2022-02-03), Chrome 97.0.4692.99
Operating System: Windows 10 Pro

The issue still exists.

• on Firefox clean profile - reproducible with ETP - Strict
• on Firefox Private mode - reproducible on first access
• on Chrome the page becomes unresponsive
  https://prnt.sc/VgaMCqW9TVAl

Tested with:
Browser / Version: Firefox Nightly 103.0a1 (2022-06-23), Chrome 102.0.5060.53
Operating System: Windows 10 Pro