A commit touching only docs/ produced a pipeline with zero jobs, which GitLab marks as failed - pipelines 203 and 204 on 2026-08-06 were both red for nothing. Cause is the needs chain: web is skipped by its changes rule, and desktop_linux/desktop_windows depend on it, which collapses the whole pipeline including the manual jobs.
This matters beyond cosmetics: gitops/CLAUDE.md makes the red pipeline the alarm for the TURN rotation, stating there is no separate reminder. Red that means nothing trains people to stop looking.
The path list is a YAML anchor shared with the web job - two copies would drift. CI_PIPELINE_SOURCE == web stays allowed so the manual maintenance jobs remain reachable via Run pipeline.
The separator has to tell a click apart from a drag, because dragging it
also ends in a click, and it did so by treating any pointer movement at all
between press and release as a drag. A pointer rarely holds perfectly
still, least of all on a trackpad, so clicking the separator to open the
room list often did nothing and had to be tried again.
Movement is now measured from where the pointer went down and only counts
as a drag past a few pixels, which means the handlers need the pointer
position and the separator passes its events through to get it. Movement
with nothing held down is ignored too: those events fire on hover, and one
of them used to spend the click that came after it.
Tests: a click that wanders a couple of pixels still opens the panel, as
does one that follows moving across the separator, while a real drag is
still no click.
Co-authored-by: R Midhun Suresh <hi@midhun.dev>
Meine Aussage "ClamAV kostet mehr als das gesamte Branding zusammen" war so nicht haltbar: gemessen sind es ~130 zu ~104 Zeilen, der groesste Einzelpatch ist sogar Branding (HelpUserSettingsTab.tsx, 71 Zeilen).
Der Unterschied liegt woanders: Branding-Patches stehen am Rand und sind nach einem Umbau wiederfindbar, ClamAV-Patches stehen mitten in Entschluesselungs- und Fehlerpfaden. Dazu der eigentliche Haken - verschiebt Upstream die viewmodels/-Dateien, entsteht kein Konflikt, die Zeilen sind schlicht weg und Git meldet nichts. Deshalb ist dort ein Funktionstest maszgeblich, nicht die Merge-Ausgabe.
Refs axion1337.chat/ThreadNet-Web#7
Der wichtigste Befund ist die Grundlage, nicht die Liste: das Repo enthaelt KEINE Upstream-Historie. Element Web 1.12.17 kam am 2026-05-10 als kompletter Baum herein, im selben Commit wie das erste eigene Feature. Es gibt also keinen gemeinsamen Vorfahren mit element-hq/element-web - ein git merge ist nicht moeglich, ein Update heisst neu auftragen.
Gemessen statt geschaetzt: 102 geaenderte Dateien, davon nur 12 Upstream-Quellcode. Fuenf davon Branding (flach, isolierbar), sieben ClamAV in der Medien-Pipeline - und genau dort baut Upstream gerade auf MVVM um. Das Update wird an ClamAV mehr kosten als am gesamten Branding.
Refs axion1337.chat/ThreadNet-Web#7
Erste Widget-Version mit VITE_PRODUCT_NAME: Fehlermeldungen und die Versionszeile im Entwicklermodus sagen nicht mehr "Element Call".
pnpm-lock.yaml von Hand nachgezogen (Version an 6 Stellen, integrity aus dem veroeffentlichten Tarball berechnet) - auf diesem Mac gibt es kein Node. Faellt beim CI-Schritt pnpm install --frozen-lockfile auf, falls etwas nicht stimmt.
Die uebersprungene .6 liegt kaputt in der Registry, siehe axion1337.chat/threadnet-call#4.
alpenglow.jpg (John Towner, Unsplash) ersetzt lake.jpg als Hintergrund der Login-Seite. Die Unsplash License erlaubt kommerzielle Nutzung und Aenderung ohne Genehmigung und verlangt keine Namensnennung - wir nennen ihn trotzdem, das ist die faire Form.
Die Danksagung ist dabei bewusst nicht uebersetzt: der Schluessel credits|default_cover_photo liegt in 32 Sprachdateien, 31 nennen Elements Fotografen namentlich. Nur en/de anzupassen haette in 29 Sprachen eine falsche Attribution stehen lassen, und diese 29 pflegen wir nicht - sie kommen aus Elements Uebersetzungsdienst.
lake.jpg ist entfernt, weil es durch diese Aenderung unerreichbar wird - 610 KB, die sonst in jedem Image mitfahren.
Die heute im Web gesetzten branding-Werte fehlten der Desktop-Config. Ohne sie
faellt AuthHeaderLogo.tsx auf themes/element/img/logos/element-logo.svg zurueck -
die Anmeldemaske des Desktop-Clients haette also weiter Elements gruenes Logo
gezeigt, waehrend der Web-Client bereits die ThreadNet-Marke traegt.
vector-icons/512.png liegt im webapp-Bundle des Desktops (geprueft), der Pfad
loest also auch dort auf.
Chirurgisch eingefuegt, nicht neu serialisiert - die 17 Themes und der
Gedankenstrich in der Beschreibung bleiben unangetastet.
Danach gilt: Web-Konfiguration ist eine echte Teilmenge der Desktop-Konfiguration,
ohne einen einzigen Wertkonflikt (verglichen ueber alle verschachtelten
Schluessel).
Refs ThreadNet-Web#1
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Upstream setzt mac.icon auf build/icon.icon - das Icon-Composer-Bundle von
macOS 26. Dessen Verarbeitung ruft actool auf, das es nur mit dem vollen Xcode
gibt (~10 GB, App-Store-Login). Mit blossen CommandLineTools scheitert damit
JEDER macOS-Build:
⨯ Failed to check actool version. Is Xcode 26 or higher installed?
Die bisherige Diagnose in management#22 war falsch: Dort stand, nur das
DMG-Target brauche actool und das ZIP baue problemlos. Tatsaechlich trifft es
alle macOS-Targets, weil mac.icon fuer alle gilt - das ZIP scheitert genauso.
Der dort empfohlene Ausweg (DMG per hdiutil bauen) haette ein Problem geloest,
das gar nicht am DMG lag.
Loesung: mac.icon und dmg.badgeIcon auf das klassische build/icon.icns. Damit
baut electron-builder ZIP UND DMG selbst, inklusive Blockmap - verifiziert am
2026-08-06, beide Artefakte in Release v0.4.1.
Umgesetzt als Variantenoption statt als Aenderung an Upstreams Defaults: Die
Werte stehen in unserem axion1337/build.json, electron-builder.ts wird nur
additiv um zwei optionale Schluessel erweitert - dieselbe Machart wie das
bereits vorhandene linux.deb.name. Ein Upstream-Merge erzeugt an der
mac.icon-Zeile damit keinen Konflikt.
Preis: kein macOS-26-Icon-Rendering. Ohne Xcode gaebe es ohnehin keinen Build.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Nachtrag zu v0.4.0. Meine Icon-Arbeit deckte nur vector-icons/ ab; an vier
weiteren Stellen stand weiterhin Element - sichtbar, nicht im Verborgenen.
<title>Element</title> stand statisch in der index.html. Im Browser-Tab stand
also 'Element', unabhaengig vom Icon daneben. Ebenso application-name und
apple-mobile-web-app-title, die beim Ablegen als PWA greifen.
favicon.ico neu: Browser fragen diesen Pfad automatisch ab, unabhaengig von den
<link rel=icon>-Tags. Bisher kam dort ein 404 mit text/html zurueck - derselbe
Fehler, den wir am 2026-08-02 im Docusaurus-Wiki hatten. Sieben Groessen von 16
bis 256, aus derselben zentrierten Quelle wie alle anderen Icons.
Fehlerseite (ErrorView): zeigte Elements element-app-logo.png mit alt='Element'.
Ausgerechnet die Seite, die man sieht, wenn sonst nichts funktioniert.
Desktop-Hinweis (SdkConfig defaults): trug Elements Logo und verlinkte auf
element.io/get-started - also auf fremde Downloads, obwohl wir eigene Builds
ausliefern. Zeigt jetzt auf unsere Releases.
Die drei Bildverweise gehen alle auf vector-icons/512.png statt auf neue Dateien:
webpack kopiert aus res/ nur themes/** und vector-icons/**, und eine zweite
Logo-Datei koennte von den uebrigen abdriften.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Zwei Haelften desselben Issues, bewusst in einem Commit, weil sie zusammen
gebaut und ausgeliefert werden.
Desktop-Icons: build/icon.png war byte-identisch mit dem alten, unzentrierten
Web-Icon - das Motiv klebte an der Oberkante (Rand oben 3 %, unten 40 %). macOS
und Windows zeigten also dasselbe schiefe Bild wie der Browser-Tab. Alle vier
Artefakte aus der jetzt zentrierten Quelle neu erzeugt: icon.png, icon.ico
(sieben Groessen von 16 bis 256), das Layer-Asset des macOS-Icon-Composers und
icon.icns ueber iconutil (10 Einzelbilder, 16-512 plus @2x). Alle vier gehen auf
dieselbe Datei zurueck, sie koennen also nicht mehr auseinanderlaufen.
About-Attribution: 'ThreadNet - powered by Element' steht jetzt in Einstellungen
-> Hilfe & Info direkt unter der Client-Version, mit Link auf element.io. Das
war der eigentliche Zweck des Issues - bisher stand die Zeile nur in der
Build-Beschreibung des Desktop-Pakets und war im Client nirgends sichtbar.
Zwei bewusste Entscheidungen dabei, beide im Code kommentiert:
- NICHT in getVersionTextToCopy aufgenommen. Der Text dort landet in
Fehlerberichten; die Herkunft des Forks ist da nur Rauschen.
- Ohne _t(). Ein Markenhinweis wird nicht uebersetzt, und jeder zusaetzliche
i18n-Schluessel ist Reibung beim naechsten Upstream-Merge - genau das, was das
Issue mit 'chirurgisch halten' meint.
Das Stylesheet nutzt nur Variablen, die im Projekt bereits verbreitet sind
(--cpd-space-2x in 43, --cpd-color-text-secondary in 28,
--cpd-font-body-sm-regular in 22 Dateien) - kein Blindflug mit erfundenen Tokens.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Die Web-Icons trugen bereits die ThreadNet-Marke - anders als im Issue vermerkt.
Sie waren aber falsch zugeschnitten: Rand oben 3 %, unten 40 %, das Motiv klebte
an der Oberkante. In runden und quadratischen Icon-Slots sitzt es dadurch
sichtbar zu hoch.
Alle sieben Groessen aus dem 1024er neu erzeugt: auf die Motiv-Bounding-Box
beschnitten und bei gleicher Groesse (81 % der Kante) mittig gesetzt - jetzt
21 % Rand oben wie unten. resize() statt thumbnail(), sonst waere nur verkleinert
worden.
theme_color stand auf #76CFA6, Elements Mintgruen. Die Marke ist #ed4f4c
(dominante Farbe des Motivs gemessen, nicht geschaetzt) - das Gruen war ein
Upstream-Rest und faerbte die Browser-/PWA-Leiste falsch ein.
config.sample.json: brand von Element auf aXion1337.Chat, damit die Vorlage
zeigt, was Prod tatsaechlich setzt.
Nicht angefasst: der Favicon-Snapshot-Test - er prueft Canvas-Operationen
(clearRect, Dimensionen), nicht den Bildinhalt, und bleibt gruen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Pressing "Open" on the download-complete toast called shell.openPath and discarded the
result with `void`. openPath resolves to a non-empty error string on failure (an empty
string means success), so when the file had been moved or deleted the open silently did
nothing and the user saw no response at all (#32273).
Await the result and, on a non-empty error, log it and show an error dialog carrying the
underlying error as its detail.
Co-authored-by: R Midhun Suresh <hi@midhun.dev>
* Exploration of a virtuoso-powered emoji picker
moved to shared components
Fable generated
* fix pnpm lock
* format & fix some lint issues
* wrong import
* fix lint warning
* Fix off-by-one
and remove manual overflow adjustment: let's leave the default unless
it turns out to be necessary. Emoji should not take that long to load.
* Convert to functional component
* WIP: change to one big virtuoso scroller
* Change to use virtuoso's own onRangeChanged
and santitise category data and how it's passed around
* Convert Tabs to functional component
and put the focusing behaviour back with it just keeping track of
refs by itself.
* Absorb two line config file into main component
* Actually add the config to the main file
* Convert emoji to functional
Also make selected always defined and use useCallback.
* QuickReactions to functional component
* Non-default exports & doc
* Search to functional component
* Well it seems to work just fine now
* Use ref prop
* fix lockfile AGAIN
* lint
* Remove default export
* Remove some mx_ classnames and fix the inputRef
to make the arrow keys in the search box work (well, work as much as
they ever did).
* Remove last of the mx_ id / classnames
(except the one in the test)
* Use useMemo to memoize
* No need to export props interface (I think?)
and fix comment now we don't do the mutation stuff anymore
* Fix test
* Fix axe violations & add screenshots
* Avoid comparing dom snapshots in test
* Allow more before or after, just compare order of the ones present in both.
* Switch existing usages to new emoji picker
and kill the old one with fire
* Unused stuff
* Remove i18n strings
* Fix some tests
* Update screenshots
* Fix test
by removing the last of the weird memoized-but-mutated data structure
* Move the string somewhere more sensible than 'a11y'
* i18n lint
* Give the emojis IDs so aria-activedescendant works
* Fix more tests
* Add a small wrapper emoji picker component
This lets us easily memoize the recent emojis when the emoji picker is opened.
Also it saves a bit of boilerplate.
* Remove old emojipicker css
* Typos
Co-authored-by: David Langley <davidl@element.io>
* Use compound constants
* Rethemendex
* Use catalog version for emojibase
* Add comments
* More comments
* Fix comment
* More comments
* more comments (and make them uniform)
* More comments
* Fix pnpm lock again
* Another comment
* Apply button types to new version
* Add comment
* Disable screenshot
as per comment
---------
Co-authored-by: Will Hunt <2072976+Half-Shot@users.noreply.github.com>
Co-authored-by: David Langley <davidl@element.io>
This never actually fixed the issue of the call elements being blurry
due to fractional pixels. But it also causes other issues like the
max/min width of the left panel never being persisted in settings.
MAudioBody passed the event body straight to the player, so an audio message
sent with a caption showed the caption text instead of the file name. It now
uses presentableTextForFile, the same helper m.file and m.image already use.
Fixes https://github.com/element-hq/element-web/issues/31116
SpaceRoomView renders RoomTopic for the space home view, but the Edit topic button in
the topic dialog dispatched open_room_settings unconditionally, so a space opened the
room settings dialog instead of its own.
Branch on room.isSpaceRoom() and use the existing showSpaceSettings() helper.