Külső tényezőt okol a Firefox a tegnapi problémákért

Címkék

A Firefox tegnap további infókat ígért, de csak két-három rövid tweet-re futotta. Pontos okokat nem mondott a leállással kapcsolatban, mindössze egy meg nem nevezett harmadik félre (cloud provider) mutogatott ...

Hozzászólások

Ezt írták: „Firefox became unresponsive due to a change in defaults by a cloud provider which triggered a Firefox HTTP/3 bug” (kiemelés tőlem). Szóval nem a harmadik félre mutogatnak, csak ez váltotta a HTTP/3 implementációban lévő bugot. Az meg itt van a Bugzillában: https://bugzilla.mozilla.org/show_bug.cgi?id=1749957

Vártam már ezt a terelést. Ha nem harmadik félre mutogatnának, akkor nem említették volna, hogy mi triggerelte a bugot. Ugyanis irreleváns. Főleg úgy, hogy meg sem nevezik. A cloud provider szó helyett a Bugzilla linket kellett volna a bejelentésbe beletenni* ...

(* nem nekünk, mert mi már tegnap is ismertük a Bugzilla linket, idéztem is tegnap belőle)

trey @ gépház

Nem is azt kéne kitenni, hanem egy átlagemberek számára fogyasztható post mortem jelentésre utaló linket. Ha azt nem sikerült kiizzadni, akkor legrosszabb esetben adjon egy Bugzilla linket. De első helyen említve valami homályos entitást, az nekem trógerkodás.

De várjál kielemezem neked a Firefox csapat PR kommunikációját:

  • tegnap: hamarosan több infót adunk
  • 16 órával később a bővebb információ, ha kivesszük belőle a szerinted irreleváns részt: volt egy bug ami triggerelődött (link nélkül)

Köszi a "TÖBB INFÓT"!

:D :D :D

trey @ gépház

Firefox 95. Ez a szám már a windows-nál sem hozott szerencsét!

Sajnos egyre szarabb ez a böngésző. Az aktuális verzió nekem pár naponta egyszerűen kilép, amúgy meg vállalhatatlanul lassú. :(

Nagy kár.

Nyugi, a chromium alapuak se jobbak, buzi lassuak, tabok random crashelnek. Meg az pl. azt csinalja nalam laptopon, hogy ha egy oldalon van valami css animacio, akkor 100%-on tekeri a CPUt, gondolom hogy tudja 10000FPS-el renderelni, csak minek.

I hate myself, because I'm not open-source.

Úgy vagyok vele, mint a Debiannal. Mindig kipróbálok valami mást, de aztán akkor is visszatérek hozzá. Ez igaz a tűzrókára is. Szar-szar, de a többi még szarabb.

Mondjuk mióta ez az újhullámos, szivárványos, csillámfaszlámás a divat mindenhol, azóta megy minden zuhanórepülésben.

Debian helyett, ha nem szerverről van szó, érdemesebb szerintem Arch-ot használni, ha azt nem tudod feltelepíteni, akkor Arco. Friss, rolling, bajod nem lesz vele, extra bloatot épp úgy nem telepít.

A tűzrókában egyetértek viszont. Én is így vagyok vele, hogy szar, egyre szarabb, de még mindig jobb, mint az alsó hangon 2-4× annyi memóriát bekajáló, még jobban lebutított Google-monopol Chrome és származékai. Legalább így egy „kisebb” fejlesztőt támogatok, ellene dolgozva a Google egyeduralmának, plusz a FF részletesebben testre is szabható. Ennek ellenére, mint egy másik vonatkozó topikban írtam, a Mozillának ezek a teljesen felesleges baromságai egyre jobban zavarnak. Egyelőre a Librewolfot fogom próbálgatni, ha az nem jön be, akkor Brave vagy Chromium lesz belőle sajnos előbb-utóbb.

Engem nem is az zavar, hogy bug van, hanem ilyen felesleges hülyeségen, hogy HTTP3, meg cloud provideres és telemetriás tanúsítványos (studies) baromságokkal, meg Pockettel és egyéb hülyeséggel bénáznak, amikre eleve a lőtéri kutyának nem volt szüksége. Mert az mondom, ha jobb többszálúsításra, hatékonyabb JS motorra, hardveres gyorsításra, vagy teljes újraírásra gyúrnának, akkor oké, oda becsúszhat hiba, elnézzük, mert próbálnak fejlődni. De ilyen cloud bránerségért, meg állandó GUI lebutításért felesleges bugokat szaporítaniuk, ez tényleg csak ilyen oktalan szarkeverésre jó. Anno már az is elég nagy baj volt, hogy dobták a XUL támogatást, ráadásul ennek a szutyok WebExtensions-nek a javára, korábbi normális és hasznos pluginoknak a fele nem működik teljes értékkel a mai napig, azt még az ember lenyelte, de előbb-utóbb a leglojálilsabb felhasználóiknak is el fog fogyni a türelme. Az pl. egyáltalán nem zavart, hogy a Java, Silverlight, Flash plugin támogatását anno megszüntették, azok tényleg férges szutykok voltak, azoknak halnia kellett kifelé, nagyon helyes.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

A Fission-t kapcsold be.

Brave: https://decrypt.co/31522/crypto-brave-browser-redirect

Ha már Arch, akkor miért nem Gentoo, és fordítsd le a saját gépedre.

KAMI | 神
Linux Mint: https://linuxmint.hu LibreOffice: http://libreoffice.hu SeaMonkey : http://is.gd/smhun
Legyél Te is Mozilla és Linux Mint önkéntes

Brave-et egyelőre csak az androidos telómon használok, ott is csak azért, mert abban a legjobb az adblockoklás. Ezt a brave coin részét nem használom, ki van kapcsolva.

Próbálkoztam Gentoo-val is, és tetszene, de nem tudom jobban minimalizálni a rendszert az Archhoz képest, pedig lehetne, de még nincs meg hozzá a tudásom, és időhiányban nem tudok annyit próbálkozni. Az Arch még egy viszonylag középút, mert haladó disztró, de nem viszi el több órás forgatásokkal minden időd. Bár szerintem egy szinttől a disztró mindegy, mert aki veterán, mindegyiket be tudja állítani magának, inkább a disztrók csak csomagkezelőben, meg kiadási-frissítési mechanizmusban különböznek (kiadás/fix pont alapú, vagy rolling), meg hogy a tárolókban mennyi csomag elérhető. Plusz minimalizmusban, hogy alap telepítésben mennyi szemetet bloatot tesznek fel.

A Debiannal sincs nagy baj, Ubuntuval szemben simán még preferálnám is, de desktopra nem mindig a legjobb ötlet, a régi csomagverziók miatt, főleg ha az ember játszik, vagy valami friss hardvere van.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

(Aki az előző topicban lemaradt volna róla.)

Ha valakinek végképp tele a puttonya a mozzarella szemétségeivel, de egyik BigTech kompánia szemetére se szeretne átállni, akkor annak álljon itt pár alternatíva:

- PaleMoon: XUL alapú, 28-29-es Firefoxra épülő konzervatív fork. Baromi gyors, de vannak olyan - többnyire JS-heavy - oldalak, amik nem, vagy bugosan mennek vele.
- IceWeasel-UXP: szintén XUL alapú, az utolsó sane - 52.9-es - Firefoxra épülő progresszív(ebb) fork. Valamivel lassabb, de "maiweb-kompatibilisebb", mint az előző.
- Ungoogled Chromium: A Chromium browser forkja, amiből minden a google-hez köthető cuccot és minden trackert, spyware-et, vagy privacy-szempontból aggályos szemetet kihajigáltak.
- Iridium Browser: Chromium alapú browser, amiből dettó kiebrudaltak minden privacy-ellenes és google-ös szemetet, sőt még egyéb security tweak-eket is kapott (pl. WebRTC IP-leak ellen), de állítólag a krómos extension-ök közül nem mindegyikkel kompatibilis.
- Falkon: Leánykori nevén QupZilla; a KDE project browsere.
- Otter Browser: A régi Presto-s Opera Qt5 alapokra építkező klónja; WebKit-es és Blink-es backenddel is tud működni.

Az egykori Midorit sajnos már nem tudom ajánlani, mert átírták electronosra. :(

A PaleMoon és az IceWeasel-UXP az garantáltan, utóbbit használtam is OrangePi-n. A GTK2-vel fordított régebbi Ungoogled Chromium és Iridium is talán. A Qt5-ös Falkont és Ottert nem tudom; mindkettő lightweight, mármint maguk a browserek, de a GUI-juk Qt5-ös.

/o\
Bocs, de ebből, meg a másik topicban a másik posztodból az derül ki, hogy sem azt nem tudod, hogy az Electron mi és hogy működik, sem azt, hogy a XUL. Az Electron esetében az egész alkalmazás teljes felülete webes és bele van gyúrva egy browserbe. A XUL-nál csak az extension-öké webes, amit csak akkor látsz, ha ki is nyitod. A régi XUL-os Firefoxok felülete GTK2-ben volt megírva a mindenféle X11-capable UNIX-okon és az OS natívjával OSX, ill. windows alatt. Szó nem volt az alkalmazás teljes felületének webes implementálásáról és rendereléséről...

Pontosan tudom, hogyan működik az Electron, még hibát is javítottam ilyen alkalmazásban. XUL-lal soha nem foglalkoztam, így ezt akár el is fogadnám, ha a Mozilla saját oldalán nem lenne egyértelműen leírva:

This technology enables developers to define cross-platform graphical user interfaces using a mixture of XML, HTML, CSS and ECMAScript (JavaScript). A user can modify any aspect of the user interface of an XUL-based Mozilla application (such as the Mozilla product itself) simply by modifying files that use standard web-page syntax.

XUL uses Gecko to implement the defined user interface. [...] It supports all the basic elements found in contemporary graphical user interfaces, including menus, input controls, dialogs and tree controls (as seen, for example, in the preferences dialog), and keyboard shortcuts.

Vagyis a Gecko képes olyan natív controlokat renderelni, amire a HTML nem feltétlenül képes, és ezt lehetett kihasználni a XUL segítségével. De ez semmit nem mond arról, hogy a GUI programozása milyen módon történt.

De ha konkrét bizonyítékot szeretnél, nézd meg a Pale Moon forrását, az összes komponens (pl. preferences) xul és js fileokkal van megvalósítva.

Hát ehhez képest összekeverted az alkalmazás GUI-ját az addonokéval/kiterjesztésekével. A Firefox GUI-ja natív, nem in-browser rendered, mint az elektronos. UNIX-ok alatt pl. GTK-s, régen GTK2-es volt, utána a XUL eldobása után GTK3-ra átállították.
Erről beszélek, hogy nem tudod, hogy működik a XUL, meg az egész Firefox belseje. Az, hogy van benne webes interface pár komponenshez, annak ehhez semmi köze, ilyen a Chromiumban és a classic Operában is van.

Az a baj, hogy el vagy tévedve, mármint fizikailag, mert nem ezt a repo-t kéne megnézni, mert ezek csak a PaleMoon-specifikus kiegészítések. A böngésző magvának GUI komponenseit itt és itt találod. Ezek azok, amik a felületért, annak a programozásáért, renderéért felelnek. És látod, van GTK-s, windowsos (a Mac-es nem tudom, hova lett) és C-ben/C++-ban van írva, nem JS-ben. A XUL-lal kiterjesztéseket írhattál a browserhez, nem az azt meghajtó Gecko renderelte a teljes felületet, csak hozzácsatolhattál vele dolgokat, de ettől még a címsáv, a navigációs és egyéb gombok, a menük, az űrlapok és minden egyéb GTK-s, vagy natív mac-es/windowsos volt. Az, hogy te csináltál egy addont, aminek a preferences-e egy weblap volt, meg hozzádobott a browserhez valahova egy extra ikont/gombot, attól ez még távolról sem ugyanaz, mint az Electron. Ez ugyanígy működik a KHTML (WebKit/Blink) és a Presto alatt is.

Az Electronban viszont a teljes felületprogramozás webes szeméttel történik és mindent is a browser renderel és nem a windows GUI, vagy a GTK.

Itt van pl. a browser.xul, ez nem csak egy Pale Moon-specifikus kiegészítés vagy kiterjesztés, ez a böngésző főablaka. Ebben az urlbar textbox element implementációját itt találtam meg az UXP repóban. A content elementjében látszik, hogy egy HTML input valósítja meg. Ennek van egy DOM implementációja (h, cpp), aminek (és a textarea elementnek) a megjelenítéséért az nsTextControlFrame (h, cpp) felel. Tehát a böngésző címsora valójában egy jól álcázott HTML input, amit végül a böngészőmotor renderel, pontosan ugyanúgy, ahogy bármilyen más HTML elemet. A natív GUI toolkit gyakorlatilag csak arra kell, hogy létrejöjjön egy üres ablak, amibe lehet rajzolni, illetve pár komplex widgetet (pl. file browser) megvalósítson.

Az, hogy a PaleMoon-ban mit hogy szerkeltek át, az nem jelent semmit. Ha a címsávot speciel lecserélték, a GUI attól még GTK-s (vagy ami van windows/macOS alatt). Mi van a menüsorral? Olyan HTML widget nincs is. Hát alatta a fülekkel? Tudtommal olyan HTML widget sincs. A különféle ablakokkal? Az összes natív widgetet a GTK (vagy a windows GUI) rendereli. Ha nem így van, akkor miért néz ki az összes úgy, mint bármelyik másik GTK-s alkalmazásom? Miért veszi fel a GTK-s témám színeit? Itt egy screenshot a PaleMoon toolbar customizer formjáról és mellette a YTFE, összehasonlítási alapnak. A színek, a formák, még a fontok is megegyeznek. És ugyanígy néz ki az összes ablak a PaleMoonban és az IceWeaselekben is.

A XUL arra van a Firefoxokban, hogy hozzáadni tudj a felülethez. Akár egy másik címsávot is. De a browser GUI-ja az GTK-s/natív.

Rendben, akkor nézzük a menüt. A browser.xul-ban csak a helyét definiálják, a struktúra egy include fileban van. Az ebben használt elemeket itt definiálják, nézzük sorban:

  • menubar: csak egy XUL labelből (egy szöveg) és a children elemekből áll
  • menu: néhány XUL labelből, egy képből és a children elemekből áll
  • menupopup (h, cpp): az implementációt átfutva nekem úgy tűnik, semmi nincs natív GUI toolkitre hagyva, ez egy teljes saját menü implementáció
  • menuitem: néhány XUL labelből áll
  • menuseparator: nincs tartalma

Továbbá ezek az elemek CSS-sel vannak formázva platformfüggően (linux, windows). Sőt, Windows esetén media querykkel (1, 2) és makrókkal szabályozva a megjelenést. Arról már nem is beszélve, hogy ezek az elemek mindig is témázhatóak voltak, a látszólag natív megjelenést csupán az alapértelmezett téma biztosítja, ami változók segítségével veszi át a rendszer témáját. Ha a teljes menü natív lenne, ezek a lehetőségek sokkal korlátozottabbak lennének.

Az, hogy a menü belsejét miben definiálják, az hótt mindegy. Te azt állítod, hogy mindent a browsermotor renderel, namármost ő a browser ablakába tud renderelni, azon kívül nem, ehhez képest a PaleMoon widgetjei kilóghatnak a browser window-ból. Az egy GTK-s menü. Nem láttad az előbb az ablakot, amit mutattam? A PaleMoon ablakától független window volt; azt hogy rendereli a browsermotor? Nyit olyankor még egy full instance-t, mintha nyitnék egy második PaleMoon-t? Ezt ugye te se gondolod komolyan. Aztán, áruld el nekem, ha a XUL az Electronnal ekvivalens megoldás lenne, akkor miért eszik egy üres PaleMoon -0.0% CPU-t és miért eszik az Electronos szemét 4096%-ot?

CSS-t a GTK-ban is használhatsz és semmi köze a webhez.

A popup dolgokhoz (mint amilyen a menü) használnak valamilyen natív támogatást, de ez csak egy konténer, amibe azt rajzolnak amit akarnak. Nem a natív menü implementációt használják, mert akkor az egész XUL implementációnak nem lenne semmi értelme. De ennél több effortot ebbe nem fogok rakni, hoztam neked a linkeket az implementációra, akkor most te hozz nekem, ahol pl. létrehozzák a natív menüt és feltöltik a menüelemekkel.

Aztán, áruld el nekem, ha a XUL az Electronnal ekvivalens megoldás lenne, akkor miért eszik egy üres PaleMoon -0.0% CPU-t és miért eszik az Electronos szemét 4096%-ot?

Hogy ez nálad miért van így azt nem tudom, én annyit tudok mondani, hogy jelenleg 4 Electron alkalmazás fut a gépemen, és összesen ha elhasználnak 1% CPU-t. Ebből 3 memóriafogyasztása 150 MB körül van, a 4. kb. 75MB.

De ennél több effortot ebbe nem fogok rakni, hoztam neked a linkeket az implementációra, akkor most te hozz nekem, ahol pl. létrehozzák a natív menüt és feltöltik a menüelemekkel.

Nem, te nem az implementációra hoztál linkeket, hanem a definíciókra; elég vaskos különbség. Te kikerestél pár XUL-ban leírt elemdefiníciót és azt mutattad meg, az egyetlen kivétel a nsMenuPopupFrame.cpp volt, ahol a XUL-os menürajzolás volt implementálva, csak annak mi köze a browser GUI-hoz?
A GUI kezelésének implementációi itt lesznek, pl. a menüsávé:

git clone https://repo.palemoon.org/mcp-graveyard/UXP
cd UXP
grep -r 'gtk_menu_bar_new()'
widget/gtk/nsLookAndFeel.cpp:    GtkWidget *menuBar = gtk_menu_bar_new();
widget/gtk/gtk2drawing.c:        gMenuBarWidget = gtk_menu_bar_new();
widget/gtk/WidgetStyleCache.cpp:  GtkWidget* widget = gtk_menu_bar_new();
grep -r 'gtk_menu_shell_append('
widget/gtk/nsLookAndFeel.cpp:        gtk_menu_shell_append((GtkMenuShell *)GTK_MENU(menu), menuitem);
widget/gtk/nsLookAndFeel.cpp:    gtk_menu_shell_append(GTK_MENU_SHELL(menu), menuitem);
widget/gtk/nsLookAndFeel.cpp:    gtk_menu_shell_append(GTK_MENU_SHELL(menuBar), menuBarItem);
widget/gtk/gtk2drawing.c:        gtk_menu_shell_append(GTK_MENU_SHELL(gMenuBarWidget),
widget/gtk/gtk2drawing.c:        gtk_menu_shell_append(GTK_MENU_SHELL(gMenuPopupWidget),
widget/gtk/gtk2drawing.c:        gtk_menu_shell_append(GTK_MENU_SHELL(gMenuPopupWidget),
widget/gtk/gtk2drawing.c:        gtk_menu_shell_append(GTK_MENU_SHELL(gMenuPopupWidget),
widget/gtk/gtk2drawing.c:        gtk_menu_shell_append(GTK_MENU_SHELL(gMenuPopupWidget),
widget/gtk/WidgetStyleCache.cpp:  gtk_menu_shell_append(GTK_MENU_SHELL(GetWidget(MOZ_GTK_MENUPOPUP)),

És akkor itt van ez: https://repo.palemoon.org/mcp-graveyard/UXP/src/branch/master/widget/gtk/mozcontainer.c
Az összes moz_container wrappelődik GTK2-re. Van egy konténer, amiben benne van a GTK-s widget. Gondolom megvan valahol ennek a windowsos megfelelője is, ahol a konténerben a windowsos widget van.
És itt van az ablak konkrét felépítésének és renderjének implementációja. GTK2 és GTK3. És nem csak egy sima GTK-s ablakot hoz létre - tökig van verve GtkWidget kóddal.

És mégvalami: a XUL-t teljesen le is lehet tiltani a --disable-xul flag-gel. Szerinted, ha a XUL-lal van rajzolva minden, akkor mi történik, ha letiltják? Nincs GUI?

Hogy ez nálad miért van így azt nem tudom, én annyit tudok mondani, hogy jelenleg 4 Electron alkalmazás fut a gépemen, és összesen ha elhasználnak 1% CPU-t. Ebből 3 memóriafogyasztása 150 MB körül van, a 4. kb. 75MB.

Ez kb. az a kategória, hogy nálad 200-400 kB egy electronos app. Azt lecsekkoltad már?

Nem tudom, hogy windowson mit csinál. Az about:logo nem egy érvényes path, azt már a parsernek fel kell oldania. Ennyi erővel kérdezhetted volna azt is, hogy pl. az a tag-ek formázásával mit kezd a GTK, hiszen az is lehet benne és az sem értelmezhető a GTK-ban. Nyilván csak azt adja oda abból a CSS-ből a GTK-nak, ami rá vonatkozik, a többi a rendermotoré.

Again: ha mindent is a XUL intéz a GUI-n, akkor hogy a viharba fog működni a browser, ha már a forgatásnál letiltjuk a XUL-t? Az újabb Firefoxokban már egyáltalán nincs is XUL, hanem WebExtensions van hozzá, ami a tizedét sem tudja annak, amit a XUL tudott. Az újabb Firefoxokban talán a WebExtensions-ön keresztül renderel mindent a browser? Azt hogy?

Tehát azt mondod, hogy amikor az alkalmazás feldolgozza a XUL-t, a különféle low-level elemeket (pl. xul:label, xul:image, stb.) megfelelteti valahogy a natív menü elemeinek, továbbá feldolgozza a CSS-t és a natív menü elemein alkalmazza a GUI toolkit által alkalmazható stílusokat (ami ugye nem feltétlenül CSS)?

Sejted, hogy ez mennyire komplex probléma? Nem lenne sokkal egyszerűbb, ha az alkalmazás implementál egy lebegő konténert, amibe ugyanúgy tud renderelni mint a főablakba, és egy ügyes UX designer összerakja XUL és CSS-ből, hogy úgy nézzen ki, ahogy a natív téma?

Again: ha mindent is a XUL intéz a GUI-n, akkor hogy a viharba fog működni a browser, ha már a forgatásnál letiltjuk a XUL-t?

Akkor használja az általad linkelt natív implementációt, amit persze így nem lehet személyre szabni.

Az újabb Firefoxokban már egyáltalán nincs is XUL, hanem WebExtensions van hozzá, ami a tizedét sem tudja annak, amit a XUL tudott. Az újabb Firefoxokban talán a WebExtensions-ön keresztül renderel mindent a browser? Azt hogy?

Ezt nem is értem miből gondolod, a két dolog nem ugyanarra jó. A UI még most is használ XUL-t, csak az extensionök számára tiltották meg a használatát. Utóbbiaknak van a WebExtensions API, hogy a XUL nélkül is be tudjanak épülni a böngészőbe, de sokkal kontrolláltabb (korlátozottabb) keretek között.

Tehát azt mondod, hogy amikor az alkalmazás feldolgozza a XUL-t, a különféle low-level elemeket (pl. xul:label, xul:image, stb.) megfelelteti valahogy a natív menü elemeinek, továbbá feldolgozza a CSS-t és a natív menü elemein alkalmazza a GUI toolkit által alkalmazható stílusokat (ami ugye nem feltétlenül CSS)?

Sejted, hogy ez mennyire komplex probléma? Nem lenne sokkal egyszerűbb, ha az alkalmazás implementál egy lebegő konténert, amibe ugyanúgy tud renderelni mint a főablakba, és egy ügyes UX designer összerakja XUL és CSS-ből, hogy úgy nézzen ki, ahogy a natív téma?

Hogy micsoda? Írtál te már GUI widgetsetet? Tudod te az mennyire komplex probléma? Én tudom, mert én írtam. Biztosíthatlak róla, hogy sokkal komplexebb, mint egy CSS parsing és forwarding. Ott kezdődik, hogy implementálnod kell az atomi rajzműveleteket, X11 rulez. (NOT!) (És ugye itt ráadásul ugyanezt meg kéne csinálnod macOS és windows alá is.) Aztán jöhetnek az objektumok. Az eseménykezelés. A Z-buffer, ami egy külön gyönyör. A callbackek, a state change-ek. A render. Hogy mit rendereljen. Hogy mikor rendereljen. Hogy hová rendereljen. Buffering, pre-rendering. Átlátszóság, pre-multiplikáció. (Ez utóbbi maga nem vészes, de ha életedben nem hallottál róla, akkor csak pislogsz, mint egy intel-vezérelt szemafor, hogy miért nem jók az alfacsatornáid.) Ja és a fontkezelés. Bitmap font, vektorfont, antialiasing, hinting, stb. Persze erre használhatsz valami fontrender library-t, de akkor meg szophatsz azzal. Képkezelés dettó, már ha ikonokat akarsz.

Akkor használja az általad linkelt natív implementációt, amit persze így nem lehet személyre szabni.

Ha be van kapcsolva a XUL, akkor is ezt csinálja. Csak azt rendereli a Gecko, amit overrideoltál, vagy hozzácsatoltál XUL-ból. Amit nem, azt nem.

Ezt nem is értem miből gondolod, a két dolog nem ugyanarra jó.

Hogy micsoda? Én nem gondolom ezt, könyörgöm, pont ezért kérdeztem rá szarkasztikusan.

A UI még most is használ XUL-t, csak az extensionök számára tiltották meg a használatát.

Nocsak, ezt nem tudtam. Úgy tudtam, megszabadultak tőle.

Utóbbiaknak van a WebExtensions API, hogy a XUL nélkül is be tudjanak épülni a böngészőbe, de sokkal kontrolláltabb (korlátozottabb) keretek között.

Korlátozottabban igen, de kontrolláltabban? És cserébe sokkal erőforrásigényesebben és sokkal kevésbé biztonságosan. De ez off most.

De már ott a Gecko a böngészőben ami mindezt megvalósítja, csak újra kell használni. Vagy szerinted a HTML renderelésnél ezek a problémák nem merülnek fel, csak a böngésző UI esetén?

Ha be van kapcsolva a XUL, akkor is ezt csinálja. Csak azt rendereli a Gecko, amit overrideoltál, vagy hozzácsatoltál XUL-ból. Amit nem, azt nem.

Tehát azt mondod, hogy amíg nem nyúlok hozzá addig natív lesz, de amint egy picit is hozzányúlok pl. CSS-ből egyből egy teljesen más renderelési módra vált át? Mindezt úgy, hogy amelyik tulajdonsághoz nem nyúltam az pixelre azonos kimenetet generál? Ennek mégis mi értelme lenne, a kódban kétszer kell implementálni ugyanazt, a natív megvalósítás semmilyen pluszt nem nyújt.

De már ott a Gecko a böngészőben ami mindezt megvalósítja, csak újra kell használni.

Nem, nem valósítja meg mindezt, csak egy részhalmazát, ami a HTML dokumentumok rendereléséhez kell.

Vagy szerinted a HTML renderelésnél ezek a problémák nem merülnek fel, csak a böngésző UI esetén?

Nem mind, ugyanis egy HTML rendermotornak nincs annyi GUI widgetje, mint egy GUI toolkitnek (és ezeknek nincs is annyi state-je), ezért egy raklap esemény, vagy rendering típus nem is létezik benne.

Tehát azt mondod, hogy amíg nem nyúlok hozzá addig natív lesz, de amint egy picit is hozzányúlok pl. CSS-ből egyből egy teljesen más renderelési módra vált át?

Nem ezt mondtam. Attól függ, hogy hogy nyúlsz hozzá. Ha CSS-ből beformázol egy elemet, azt a GTK is tudja. De ha oda akarsz rakni valami JS-ben vezérelhető űrlapot, azt Gecko fogja csinálni.

Ennek mégis mi értelme lenne, a kódban kétszer kell implementálni ugyanazt, a natív megvalósítás semmilyen pluszt nem nyújt.

Nem kell kétszer implementálni ugyanazt, ugyanis a GTK már implementálta helyetted. Kérted, hogy mutassam meg, megmutattam. Nem tudom, mit vársz még tőlem.

Szerintem az sokkal nagyobb probléma, hogy a böngésző ezek szerint olyan helyre akart csatlakozni, amit én nem tudtam vagy nem akartam. Ha én meg akarom nyitni a Firefoxból a HUP-ot, mi közöm van bármiféle felhőhöz? DNS-hez még van közöm, meg a HUP-hoz az adott példában. De bármelyik random felhő porig éghet felőlem, akkor sem kellene hbát tapasztalnom.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerkesztve: 2022. 01. 15., szo – 07:45

Egy éve már terveztük kivágni a vállalati infrából, de csak’ halasztódott a dolog újra és újra, valahogy nem vettük teljesen komolyan az ötletemet. Az ilyen esetek, kiemelve az ostoba terelést viszont közelebb hozza az esemény időpontját \o/

5-6 évvel ezelőtt nem hittem volna, hogy ilyeneket írok egyszer. Most mégis sikeredett ideböfögni.

Vortex Rikers NC114-85EKLS

Akkora lendülettel pattantunk MS vonatra, hogy irodában Edge lesz, ez kb. 130 munkaállomás (plusz a néhányukon futó vendég rendszerek is). Produkciós ipari környezetben pedig marad IE alternatíva amíg megy, ez további kb. 20-30 berendezés.

Nem az a lényeg melyik a “jobb”, mert ez szubjektív. Azt erőltetném, amelyikkel kevesebb kérdés merül fel és kevesebb meló akad. A FF az utóbbi időben mindenütt plusz munkát ad. Vagy nem praktikus (nálunk), vagy hegeszteni kell (nálunk). Vagy ez a mostani szopás. Vagy jövő héten megint más. Utána meg megint. 

Tényleg idő kérdése és tőlünk repül, erre nagyobb összeget tennék. Nem örömmel írom.

Vortex Rikers NC114-85EKLS