mediapart.fr loading an image locks the tab

[mmouse]

Using Linux (Kubuntu 22.04 with Wayland), reproduced on a Win 11 Vm.
*** warning this is using half official builds of Palemoon 33.7.2 without Avx ***

Getting to

https://blogs.mediapart.fr/thomas-delcl ... a-pauvrete

the article itself displays and works fine, but scrolling to the first image (titled ' Distribution du revenu annel équivalent net par région....') and
clicking on it displays the image in foreground normally, however after closing it the tab is 'locked', the mouse cursor stays as a hourglass with a 'minus' in it
and nothing can be done on the page at all (scrolling, selecting text...). The browser itself is generally working, other tabs are acting fine, it's
possible to close the locked tab and load it again and it will be fully usable.
Console shows no error message if cleared first and doing the problematic operation, neither on Linux nor on Windows.
Tested on Firefox, no problem here.

[Goodydino]

I am not seeing quite the same thing with that page. The cursor is indeed locked up as the "minus" magnifying glass and will not select anything, but I can still scroll. Closing the tab and reopening it does not fix the cursor, unless I delete the history.

[vannilla]

Clicking on the image creates a "modal" element inserted at the end of the document in order to overlay the entire page.
When the "modal" is dismissed the element still exists but it is configured to have opacity: 0.
Visually this configuration hides the element but does not make it disappear from the page; the cursor shows the "decrease zoom" icon because the image is still there, just invisible.
If it works on Firefox then there is a non-zero chance they changed how opacity works in order to make it behave the same as display: none, i.e. the element is there but cannot be interacted with, but that does not make any sense: as any videogame player knows, an invisible wall is still a wall.

[Moonchild]

there is a non-zero chance they changed how opacity works in order to make it behave the same as display: none

That would be completely against the spec.

an invisible wall is still a wall

Exactly.

If they want to not obstruct the page but keep the "fake-modal" overlay present and not interactable, they should use pointer-events: none on their "hidden" class for the overlay if I recall correctly off of the top of my head.

[adoxa]

It seems a transitionend event is not fired, so a promise is never fulfilled, meaning the element is not removed (Dismiss The Overlay will remove it).

[mmouse]

Thanks to everyone who replied.
My Js skills are not up to the task of tracing what the page is doing, however using the simple trick of searching the Html for the string 'Agrandissement', that appears only linked to this specific feature, it appears one time in Palemoon when clicking the picture, and stays present in the page when dismissing it, and indeed it allows to find the modal dialog still existing in the page after dismissing the pop up image.
In Firefox the string is not found anymore after dismissing the modal image displays, so it seems that Adoxa explanation is correct and the intended behaviour is to destroy the modal, not just hide it.
Maybe the transparency / opacity transition is the result of wanting to provide fast feedback and is not the primary mechanism to get back to the normal article display.

[Moonchild]

It seems a transitionend event is not fired, so a promise is never fulfilled, meaning the element is not removed (Dismiss The Overlay will remove it).

I'm not sure why this wouldn't fire. We support this and actually use it internally too (for e.g. fullscreen UI).

[mmouse]

Argh.

I checked how to debug TransitionEnd events using Chrome and Firefox. Chrome displays the source all right without asking for it. Firefox unminifies but you have to ask. Under Palemoon, sources stay minified. When asking for it, an progress bar is shown for a few seconds and then the darn javascript stays as it is. How is Adoxa debugging the thing then ? Surely not by setting breakpoints in unminified goo?

I had then an awful thought: if 'linux is making everything difficult', could it be that Adoxa et alii are all using this other operating system ? I have access (if not often) to a Windows box and tried to access this cursed Web page with current Palemoon: unminifying the source works under Windows. Setting a breakpoint on the eventListener setting works.
Is this unability to unminify JS under Linux a known bug ?

[adoxa]

Aha! It's actually an unsupported CSS media at-rule that is causing the issue. Here's a Modify HTTP Response filter to remove them.

Code: Select all

[["www.mediapart.fr",["/main.*\\.css$/",["/and \\(prefers-reduced-motion: no-preference\\)/g",""]]]]

[mmouse]

Thanks @adoxa, and sorry for the delay - I wanted to have an access to a Windows computer to be able to load the page under the debugger - however it was to no avail since the problem is fixed by your modify HTTP response, but it shows again when run under the debugger with a breakpoint on the offending part :-/.

What I gather from the behaviour under Palemoon and Firefox is that whatever the modify HTTP response (loaded or not), the code is always picking the part where it starts an event listener, but that for some reason when the modify HTTP response is not loaded, the Javascript engine crashes or takes a bad branch because of the unimplemented media method (prefers-reduced-motion) and never fires the event. Well, if it happens only for this specific method and this specific page it's not a big deal by itself of course.