acikyazilimagi
bug: zIndex's are bloated and conflicts MUI
Hata Tanımı
zIndex values are not really making any sense, and they are broking MUI's popper components. Popper component is needed for MUI's components with Pop-up UX purpose. They needed to get lower then 100z.
## Hata Ortamı I noticed this problem while developing feature with MUI's Autocomplete component. PR: #495 When you add MUI's Autocomplete component the component stays under Header.
Hatayı nasıl aldığınızı adım adım açıklayın
- Checkout the PR: #495
- Don't forget to add GCloud api-key as env variable. It's needed for feature.
- Type something to search box and you'll see it stays under header.
- Don't try to manipulate zIndex because you shouldn't bypass MUI's default values like this if you don't really need.
Beklenen Davranış
It should be on top and when I look source code. These are the all zIndex values in whole project: [9999, 99999, 1000, 998, 999, 1000, 999, 999, 1000, 2, -1, -1, 1, 1, 9999, 999] I think we needed to get away from this bloated stuff. And manage zIndex properly.
Ekran Görüntüleri
Masaüstü Bilgileri
- İşletim Sistemi: [Windows 11]
- Tarayıcı [Chrome]
- Sürüm [stable@latest]
Akıllı Telefon Bilgileri
- Cihaz: [S21]
- İşletim Sistemi: [A13]
- Tarayıcı [Chrome]
- Sürüm [stable@latest]
Ek Bağlam
It's easy to fix problem. If you assign me the issue I can coordinate the zIndexes and order them properly.
Also #502 numbered issue has same problem. That's a quite global problem about MUI and zIndex'es.
Be my guest and fix it.
So I fixed it in my fork, waiting for approved status to create PR. 57903d7 @eraygundogmus @usirin @canerakin111
canerakin111 added improvement and removed bug labels 6 hours ago
Also this is a bug+refactoring. Not improvement, there is other issues about z-fighting and in feature can really cause many more troubles. The new feature developments always needs to override MUI components with bloated z-index values if we don't fix leaflet css like this.