Files

T

admin a76207945e

gates / gates (push) Successful in 4m31s

Details

marketing/facebook: the phone check ran after all — the cover IS cut on phones (R-919)

Your suggestion to use DevTools device mode was right; "cannot be checked" was
too quick a conclusion. On an emulated Pixel 9 (412x924, mobile UA, with a
reload so Facebook serves the mobile bundle) the Page's mobile header renders
412x274 = 1.504:1. Facebook keeps the cover's full height and shows only the
centre 938 px of its 1640 px width -- 351 px off each side. build.py's safe
area leaves 306 px clear per side, 45 px too few, and the light text in
cover-c.png runs x333..x997 against a left crop edge of x351, so 18 px are lost:
the headline reads "aját szabályaid" and the wordmark "elhom.eu" on every phone.

Nothing re-cropped on Facebook (the task's fence). The fix is build.py's safe
area (<=938 px, ~900 for margin) plus the measured 172 px centred phone profile
circle, then a hand re-upload. R-919 opened; R-918 closed and moved to
CLOSED-ITEMS with the recipe that made the check possible.

Meta's help page is wrong about Meta's own rendering: it states 2.4:1 for the
mobile cover where the header measures 1.504:1, so this session's first-pass
arithmetic -- explicitly labelled arithmetic, not a check -- under-predicted the
crop about fivefold. That is recorded rather than quietly deleted.

Also: the evidence secret scan needed --exclude=README.md, because that README
quotes the search strings and was matching itself (4 false EAA hits, 1 false
access_token); with the exclusion, control 1 -> 0 and no real hit. And the
Business & legal section header was already miscounted before this session
(said 9/P2 4, actually held 10/P2 5) -- corrected; five other section headers
drift too and are named in the report, left for a session that owns the register.

2026-10-08 21:50:57 +02:00

8.9 KiB

Raw Blame History

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:

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).
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.
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.
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:

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.
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.
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.
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.

8.9 KiB Raw Blame History Unescape Escape