MSN News site locks up

thefossil · Post by **thefossil** » 2025-12-27, 01:00

https://www.msn.com/en-us/news/us/minne ... a168&ei=22

Locks up Pale Moon on Win 11 Prof
Just get a finger pointer (ironic) but track pad on my Lenovo laptop won't work.
PgUp and PgDn buttons still work, however.

Content Security Policy: Couldn’t parse invalid host 'report-sample'
(unknown)
Content Security Policy: Couldn’t process unknown directive ‘report-to’
(unknown)
AST library loaded: 1.10.56
ast.js:5:126950
Use of removeAttributeNode() is deprecated. Use removeAttribute() instead.
microsoft.b73c16e0ec41b55b3d24.js:29:14377
unreachable code after return statement[Learn More]
en-us_script.js:1:87004
Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user’s experience. For more help http://xhr.spec.whatwg.org/
en-us_script.js:1:20172
Viewable Complete Fri Dec 26 2025 18:54:28 GMT-0600 (Central Standard Time) Object { percentViewable: 1, technique: "IntersectionObserver", viewable: true, viewportWidth: 300, viewportHeight: 250, elementWidth: 300, elementHeight: 250, iframeContext: "same domain iframe", focus: true }
v.js:50:15
Viewable Complete Fri Dec 26 2025 18:56:10 GMT-0600 (Central Standard Time) Object { percentViewable: 0.9842767295597484, technique: "IntersectionObserver", viewable: true, viewportWidth: 300, viewportHeight: 254, elementWidth: 300, elementHeight: 254, iframeContext: "same domain iframe", focus: true }
v.js:50:15
Viewable Complete Fri Dec 26 2025 18:56:10 GMT-0600 (Central Standard Time) Object { percentViewable: 0.9827044025157232, technique: "IntersectionObserver", viewable: true, viewportWidth: 970, viewportHeight: 254, elementWidth: 970, elementHeight: 254, iframeContext: "same domain iframe", focus: true }
v.js:50:15

Post by **jobbautista9** » 2025-12-27, 01:39

This is a bug in the website itself. The <body> is styled with overflow-x: clip without a corresponding overflow-y. This pretty much tells the browser that scrolling is not to be expected. See Issue #2853 (UXP)

A workaround is to revert them with userContent.css (you can use the Stylem extension for this). You can apply this globally (there isn't a good reason to change the overflow behavior of the html and body anyway AFAICS):

Code: Select all

@namespace url(http://www.w3.org/1999/xhtml);

@-moz-document url-prefix("http") {
  html, body, html body { overflow-x: revert !important; overflow-y: revert !important; }
}

Post by **Moonchild** » 2025-12-27, 10:04

Of course getting a hold of a webmaster at MSN (to let them know what they are doing wrong) will be almost impossible. I guess the best one can do is use the "feedback" widget on MSN pages.

THX-1139 · Post by **THX-1139** » 2025-12-27, 16:28

The site's page worked okay for me, no lock ups or crash and burns, the scrolling was a bit jankey but otherwise worked... But then I am still using Win7 pro (64)
Never made the move to win10, nor will I until all the mess is 'maybe' eventually, sorted out (I'm just too old to deal with all that BS at this time...my personal memory is shot..(not the PC's)

Enobarbous · Post by **Enobarbous** » 2025-12-27, 18:29

Moonchild wrote: ↑
2025-12-27, 10:04
Of course getting a hold of a webmaster at MSN (to let them know what they are doing wrong) will be almost impossible. I guess the best one can do is use the "feedback" widget on MSN pages.

I think we should make a change to how clip is handled. Sure, what we have now seems to match the spec, but it's poorly written, and website developers rely on behavior in other browsers.
Maybe we could add an additional setting? After all, we already have "button.standards_compliant"...
Because, based on my experience, our current clip implementation breaks more websites than it fixes.

Post by **Moonchild** » 2025-12-27, 19:01

Enobarbous wrote: ↑
2025-12-27, 18:29
I think we should make a change to how clip is handled.

I firmly disagree. The spec is very clear what it's for and how it should be used.

Enobarbous wrote: ↑
2025-12-27, 18:29
but it's poorly written

I had no trouble reading and understanding it without ambiguity, once I took a moment to go through it. So no, I don't think it's poorly written. Have you read it?

Enobarbous wrote: ↑
2025-12-27, 18:29
website developers rely on behavior in other browsers

Website developers rely on copy-pasting a rather nonsensical CSS rule across sites. There's not been given a reason whatsoever (other than hard-coding quirk behaviour into styling) why websites are even using this on full-page elements like HTML and BODY, to begin with. It seems to just be a case of "other sites do this so we do this too". Even if they want a specific rule to prevent full-page x-scrolling at all costs (which is the only somewhat understandable reason why a poorly-informed webmaster might add this...?) then they should be using overflow-x:hidden instead. The keyword clip behaves differently than hidden on purpose.

Enobarbous wrote: ↑
2025-12-27, 18:29
our current clip implementation breaks more websites than it fixes.

Probably not. Before our current clip implementation, more websites were broken (any site using clip, whether correctly or incorrectly). By definition, we fixed all sites using clip correctly. It just exposes incorrect use by having a standards implementation. Just because a mistake appears on higher-profile websites doesn't mean "we broke a large number of sites".

Enobarbous wrote: ↑
2025-12-27, 18:29
Maybe we could add an additional setting? After all, we already have "button.standards_compliant"...

No. Not being standards compliant and duplicating the quirk in this case would mean making specific element-by-element exceptions to standard behaviour. That is a lot more complicated than changing overall behaviour and would be introducing a lot of fragility and complexity just to compensate for very obvious wrong CSS use. The answer here is informing webmasters.

Enobarbous · Post by **Enobarbous** » 2025-12-27, 20:20

Moonchild wrote: ↑
2025-12-27, 19:01
I firmly disagree. The spec is very clear what it's for and how it should be used.

Ok. This is your browser.

Moonchild wrote: ↑
2025-12-27, 19:01
Have you read it?

Yes. Just like your comments in uxp#2853 and bug #1531609, and https://www.w3.org/TR/css-overflow-3/#o ... ropagation where

If visible is applied to the viewport, it must be interpreted as auto. If clip is applied to the viewport, it must be interpreted as hidden.

So yes, I think the specification is written quite strangely.
And there is also a discussion at https://github.com/w3c/csswg-drafts/issues/1971 that's a bit more confusing...

Moonchild wrote: ↑
2025-12-27, 19:01

Enobarbous wrote: ↑
2025-12-27, 18:29
our current clip implementation breaks more websites than it fixes.
Probably not. Before our current clip implementation, more websites were broken.

So, I'm unlucky with the websites I visit. My fault (?)

Moonchild wrote: ↑
2025-12-27, 19:01
Just because a mistake appears on higher-profile websites doesn't mean "we broke a large number of sites".

I agree, from a technical point of view, the websites aren't "broken." From a user perspective, it's more questionable...

Moonchild wrote: ↑
2025-12-27, 19:01

Enobarbous wrote: ↑
2025-12-27, 18:29
Maybe we could add an additional setting? After all, we already have "button.standards_compliant"...
No.

Ok. It was just a suggestion.

Enobarbous · Post by **Enobarbous** » 2025-12-27, 21:40

Moonchild wrote: ↑
2025-12-27, 19:01
Even if they want a specific rule to prevent full-page x-scrolling at all costs (which is the only somewhat understandable reason why a poorly-informed webmaster might add this...?) then they should be using overflow-x:hidden instead. The keyword clip behaves differently than hidden on purpose.

From what I've found, this is exactly what clip is used for for html and body. Hidden is not used because of how it interacts with position:sticky.
In the example

Code: Select all

html, body {
  overflow-x: hidden;
}

header { 
  position: sticky; 
  top: 0px;
}

sticky will not work, but if you replace hidden with clip, it will work.

Of course, this is not the only (and perhaps not the best) way to achieve these goals, but if all websites were written as perfectly as possible...

Post by **vannilla** » 2025-12-27, 23:03

Whenever I try to investigate overflow-x: clip all I see are examples for specific "sub-layouts" like hero images (the banners you see at the top of many service-selling websites) and never something about placing it on <body> or higher.
When it comes to "sub-layouts" it kind of makes sense: you want something to appear only partially like hero banners often want, but you can't edit the background picture because it's acceptable to see the whole thing on very large screens; CSS can then clip horizontally with all that entails, when hidden doesn't do the job quite right (the explanations I've read make a good case for clipping here).
I think clipping on <body> is part of the mentality of hoisting every definitions up and let children inherit them, then revert or override as needed. It's fine to let styles cascade (it's in the name!) but it's often done without any criteria and it's clearly wrong here.

Enobarbous · Post by **Enobarbous** » 2025-12-28, 00:06

vannilla wrote: ↑
2025-12-27, 23:03
I think clipping on <body> is part of the mentality of hoisting every definitions up and let children inherit them, then revert or override as needed.

That's it. But there also the issue of adaptability and dynamic content. If some content is added using js - ads or widgets, or the site is built like a spa - in this case, overflow becomes a problem on narrow screens. And clipping content at the body level looks no worse than the endless hell of nested div's.
Of course, this can be solved in other ways, but it's not always possible to control how the framework handles the addition of elements...

Enobarbous · Post by **Enobarbous** » 2025-12-29, 22:13

Moonchild wrote: ↑
2025-12-27, 19:01
By definition, we fixed all sites using clip correctly. It just exposes incorrect use by having a standards implementation.

I think I've found the reason why problems arise when clip is applied to body. A close comparison bug #1531609 and pr#2788, shows that for some reason MeladJM ignored the entire second part - “Implement overflow:clip/visible combinations” (of course, I'm no expert, but I don't see even part of the work that mozilla has done), as a result of which our implementation ignores section https://www.w3.org/TR/css-overflow-3/#o ... ropagation of the specification.
So I apologize for my words - the implementation of clip in pm is correct, just incomplete.

Post by **Moonchild** » 2025-12-30, 00:21

I see. there's an extra specced step/circumstance. While we do have equivalent logic there, it's not correct for viewport propagation (not entirely sure how we missed that, since it's been in the spec for quite some time). The situation wasn't entirely skipped as you think, because our code is just significantly different and it was written from spec more than by porting what Mozilla did.
Thanks for pointing me in the right direction so I can complete the implementation as-specced.

Pale Moon forum

MSN News site locks up

MSN News site locks up

Re: MSN News site locks up

Re: MSN News site locks up

Re: MSN News site locks up

Re: MSN News site locks up

Re: MSN News site locks up

Re: MSN News site locks up

Re: MSN News site locks up

Re: MSN News site locks up

Re: MSN News site locks up

Re: MSN News site locks up

Re: MSN News site locks up