felhom.eu/documentation/audits/facebook-page-setup-2026-10-08

Facebook Page setup — evidence, 2026-10-08

Task: marketing/facebook/TASK-page-setup-windows.md. Run from the Windows workstation with Claude in Chrome (the operator's own Chrome, logged in as the Page admin); the Graph read-backs ran on DooPlex, where the credentials file is.

Baseline felhom.eu main = 1d692734 (clean on both working trees before the run).

What is in here

File	What it is
A-meta-sizes.md	Phase A — Meta's own size page, quoted verbatim, with the comparison against our README
A-meta-sizes-screenshot.jpg	the same page on screen
B0-page-before.jpg	the Page before any edit (old intro text visible)
B1-intro-after.jpg	the Page after the intro was replaced
B3-action-button-readback.jpg	the action button read back from the Page header „…" menu (a different entry point than the one that set it)
B4-messenger-welcome-refused-attempt.jpg	the welcome message typed in, on the attempt Meta refused
B4-messenger-welcome-after.jpg	the saved automation, on, with our text
B5-username-after.jpg	„Oldal általános beállításai" showing the saved username
C1-page-computer-1435px.jpg	the Page at a 1435 px viewport (the Phase C computer check)
C1-page-computer-2067px.jpg	the same at 2067 px — the cover container is capped at 1250 px, so both show the identical cover
C2-page-phone-pixel9-412px.jpg	the Page on an emulated Pixel 9 (412 × 924, mobile user agent) — the Phase C phone check
C2-phone-cover-cut.png	the phone header at native size: the cover's left edge is cut
C2-phone-headline-cut-closeup.png	the close-up: „aját szabályaid" and „elhom.eu" — one letter gone from each
C3-narrow-window-horizontal-scroll.jpg	the proof that narrowing the window does NOT give the phone layout (see below)
D-ci-run-846-green.jpg	the CI run for the first commit of this work
probe-before/	fb_probe.py read before the edits — C1-page.json holds the OLD about
probe/	fb_probe.py read after the edits — C1-page.json holds the NEW about; run.log is the run transcript

The read-backs, each from a different channel than the edit

Edit	Made in	Read back from	Result
B1 intro	the Page's „Névjegy" editor	Graph API GET /{page}?fields=about (DooPlex, Page token)	about = 99 chars / 111 bytes, hex equal to COPY.md §1; the before run holds a different 134-char value
B3 action button	the „Az oldalad beállításának befejezése" card	the Page header „…" → „Műveletgomb módosítása"	„További információ", https://felhom.eu/
B4 Messenger welcome	Business Suite → Bejövő üzenetek → Automatizálások	the automation reopened from its own URL after a reload	120 chars / 134 bytes, hex equal to COPY.md §3; toggle „Bekapcsolva"
B5 username	Facebook settings → Oldal általános beállításai	Graph API GET /{page}?fields=username and loading facebook.com/felhom.eu	username = felhom.eu; the address loads the Page

Hex comparisons were made against the fenced blocks of marketing/facebook/COPY.md, read from the file — never retyped. The in-page text was read with TextEncoder in the browser and compared byte for byte.

Phase C — what was measured and what was not

Computer width: measured, nothing is cut. At a 1435 px viewport the cover renders 1059 × 403 from the natural 960 × 365 Facebook re-encode of our 1640 × 624 PNG; object-fit: fill, and the image's rectangle equals its container's rectangle exactly, so no crop and no visible distortion (2.6301 vs 2.6316 — 0.06 %). The cover container is capped at 1250 px, so a 2067 px viewport shows the same picture; the requested 1440 px and the 1435 px measured are the same case. The headline „Saját felhőd, saját szabályaid" and „felhom.eu" are whole. The profile circle renders 168 × 168 and its top edge sits 16–17 px below the cover's bottom edge — it does not overlap the cover at all at this width, so it covers no cover text. Zoomed on the circle, the logo is whole: nothing is cut by the circular crop.

Phone width: MEASURED on a Pixel 9, and it FAILS — the cover is cut. See C2-page-phone-pixel9-412px.jpg, C2-phone-cover-cut.png and C2-phone-headline-cut-closeup.png.

The mobile Page header renders 412 × 274 CSS px = 1,504:1. Our cover is 2,628:1, so Facebook keeps its full height and shows only the centre 938 px of its 1640 px width (57,2 %) — 351 px cut from each side. marketing/facebook/build.py builds to a safe area of the centre 1028 × 544, which leaves 306 px clear of each edge: 45 px per side wider than the phone actually shows. Measured on the shipped file, the light text in out/cover-c.png runs from x 333 to x 997 and the left crop edge is x 351, so the first 18 px of the text are cut. On screen the headline reads „aját szabályaid" and the wordmark reads „elhom.eu". Filed as R-919; nothing was re-cropped on Facebook, per the task's fence.

The mobile profile circle is also much bigger than the README assumed: 172 px, centred, overlapping the bottom 112 px of the 274 px cover — in source coordinates it hides x 637–1030 × y 369–624. It covers part of the dashboard picture, no text.

Two things this contradicts. Meta's own help page says the mobile cover is 2,4:1; the Page header measures 1,504:1, so Meta is wrong about its own rendering. And the arithmetic this file carried before the measurement — „a 2,4:1 crop loses ~71 px a side, and the safe area is 306 px clear, so the headline should survive" — was right in method and wrong in conclusion, because it trusted Meta's ratio. The real crop is five times deeper. It is left recorded here as the reason not to report arithmetic as a check.

How to get Facebook's phone layout at all (this took several wrong turns)

What does not work — narrowing the browser window:

1. resize_window to 1440 × 900 and to 390 × 844 while the Chrome window was maximised — the tool reported success each time and window.innerWidth never moved (2133).
2. The operator un-maximised the window; resizing then worked, but only the first call after a window state change took effect — several later calls reported success and changed nothing.
3. With the window narrowed to about 500 px (C3-narrow-window-horizontal-scroll.jpg), www.facebook.com kept the desktop layout and grew a horizontal scrollbar: window.innerWidth stayed pinned at 1105 and document.documentElement.scrollWidth at 2051. The desktop site has a minimum width.
4. https://m.facebook.com/felhom.eu redirected to https://www.facebook.com/felhom.eu?_rdr.

What does work — Chrome DevTools device mode, which also sets the user agent:

5. F12 → Ctrl+Shift+M → pick Pixel 9 (412 × 924, dpr 2,625, Android UA). Set this on the tab the browser tools drive: emulation is per-tab and cannot be switched on from the page.
6. Reload afterwards. Without the reload Facebook keeps serving the already-booted desktop bundle and the content stays 901 px wide inside the 412 px viewport (clientWidth 412, scrollWidth 901). After it, clientWidth == scrollWidth == 412 — no overflow, the real mobile layout.
7. www.facebook.com/felhom.eu then hung on the Facebook splash (14 divs, no images, readyState complete). m.facebook.com/felhom.eu loaded properly — the redirect in step 4 only happened because the user agent was still a desktop one.
8. Set DevTools' device-mode zoom to 100 %, or screenshots come back at the scaled size (118 × 264 at 29 %). getImageData on a Facebook CDN image throws SecurityError (tainted canvas), so the cover cannot be analysed in the page — read it off the screenshot.

Secret scan

Run over this whole directory, with a planted control. --exclude=README.md is load-bearing: this file quotes the search strings verbatim, so without it the scan finds itself (4 false EAA hits and 1 false "access_token") and stops being able to tell a real hit from its own documentation.

printf 'EAAfakeprobe\n' > decoy-control.txt
grep -r -o -a --exclude=README.md 'EAA' .      ->  1      (the control, so the search works)
rm decoy-control.txt
grep -r -o -a --exclude=README.md 'EAA' .      ->  0
grep -r -o -a --exclude=README.md '"access_token"' .  ->  0
grep -r -o -a --exclude=README.md -iE 'jelszo|jelszó|password' .  ->  0

The exclusion is safe because this file is written by hand and holds no captured output.

The first pass found 1 real hit: probe/run.log line 1, the probe's own key FACEBOOK_API: <n> chars, starts EAA line. That is token metadata, not a token, but it was redacted in place before committing and the line says so. No token, no password and no personal data is in this directory; the Messenger inbox, the credentials file and the operator's personal profile were never screenshotted.