The filtering does not work in that example as the "backend"-response is nothing else but a static JSON Value and wont be filtered at all. (This example just wants to show the preserveHTML setting difference)

However, at the moment i cannot tell why Firefox 121.x+ freezes. I suspect a browser bug. Need to investigate

Thanks @lubber-de for the clarification. Indeed, the freezing Firefox is the main problem. I just panicked a bit and thought the lack of filtering is a related issue, but you're right, that's not the case with the static JSON example.

I did another investigation and it seems the number of records returned by the API matters.
Here are the examples:

1. Static content 333 records: no freezing - https://jsfiddle.net/t028c5L7/1/
2. API content 329 records: freezing for a long time - https://jsfiddle.net/5kvwe47o/
3. API content 158 records: short freezing - https://jsfiddle.net/b5yc48g7/1/
4. API content 67 records: unnoticeable, small delay in typing - https://jsfiddle.net/02jorq79/1/

I'm using Fomantic-UI css in conjunction with semantic-ui-react and experience the issue with static content (300 records) too.

An example using the latest fomantic-ui/2.9.3/semantic.min.css can be found here: https://jsfiddle.net/7mk4s6u0/5/ - using Firefox, when starting to type "Computer" in the input field, the tab freezes.

I tested downgrading to previous versions and found that it started working fine using fomantic-ui/2.9.1/semantic.min.css : https://jsfiddle.net/zowf18k6/

Hence, I assume the issue was introduced in 2.9.2. Downgrading to 2.9.1 fixed the issue for me. Hope this helps.

@slachinger indeed, it helps !

Looks like it's a CSS issue with Firefox 121.x+, but i cannot figure what's happening here.

In dist/fomantic.css L43527, just comment this lines:

@supports selector(:has(.f)) {
  *:has(> .ui.piled.segment) {
    z-index: 0;
    position: relative;
  }
}

And freezes are gone !

@lubber-de I suspect this to be the culprit, but why it's driving Firefox nuts is out of my knowledge !

Thanks for finding the reason @prudho !
Well, Firefox just supported :has since 121 which is obviously implemented ineffectively in firefox which causes the freeze so mozilla has to fix this in general.

What one can do right now:

• set @variationSegmentPiled: false and rebuild FUI which will remove the piled segment variant

What we can change in the core is either

• adjust the @supports selector for the moment so it won't affect firefox (especially since 121 where :has support is enabled by default)

- @supports selector(:has(.f)) {
+ @supports selector(:has(.f)) and (not(-moz-appearance: none)) {

This could be removed again once it is fixed in firefox

• make the *:has selector more specific, so it won't affect dropdown (infact a piled segment will most probably never be inside a dropdown), but this drastically limits the usage, as one has to declare a possible piled segment to a prepared parent element (and i dont imagine what we should define here, that was the reason back then to use the star selector)
  However, i haven't yet tested if this will fix it at all in firefox as it seems the firefox css engine will check the selector on each DOM change, so this probably doesnt help at all.
• Partly revert fix(segment): piled segments under parent background, inverted variants #2730 and remove the whole selector (which i dont think we should do as other browsers support this just fine without a performance lag)

What do you guys prefer? ( i vote for the first option to advance the @supports selector

I choose first option too. It's quick and just disable a buggy behavior without breaking anything else.

mmh, i cannot get this to reprocuce locally or via a jsfiddle and not even by trying the docs locally. Firefox works just fine.
ONLY the online docs freeze.
Even worse, i tried to manipulate the css inside the online docs as discussed above and it still freezes.
I also tried to make the :has selector more specific (even by using a non existing selector) ...and it still freezes.

@prudho Have you got a reproducable jsfiddle or how did you confirm removing the @supports selector worked for the online docs?

https://jsfiddle.net/lubber/etpjsrxo/6/

Here a comparison between local docs yarn docpad run -> no freeze
and fomantic-ui.com -> freeze, although the docs are the same code

Here is my try to change the supports-selector as discussed above (i added a red background to find out if the additional rule will not affect firefox)...it still freezes although the selector is not even executed.

So, even if we add my suggested change "dry" to the core, i suspect the issue still exists.

And, even weird....last try: I removed the whole selector...firefox still freezes

@prudho Please help if/where/how you confirmed it is fixed when removing the selector

@slachinger @prudho
🤔 I took the working example using 2.9.1 and added the @supports selector.

https://jsfiddle.net/e70xjovw/1/

I would have expected firefox to freeze now.... but it doesnt (which would explain, why my previous teste also did not make any difference

So the reason for the freeze must be somewhere else

I got it. 💪🏼 It's a combination of 3 specific @supports selector(:has) selectors , so :has is still broken in certain scenarios in firefox. All the other supports selector(:has) selectors which are also new in 2.9.3 did not affect the issue.

Using 2.9.2 and adding the 3 selectors in question will freeze firefox reproducable.
https://jsfiddle.net/e70xjovw/8/

adjusting the selector to ignore firefox will fix it in firefox
https://jsfiddle.net/e70xjovw/9/

However: keep in mind that the selectors in question do not even belong to the example code! There is no piled segment and no pointing dropdown so the selector will not even trigger. (and i also tested to make the *:has more specific: It does not matter. Something in firefox makes the parsing of those three internally freeze....

I can confirm the change (of all 3 selectors) also fixes the docs page

Will prepare a PR :)

Fixed by #2973

I filed an issue for mozilla at webcompat/web-bugs#132131

mozilla confirmed the issue and takes care about that by https://bugzilla.mozilla.org/show_bug.cgi?id=1874066

I can confirm, the issue is fixed in latest firefox 123.a01
https://archive.mozilla.org/pub/firefox/nightly/2024/01/2024-01-20-09-39-31-mozilla-central/

Firefox 123 was released today and fixed the issue. Please update your browser