163 Commits

Include renames

Author	SHA1	Message	Date
5 people	a5f85da4af	UI - Keep history diff title and controls visible while scrolling (#4412) ... * Keep history diff title and controls visible while scrolling The watch label, version selectors, diff options and tabs move into a sticky #diff-header, and the top menu above it (watch URL, EDIT, theme and GitHub links) becomes sticky too, so the whole header stays on screen while the diff scrolls. The minimap and anchor jumps offset by the measured height of both bars instead of a fixed value. Heights are measured on load and kept current with a ResizeObserver where it is available, falling back to the window resize and hashchange events as the restock graph and queue sparkline already do, plus one deferred measure at load - the tab switch hides #settings and so resizes the header without a window resize, and opening a link already at #screenshot does the same with no hashchange to follow. The app header is stored before the diff header is measured, since the latter's cap is derived from the former. A sticky bar must be opaque to the content scrolling beneath it, but the page's own backdrop is a fixed full-viewport gradient layer over the page colour, so a flat --color-background panel reads as a white band cutting across it. Instead each bar repaints that same backdrop via a shared page-surface-gradient mixin: the three gradient stops pre-composited against --color-background-page with color-mix() at the layer's 0.91 opacity, with background-attachment: fixed so they stay registered with body::after. Children of #diff-header are centred with a flex column, mirroring the align-items: center that section.content applies to the non-sticky siblings, so the controls panel and tabs keep their intrinsic width and standard colours. The top menu is made sticky only under body.difference-page. Upstream already wants this globally (see the @todo in parts/_top_menu.scss) but held off because the bar has no background of its own; scoping it here keeps that decision separate. Sticky makes .header a stacking context, so its mobile drawer is capped at the bar's z-index of 30 - high enough to cover #diff-header, low enough that the action rail's hover flyout and toast notifications still paint over the bar as before. The activity strip is fixed on body in the root stacking context, so it would have painted through the capped drawer; on this page it drops just below the bar rather than raising the bar past the rail. Dropping the 40px section.content padding and tightening the title's own padding closes the gap between the two bars, and #diff-header's half-viewport cap now excludes the top menu so the sticky stack stays within the same budget on short viewports. .app-main's 0.55rem gap goes too on this page: it sits between the two sticky bars, so the diff header would otherwise start 8.8px below the top menu and slide up to meet it over the first 8.8px of scroll. That gap cannot survive sticking - it is outside both bars, so the diff would scroll through it - and the bars are flush at every scroll position instead. Co-authored-by: Engineer <engineer@agents.matrixsi.com> Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> * Condense the history diff header into a compact toolbar The sticky bar the previous commit introduced takes 297px of a 1000px desktop viewport and 422px of a 390x844 phone - at that width its own 50dvh cap is already clipping it, so the shipped page scrolls a header inside itself before the diff has moved at all. Compact it to three rows and that becomes 154px and 228px, without hiding any control. The watch title takes the full width of the bar on its own row above the controls, centred, 0.9rem, one line with an ellipsis. It truncates only when it is wider than the whole viewport - a 184-character title shows in full at 1440px and ellipsizes at 768 and 390 - and the bar keeps exactly the same height either way, which a two-line clamp would not. The full text goes in the title attribute so hover reveals what the ellipsis hides, the same bargain the watch URL above it already makes. The From/To labels shrink to chips rather than hiding. display: none takes a <label> out of the accessibility tree: verified through Chromium's accessibility tree, the selects report "From" and "To" with the chips and "" without them. Sighted users need them too, since two identically formatted datetime selects side by side have only their order to tell them apart, and on a phone they stack so even that stops helping. The chips cost horizontal space and no height at all. Dropping the shipped width: 4rem sizes them to their text, and "From" is wider than "To", so a min-width floor keeps the stacked selects flush. The seven diff options move behind a Filters button. The fieldset stays inline, inside the form, until diff-overview.js swaps it for the popover, so with scripting off the options are exactly as reachable as they are today. The panel is position: fixed, not absolute: #diff-header carries overflow: auto to enforce its 50dvh cap, which clips an absolutely positioned descendant at the bar's bottom edge. The bar is sticky with no transform, filter or contain, so it is not a containing block for fixed and the panel escapes the clip; the script parks it under the button and keeps it inside the viewport, with aria-expanded, Escape, outside-click and a reposition on resize. The keyboard-nav prompt and the two button words are hidden, leaving the arrows; both links carry the full wording as aria-label and title so the accessible name survives the CSS. The tabs' vertical padding halves on this page, 11px off every scroll position, leaving their horizontal padding and so their widths alone. Narrow viewports need one more thing, and font-size alone cannot give it: once the chip takes inline width the select clips its own displayed value, and two snapshots from the same day differ only by the meridiem, so they read identically while closed. #settings, #diff-form, .diff-fieldset and the span are all sized to max-content, which is the select's text, so the container shrinks by exactly as much as the text does - headroom measured 0.0px at every size from 0.9rem to 0.7rem. The chain is pinned to the row first and only then does 0.75rem buy room: +19.3px on the demo pair and +6.3px against the longest realistic English value, which still clips at 0.8rem. All of it hangs off the one 700px breakpoint, and every selector in it carries an ID because the rules it overrides are written with one and a class-only override would lose silently. Co-authored-by: Architect <architect@agents.matrixsi.com> Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> * Rebuild translation catalog for the new diff header strings The compact header adds three msgids - Filters, Previous version and Next version - and the lint-translations job re-runs extract_messages, update_catalog and compile_catalog and fails on any resulting diff, so the catalog has to travel with the strings that created it. It failed on 297bd365 and took the four test-application jobs down with it, since they depend on it. Purely mechanical: the extract adds exactly those three entries to messages.pot and to each of the seventeen catalogs, all with an empty msgstr, and changes nothing else. The .mo files are unchanged, because an empty msgstr is not written to the compiled catalog. POT-Creation-Date is deliberately left at its committed value rather than restamped. The job filters that line out of the diff it checks, so restamping buys nothing, and 0.60.4 rewrites the same header lines - a restamp here would conflict with the release commit over a timestamp. Kept out of the header commit so the change being reviewed stays the template, the stylesheet and the script. Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> * Make the sticky diff header full-bleed and pin its cap to svh Two iOS-only faults in the sticky bar, both reported from a real iPhone and neither reproducible in Chromium, emulated or not. Both are properties of 43b07d5b rather than of the compact toolbar on top of it. section.content insets its children by $common-gap so they clear the left rail, while the top menu above stays flush against it, so the bar left an 8.8px strip of real page background down each side. That strip is invisible only while the bar's gradient stays aligned with the page's, which is what background-attachment: fixed buys - and iOS Safari does not honour it. There each box samples its own origin, so the bar paints the start of the ramp (#5ad8f7) while the strips paint whatever the document shows at that scroll offset (#9150bf at depth), and they read as mismatched borders that hold still while the diff scrolls past. Cancelling the inset removes the thing that has to stay matched, on every engine, instead of blending across it. The width has to come from align-self: stretch, not width: 100%. .content-main centres its children, so an item is fit-content unless it stretches, and a percentage resolves against the parent without the negative margins - it would leave the bar 17.6px short. Measured flush against the top menu at 1440, 768 and 390: 1358.4/1358.4, 768/768, 390/390. Note the desktop figure is not the 1440px viewport, because the rail takes 81.6px; the invariant is the top menu's box, not the window's. The height cap moves from dvh to svh. dvh tracks the dynamic viewport, which on iOS grows and shrinks as Safari's toolbar collapses and expands during a scroll: the cap breathed mid-scroll, changing the header's height and shifting the content below it, and each transition also fired resize and re-ran the sticky measurement behind it. svh is defined as the toolbar-expanded minimum and holds still for the life of the page. It is the smaller of the two, which is the safe side to be wrong on for a cap, and the plain vh line stays as the fallback for engines without the new units. This one has no Chromium instrument - there is no dynamic toolbar to simulate - so it is verified on the device, not in the harness. No control moves and no height changes: the bar grows outwards by exactly the margin it takes back, and the sticky stack still measures 153.9px at 1440, 230.7px at 768 and 227.5px at 390, the same as before this commit. Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> * Stop the tab wrap verdict depending on which tab is selected base.html decides body.wrapped-tabs - the vertical tab stack - by flipping the tab list to flex-wrap and checking whether any tab lands on a second row. It re-runs on load, on resize and on every tab switch. Both sides of that comparison move, so in a band of widths the answer changes per tab: a phone showed the three tabs in a row in one screenshot and stacked in a video of the same page. The container moves because _tabs.scss says, in upstream's own comment, that .tabs must take the full width of the centred column "so the wrap-detector JS has the real available space to measure against" - and the two properties that would do it sit commented out directly beneath it. Inside the compact header, which centres its children, .tabs is therefore sized to its own content and the detector measures against a container that follows the thing it is judging. align-self: stretch here fixes that, scoped to this page; un-commenting the global lines would change every page in the app and this branch has no business doing that. The tab row is re-centred on the ul, which is a grid, so the visual is unchanged. The content moves because the active tab's label is bold. At 355px the Text and Extract Data states measure 332.9 and 330.5 against a 339.0 container and stay on one row, while Current screenshot - the widest label - goes over and wraps to three. Removing only the bold rule collapses all three states to 330.5 and the flipping stops, which is what identifies the weight rather than the container as the second variable. Dropping the bold on this page is the fix: the active tab already carries its own background-colour and its own text colour from _tabs.scss, so it loses the third of three signals and nothing else. Reserving room for the bold instead - a hidden bold copy behind every label - stabilises it too, but widens the row ~14px in every state, which pushes 360px from one row into the stack. Measured stable across 320, 344, 350, 355, 358, 360, 375, 390 and 412px, with the one-row layout now holding down to 350px where before it was unstable from 350 to 358. iOS put the same band at the phone's own width because its fonts are wider. Nothing here is engine-specific - the instability is arithmetic, and Chromium reproduces it once you look at the widths where the numbers cross. Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> * Keep the Filters popover reachable and anchored on a small screen Two defects in the same placement code, both outside the viewport range the desktop frames covered. The panel is position: fixed, because #diff-header carries overflow: auto for its 50svh cap and would clip an absolutely positioned descendant. Fixed also means nothing the document does can scroll the panel: whatever hangs off the bottom edge at placement time stays unreachable. It was parked below the button at full height regardless, so in a landscape phone viewport - 844x390 - it spanned y=150.4 to 431.6 and the last three filters sat past the 390px edge. Replaced, at y=396.6..423.6, could not be clicked at all. place() now measures the room below the button and caps max-height to it, and the panel scrolls inside that cap. Room below is always the roomier side, so there is no flip to decide: the bar's own cap keeps its bottom edge inside 50svh, so below the button there is always at least half the viewport. The harness asserts that premise rather than trusting it. The cap is handed to max-height less the panel's own padding and borders, since the panel is content-box and switching it to border-box would fold the padding into min-width and narrow it by 24px. The bar is also its own scroll container, which the code did not account for - its comment claimed only a resize could move the button out from under the panel. On a short viewport the 50svh cap engages and #diff-header scrolls independently: 16px of scroll at 390x390 moved the button 16px while the fixed panel stayed at y=171, and 30px at 320x480. The popover visibly comes away from its trigger and can end up over the wrong control. It now re-places on the bar's scroll, and closes instead once the button has scrolled out of the bar altogether - reachable below 280x300, where the bar has 120px of travel. Verified in Chromium at 844x390, 740x360, 390x390, 320x480, 280x300, 390x844 and 1440x1000: the panel stays inside the viewport at every one, the last filter is clicked for real rather than asserted on by rect, and the gap between button and panel holds at 4px across the bar's whole scroll range. All seven fail on the tree without this change - twelve failures, the click timing out on the three short viewports. Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> * Keep the Filters popover's height budget current with the visual viewport place() already budgets against the smaller of documentElement.clientHeight and visualViewport.height, because a fixed element is positioned against the layout viewport while iOS shrinks the visual one behind its chrome. But the open panel was re-placed only on window resize and on #diff-header scroll, and neither of those fires when the visual viewport alone changes - an expanding toolbar or the on-screen keyboard does exactly that. The cap then stays at the height it was computed with and the bottom filters go back behind the chrome, which is the failure the cap was added to prevent. That half of place() was recorded as unverifiable, on the grounds that Chromium has no dynamic toolbar and the two viewports are always equal here. They are equal only at page scale 1. CDP Emulation.setPageScaleFactor is pinch-zoom: it shrinks the visual viewport against a layout viewport that does not move, and fires VisualViewport resize - the same split iOS produces. So both halves are measurable, and the harness now measures them at 390x844@2, 844x390@1.5 and 390x390@1.5: * placing while the visual viewport is already the smaller one caps the panel to it - 85.6px against a layout-budget 215.6px at 844x390 - which is what shows the Math.min binds rather than sitting inert; * on the tree without this commit, shrinking the viewport under an open panel left the cap untouched and the panel overhung the visible area by 122px at both short viewports and 46.8px at 390x844. Three failures, one per viewport, and none anywhere else in the harness. The probe asserts its own instrument before its result: unless the scale really splits the two heights and the page really receives the resize event, it fails rather than passes. It also fails if no viewport in the set caps more tightly than the layout height would have, since then the visual-viewport budget is untested, and if a viewport's panel already fitted before the shrink, since then it cannot detect a stale cap. The re-placed cap lands on the same value as placing fresh at that viewport (210.4, 85.6, 65.0px), and the panel's width is unchanged by the re-placement. Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> * Stop the sticky bars' backdrop depending on background-attachment: fixed Reported from an iPhone: on the diff page the sticky bar sweeps cyan to purple as you scroll while the page behind it holds still, and snaps when you scroll back up a little. The gutters beside it are correct throughout, so the page's own backdrop - body::after, a real position: fixed layer - is fine; it is the bars' copy of it that moves. page-surface-gradient asked for that copy with background-attachment: fixed, which makes the viewport the positioning area. iOS Safari does not honour it and anchors the layer to the document instead, so each bar shows whatever slice of the ramp its document position lands on. Chromium does honour the property, which is why every emulated check passed and only a device caught it. Derive the alignment from geometry instead, and ask for no engine feature at all. body::after is a viewport-wide, 100vh-tall box pinned to the viewport's top-left corner. Each bar keeps a constant viewport offset - .header at the top, #diff-header at --app-header-height, which the ResizeObserver already keeps current - and both are flush with the viewport's right edge at every width. So size the copy to the viewport, anchor it to that right edge, and push it up by the bar's own offset: the bar then paints body::after's own slice by construction, on any engine. Three details that are load-bearing: * 100vw, not 100%. The two bars are as wide as the viewport only on a narrow screen; at 1440 the action rail insets them by 81.6px (and widens further on hover), so a percentage would compress the whole ramp into what the rail leaves. Nothing moves their right edge, which is why that is the anchor. * background-origin: border-box. #diff-header carries 1rem of side padding and 0.25rem on top, and the default padding-box origin would offset the copy by exactly that. * longhands, with the solid-colour fallback shorthand first and no shorthand after them - a later `background:` line silently resets size, position and origin to their initial values. The Filters popover has no constant viewport offset of its own, so diff-overview.js hands it the one it just computed, in the same place it sets top and left. Measured in the harness against the page itself: shot B hides .app with visibility: hidden, which leaves body::before/body::after painting alone with layout and scroll untouched, so "seamless" is a pixel comparison rather than a judgement. Worst per-channel distance from that backdrop, over 40 samples at 1440x900, 768x1024, 390x844, 844x390 and 320x600, each at three scroll offsets and with the popover placed twice: bars popover before, attachment honoured 3 6 before, attachment denied 24 112 after, attachment honoured 3 6 after, attachment denied 3 6 "Denied" injects background-attachment: scroll !important - it takes away the one property iOS ignores. The before/after rows differ only in whether the engine grants it, and the after rows are identical to each other: the code path no longer has an opinion about it. That denial is not a full iOS emulation - WebKit anchors the layer to the document, which also produces the sweep, and nothing in Chromium reproduces that - so the device pass is still the gate on the sweep itself. Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> * Give the diff page's screenshot tab the short label the extract page uses On a phone the three tabs render as a full-width vertical stack. base.html's wrap detector flips the page into body.wrapped-tabs when the tab row does not fit its container, and iOS font metrics put this row over the line at 390px - an iPhone's width. 01420ac7 stopped the verdict flip-flopping between tabs; it did not give the row room to fit. The extract page's tab for the same pane is called "Screenshot". It renders on one line on the same phone at the same width, which is the evidence this change rests on: the two pages then carry the identical three labels, the diff page's row asks for no more width than the extract page's, and #diff-header offers it slightly more room. Measured at 390px: diff page, this change row 275.4px offered 374.0px extract page row 280.8px offered 372.4px diff page, before row 330.6px offered 374.0px So the phone's own extract-page row settles the diff page, with no iOS font model in the argument. In Chromium the narrowest viewport that still fits on one line moves from 347px to 292px. "Screenshot" is also what translations/README.md asks for - the shortest suitable wording - and it makes the two sibling pages agree, which they should have done anyway. The catalogs are regenerated for the moved msgid reference; the empty msgstrs this exposes are filled in the commit that follows. Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> * Keep the tab row inside the sticky bar when the bar runs out of room Reported from an iPhone held sideways: the diff page's tabs are not there. The bar's height budget is max-height: calc(50svh - the top menu) with overflow: auto, and in landscape its contents do not fit inside that - iOS gives the two datetime <select>s enough intrinsic width that From and To each take their own row, so the bar wants title + From + To + Filters + tabs where it has room for about three of them. What scrolls out of the visible box is the last child: the tab row, which is the page's navigation, with no scrollbar on a touch screen to say it is there. This one does not need the device. Chromium overflows the same bar on its own at 736x414, 667x375, 780x360, 844x330 and 844x300, and at 844x390 with From/To forced onto their own rows - measured as the tab row's rect falling outside So spend the budget on the row that can afford to give. #settings is the only child allowed to shrink and the only one that scrolls; #diff-watch-title and .tabs are flex: none and are therefore inside the bar at any viewport height. The shrink needs min-height: 0 on #settings - a flex item's automatic minimum size is its content, which is exactly what was pushing the tabs out. diff-overview.js follows the Filters button while the bar scrolls under the fixed panel, and the element that scrolls is now a descendant rather than the bar itself. Scroll events do not bubble, so that listener moves to capture; it then catches #settings and #diff-header's own last-resort scroll alike, and the close-when-the-button-leaves-the-bar test is unchanged because it already compares against #diff-header's rect. Verified: the tab row is inside the bar at all nine viewports above, and with the pre-change diff.css and diff-overview.js served back over the wire in the same run, six of the nine fail - the check is not watching an empty room. The popover drift probe in the harness was retargeted at whatever inside the bar actually scrolls, and proved red first: with the capture flag removed the panel drifts 3.0px off its button at 390x390 and 12.0px at 280x300. Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> * Close the seam between the active tab and the diff card Reported from the device: a gap between the tabs and the content on Text and Screenshot, and none on Extract Data. It is #diff-header's own 0.25rem of bottom padding. The tab row is the bar's last child, and the active tab and #diff-ui below it are both var(--color-background) - so those 4px paint the page gradient across what is otherwise one continuous white surface, and the tab stops reading as the front edge of the card it belongs to. Extract Data looks right because its tabs are not in a bar at all: the same measurement on that page is 0. Measured at 1440x900, 768x1024, 390x844, 844x390 and 320x600, on both the Text and Screenshot tabs: 3.2-4.0px before, and -0.8 to 0.0 after, with the tab and the card confirmed to be the same computed colour in every frame. The check fails only on a positive gap: a sub-pixel overlap of white on white has nothing to show. The top padding stays - nothing sits above the title. Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> * Land at the top of a tab's pane when the switch resizes the page under it Reported from the device: the Screenshot tab starts scrolled down a bit. The recording shows it plainly - for about a second after the tap the tip's first line sits behind the sticky bar, then Safari settles it. Order of events. The browser performs the fragment jump to #screenshot first. Only then does this file's own hashchange handler hide #settings, and the outgoing #text pane stop being :target - which takes the document from ~8000px to a fraction of a screen. The engine is left holding a scroll offset for a page that no longer exists, and clamps it to the new maximum rather than re-running the jump it has already done. On iOS that maximum is never zero: styles.scss floors the shell at min-height: 100vh, and 100vh there is the toolbar-collapsed viewport, so with the toolbar showing the document outruns the visual viewport by the toolbar's own height and the stale offset has somewhere to survive. So re-run the jump once the layout has stopped moving. scrollIntoView rather than scrollTo(0, 0): .tab-pane-inner already declares the offset the sticky stack needs as scroll-margin-top, and this asks for the same alignment the browser was asked for, against the layout that actually resulted. setTimeout(0) rather than requestAnimationFrame, because that scroll-margin-top is written in terms of --diff-header-height and diff-render.js's ResizeObserver updates it during the rendering update, after animation frame callbacks have run - and hiding #settings is precisely what changes it. Honest limit: Chromium is not the engine that gets this wrong. With the document floored above the viewport it lands 1px off before this change and 0 after, at 390x844 and 390x500 - the right direction, but a pixel is not the line the phone showed. The mechanism above is read off the recording and the code, not reproduced here, and the device is what settles it. Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> * Drop the sticky design on a short viewport rather than compensate for it A phone held sideways is the one place the sticky bar cannot pay for itself. 50svh of a 390px-tall viewport is 195px, the top menu takes 55 of that, and what is left has to hold From, To, Filters and the tab row - three of those on their own lines, because iOS gives the two datetime selects enough width that From and To cannot share one. The previous two commits kept the tab row inside the bar by shrinking #settings into a scroller, then took the title and some padding back to widen the margin. Both were right about the budget and neither made the bar usable: the reporter's answer was still "it's only showing the From line and I have to scroll", and that is reproducible here - at 780x360 and 844x330 the To selector, the Filters button and both version arrows are clipped out of So below 500px of viewport height, give up the budget instead of spending it. Both bars become ordinary static blocks: no height cap, no inner scroller, title and every control present at once, and the page scrolls as one document. Neither bar keeps its pre-composited copy of the page gradient, which is not optional - that copy is aligned by pushing it up by the bar's own *constant* viewport offset, and a bar that scrolls has no constant offset, so it would slide out of phase with body::after's fixed layer. With nothing scrolling underneath, the real fixed backdrop shows through and is aligned by construction. The trade, plainly: in landscape and in a short desktop window the controls and the tab row scroll away with the diff, so switching tabs means scrolling back up. That is the right side to be wrong on when the alternative is controls you cannot see. Portrait and the desktop are untouched and still sticky - asserted, not assumed. Three things this turned up that the plan did not anticipate, each of which the change itself breaks and so belongs here: * The minimap is sticky inside the diff card at an offset equal to the sticky stack's height. With that stack gone it would pin itself 150-227px down the viewport under nothing - past halfway on a 390px-tall one. Pinned to the viewport instead, which is now free. * The Filters panel is position: fixed and followed its button only through a capture-phase listener on the bar, because the bar held still and #settings moved inside it. Static mode is the mirror image - nothing moves inside the bar and the bar itself moves with the document - so the panel drifted by the full scroll distance: 200px at 844x390, 926x428 and 1440x480. The same follow/close rule now runs from the window's scroll as well, and carries both closing tests; each is inert in the mode it was not written for. * place() had no flip-above branch, and compact_verify.py carried the reason as an assertion: the bar's own 50svh cap kept its bottom edge inside the top half of the viewport, so below the button was the roomier side by construction. Removing the cap removes the premise, and that assertion is what caught it - at 280x300, 147.6px above the button against 104.2px below. place() picks the roomier side again. The load-path scroll fix is the fourth, and it is the one worth reading twice. upstream's tabs.js rewrites an empty hash to the first tab's, and the browser performs that jump the moment the diff is built - before diff-render.js has measured the bar, so scroll-margin-top is still resolving against its --diff-header-height: 0 fallback. Traced at 844x390: the jump lands at scrollY 231 against a 16px margin at t=132ms, and the margin becomes its real 202px at t=167ms with the offset left where it was. Under a sticky bar that is invisible, because the chrome is pinned whatever the offset is; with the bar in flow the same 231px put every control above the top of the page and a landscape phone opened on a bare diff. So the alignment re-runs when the quantity it was wrong about settles - the bar's own size - guarded on the reader still being where the last alignment left them, so that rotating the phone mid-read cannot throw someone back to the top of the pane. Portrait benefits too: the page used to open 224px into the text diff and now opens at 1. .tab-pane-inner's scroll-margin-top is deliberately NOT dropped to 1rem here. It reads as an allowance for pinned chrome and therefore like dead weight once nothing is pinned, but the same number is right in both modes for two different reasons: sticky, it clears chrome painted over the pane; static, it keeps chrome that sits above the pane on screen. The comment says so, next to the measurement. 20d75707, which hid the watch title in landscape to buy budget room, is rebased out rather than left in and undone - there is no budget to buy any more, and the question of whether hiding it was acceptable goes away with it. Verified in four browser runs that vary the two changed files independently, because the popover check needs the new stylesheet with the old script: serving both old puts the page back in sticky mode, where it passes for the wrong reason. Every run reads the served diff.css and diff-overview.js back over the wire, hashes them, and fails if they are not the pair it meant to serve. On the branch: PASS, no failures. Reachability went red at 10 of 14 short viewports on the old pair, the gradient copy at 7, the minimap at 7, the load landing at 5, and the popover drift at 3 on the new-CSS/old-JS pair. The full branch harness and the previous round's probe both re-run green. One instrument repair, and it had been green while measuring nothing. The popover drift check scrolls whatever inside the bar can move and re-reads the gap - but page.click() scrolls the toggle into view to click it, which leaves that scroller already parked at its maximum, so "scroll to the maximum" was a no-op and the check compared two identical readings. It now drives the scroller to whichever end it is not at, and proves the point by comparing the two readings rather than by testing for non-zero. Re-proved red on the real code: with the capture flag removed the panel drifts 45px off its button. Nothing inside the bar overflows in this engine at any viewport any more - that was always iOS's wider metrics - so the condition is forced with an explicit max-height rather than hunted for. Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> * Give the tab-to-card seam a whole pixel of overlap instead of none The thin blue line under the active tab is the page gradient, not a border - nothing at that boundary has one, the active tab and #diff-ui are both var(--color-background). It can only be a device-pixel row where neither white paints, and whether such a row exists comes down to a single number: the bar's bottom edge minus the card's top edge. Measured across 14 viewports at device pixel ratios 1, 2 and 3, on both the Text and Screenshot tabs, that number is 0.813px, 0.203px or exactly 0.000 - 84 readings, not one of them a whole pixel, and 0.000 at 390x844 on the Screenshot tab, which is the exact case reported. At zero the outcome is not a decision the stylesheet makes; it belongs to whatever the engine does with two edges on the same coordinate, which is why a DPR 3 phone can show a line a DPR 1 desktop does not. Chromium rounds the same way on both sides and paints no sliver at DPR 3 either - walking the bar's height in thirds of a pixel did not produce one. So this is the margin being fixed, not a pixel being chased: after the change the worst of the same 84 readings is exactly 1.000px. The alternative - a white skirt under the active tab, box-shadow: 0 1px 0 - would have been more precisely scoped and does not work. The shadow hangs below the bar's last child and #diff-header's overflow: auto, which is what enforces its height cap, clips it. Measured with the card held 3px away so the skirt and the card are separable: 0 device rows of the 3 it needs at 844x390 and 926x428, and 0 to 2 in the sticky modes. The negative margin is what survives the clip, because it moves the card rather than painting past an edge. Scoped to body.difference-page, which matters more than it looks. diff.css is not diff-page-only: preview.py and processors/extract.py serve it too, both pages have a #diff-ui of their own, and neither has a bar above it to absorb the pixel. Asserted rather than reasoned - the preview page's computed margin-top is 0px with this stylesheet and with the previous one, while the diff page's moves to -1px. The comment on the activity-strip rule above claimed diff.css was loaded only by the diff page; that was wrong and is corrected, since the scope it describes is what actually does the work. What the overlap costs, stated rather than left to be found: where the bar is sticky, nothing. A device-pixel diff of the seam band at 390x844 and DPR 3 comes back with zero differing pixels, because the bar is opaque and paints over the card. Below the short-viewport breakpoint the bar has no background of its own, so the card's white also reaches the bottom pixel of the inactive tabs and the 5px gaps between them - 4374 device pixels at 844x390, gradient turning white, and side-by-side crops of the two are indistinguishable. The tab row ends up sitting flush on the card instead of floating a pixel above it, which is how tabs normally meet their panel and is the same continuity the active tab was asked for. Full branch harness, the previous round's probe and this round's all re-run green against the change. Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> * Reuse upstream's Previous and Next for the version arrows' labels 297bd365 gave the version arrows `title` and `aria-label` of their own, "Previous version" and "Next version". Those are two msgids this branch introduced and no catalog has ever carried, so on a German or Japanese page the arrows' accessible name is English. The upstream msgids `Previous` and `Next` say the same thing in this context - the arrows live inside the version bar, between the From and To selectors - and are non-empty in 15 of 17 catalogs; the two empty ones are en_GB and en_US, where the English msgid is the correct rendering anyway. The visible span on each arrow already uses these msgids, so the accessible name and the (header-hidden) label now agree instead of differing by a word. The cost is that the accessible name drops "version": a screen reader says "Previous" rather than "Previous version". On a control that sits between two datetime selectors that is enough, and it is the price of not asking fifteen translators for a string they can already spell. The catalogs are regenerated: both msgids disappear from the .pot and from all 17 .po files. No .mo file changes, because neither msgid had a msgstr anywhere to compile. Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> * Correct the French translation of "Previous" fr renders the msgid `Previous` as "Aperçu", which is French for *preview*. That is a wrong word, not a style choice: the same catalog gives "Aperçu" as the msgstr for `Preview` and for `Activate preview`, and it evidently leaked from there. The msgid renders in exactly two places, both of them prev/next pairs - this page's version arrows and preview.html's own pager - and fr already translates `Next` as "Suivant", so "Précédent"/"Suivant" is the pair the catalog is otherwise using. On the preview page the current string produces an "Aperçu" button on the page called Aperçu. Left alone deliberately: de renders `Previous` as "Zurück" (*back*). That is defensible on a back arrow and is a translator's call, not an error. Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> * Put the watch's name on the top line and drop the diff page's second title row The diff page printed the same thing twice. The menu's top line has always shown the watch URL, and 297bd365 added a sticky <h1> under it showing watch.label - which for any watch without a custom title *is* that URL. Two rows of chrome, 30px of the sticky budget, and on the common case the identical string on both. dgtlmoon's read (#4412): put it all on the top line, use the title if it is set, and take back the left inset while we are there. That is what this does, and it removes code rather than adding any. The top line's <a> is unchanged as a link - same href, same fade-out mask, same flex-shrink that keeps a long value off the menu icons. Only its text changes: current_diff_label (watch.label - title, then the fetched page_title, then the URL) with the URL as the fallback, so an untitled watch reads exactly as it does today. The five views that already pass current_diff_url pass the label beside it. The hover text now carries both, label then URL on its own line, and only when they differ. A title covers the URL that used to be printed here, and the URL is also where the link goes - so it has to stay readable without following it. That also keeps the long-title-on-long-press property the <h1> had. The heart hides under $desktop-wide-breakpoint on this page only. That is the width where the hamburger appears and the row is at its tightest, so it is where the name needs the space; on a desktop diff page and on every other page the heart is untouched. It is a media query rather than a {% if %} because the heart's reason to exist is that it is always there - folding it away with the rest of the narrow row is a different thing from taking it off the page. Left-justification: the line's text started $common-gap twice in - the menu row's own padding plus the link's own left margin. On the row's first item the second one only repeats the first, so it goes and the row's padding stays. 8.8px back, and the line still shares a left edge with the diff below it rather than sitting hard against the viewport. The right side of both is untouched. No new or removed translatable strings, so no catalog churn. Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> * Fill the empty msgstr cells this page's own strings left behind 30 cells across 15 catalogs. No new msgids: extract_messages produces a byte-identical .pot (bar POT-Creation-Date) and update_catalog leaves every .po unchanged, which is the control that nothing here is a source change wearing a translation's clothes. Filters - empty in all 15 non-English catalogs since the diff page's options popover was added. Each value is the plural form that catalog already uses for "Global Filters" and "Filters & Triggers", not a fresh translation: Filtry, Filter, Filtros, Filtres, Filter, Filtri, フィルタ, 필터, Filtry, Filtros, Фильтры, Filtreler, Фільтри, 过滤器, 過濾器. Screenshot - this is a regression the diff-header work introduced and owes. The tab used to read "Current screenshot", which every catalog translates; shortening it to "Screenshot" moved the tab onto a msgid that nine of them (cs, de, es, fr, it, pt_BR, tr, uk, zh) had never filled, so those users got an English tab where they had a translated one. Each value is that catalog's own "Current screenshot" with the qualifier dropped - Snímek obrazovky, Captura de pantalla, Capture d'écran, Ekran görüntüsü, Скріншот, 截图 - and for de, it and pt_BR the word those catalogs already use is literally "Screenshot" (Aktueller Screenshot / Screenshot corrente / Screenshot atual), which is what dennis W302 flags and CI excludes. Italian's five pre-existing gaps on this page, deliberately in scope: the guide's multi-language rule is to fix every affected catalog in one session rather than fix one language and move on, and an Italian diff page was showing untranslated From, To, Ignore Whitespace, Keyboard:, Extract Data and Jump to next difference next to strings that were translated. Ignora spazi and Estrai dati come from the same catalog's "Ignore whitespace" and "Extract text" / "Extract as CSV"; successiva from its "Next" -> "Successivo" and differenza from its "Pixel Difference Sensitivity". Compiled with setup.py compile_catalog. en_GB and en_US recompile byte-identical, so the 15 changed .mo files are exactly the 15 changed .po files. Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> * Let the watch title be dragged when it is too long to fit Asked for on the PR: "does the title at the top accept overflow scroll hidden so it can be scrolled with your finger/touch/drag?" It could not - .current-diff-url was overflow: hidden with a fixed right-edge fade, so the end of a long title was reachable only by hovering for the title attribute, which a phone does not have. It is now a horizontal scroll container with its scrollbar hidden in both engines. A tap still follows the link; browsers distinguish a pan from a click, so the anchor keeps its navigation. overflow-y stays hidden because the content is one non-wrapping line and an axis that can move by a rounding error lets a diagonal swipe jog the text. The fade has to follow the scroll, or the ending someone just dragged over to read is the part that is dimmed. static/js/scrollable-title.js maintains fade-left / fade-right against scrollLeft and adds js-fades to say it is doing so; under that class the CSS drops the static mask and paints only the edge that is actually cut off, or a two-ended gradient when both are, or nothing at all when the title fits. The static right-hand fade stays as the no-JS default, which is correct there because without a handler the line can only ever be cut on the right. In base.html rather than diff-overview.js: restock_diff/difference.py and image_ssim_diff/preview.py both render this line and neither loads that file. The script guards on the element existing, so it is inert on every other page. Accepted tradeoff: with the anchor focused, ArrowLeft/Right still runs version navigation on diff pages via the existing window keydown handler rather than scrolling the line. Keyboard users keep the hover title attribute, as today. styles.css is spliced, not rebuilt. parts/_top_menu.scss compiles into styles.css, whose committed bytes do not match a fresh compile of its own scss - an older sass folded rgba(255,255,255,X) to hsla(0,0%,100%,X) and hoisted nested declarations in a different order (#heartpath, .button-tag, .tab-pane-inner, .watch-table img.favicon, #browser_steps li and more). That drift is upstream's and predates this branch. So rather than commit a full rebuild and carry all of it, the scss was compiled twice - at the parent commit and with this change - and only the span that differs between those two compiles was transplanted into the committed file. The drift is identical in both compiles and cancels. The result differs from the parent by 795 bytes, all inside the .current-diff-url rules, and is byte-identical everywhere else; diff.css is untouched. A reviewer who runs npm run build will see a dirty styles.css - that mismatch is the pre-existing drift, not this commit. Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> * Cut diff-overview.js back from a slab to a file Raised on the PR as "a slab of javascript... why cant this be a few lines of jquery". Measured before arguing: upstream's file is 190 lines (144 code, 20 comment) and this branch had grown it to 476 (284 code, 142 comment). Half the growth was comment, written at review density rather than this project's, and that is what makes it read huge. 476 -> 370 (256 code, 72 comment). Every long forensic comment is cut to the constraint it was protecting - the measurement that motivated it survives as a clause, the war story does not. Nothing load-bearing was deleted: the capture-phase scroll listener still says why capture, the visual-viewport listener still says why it exists separately from resize, and place() still says why offsetHeight is read after the cap. Converted to jQuery idiom where that is genuinely shorter, so the file reads in one voice: element lookup, class toggling, open/close, and the event bindings that need no listener options. The geometry stays native, because there is no jQuery shorthand for it - getBoundingClientRect, getComputedStyle, offsetHeight, visualViewport and ResizeObserver are the added code, and popover placement is what they are for. Two registrations deliberately stay on addEventListener and say so in place: the bar's scroll listener needs capture (scroll does not bubble and the element that scrolls is a descendant) and both scroll listeners need passive, neither of which jQuery's .on() can pass. The one structural change is that the four copies of "step both selects one position and rebuild the query string" collapse into diffStepHref(direction), called by the buttons at setup and by the arrow keys at press time. The guards are unchanged: the buttons are only touched when both selects have a selection, the arrow handler still requires both a live step and a button href, and it still returns early while an input, textarea or select has focus. Not done here, and offered instead as a follow-up: moving the popover to the native Popover API. It would delete the dismissal wiring, but placement stays manual without CSS anchor positioning, which is not yet safe cross-browser - and it would churn code that is tested and green. No new translatable strings, so the catalogs are untouched. Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> * Point the top-menu comment at the rule it describes The previous commit inserted the fade variable and mixin between this block and .current-diff-url, which left the comment describing the declaration above it rather than the rule it was written for. It also still said the line "trims" its text, which is now only half true - it scrolls, and the trim is what the fade stands in for. Comment only: sass emits byte-identical css, so styles.css is unchanged. Co-authored-by: Jeff Hedlund <jhedlund@gmail.com> Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> --------- Signed-off-by: Jeff Hedlund <jhedlund@gmail.com> Co-authored-by: Surveyor <surveyor@agents.matrixsi.com> Co-authored-by: Engineer <engineer@agents.matrixsi.com> Co-authored-by: Architect <architect@agents.matrixsi.com> Co-authored-by: dgtlmoon <dgtlmoon@gmail.com>	2026-09-16 14:19:00 +02:00
dgtlmoonandClaude Opus 5	48723a09dd	UI - Search modal - fix Enter dismissing the form instead of searching (#4428) ... Pressing Enter in the search box closed the modal without running the search; you had to click Search with the mouse. Implicit form submission fires a click at the submit button, and a keyboard-synthesised click carries detail 0 and coordinates of 0,0. The backdrop-click handler only tested the coordinates against the dialog's bounding box, so 0,0 read as "outside" - it closed the dialog and blanked the input while the click was still bubbling. By the time the submit ran, `q` was empty and `required` rejected it, so nothing was searched. Ignore clicks with detail 0 - only a real pointer can hit the backdrop. Verified with Chromium against a local instance: Enter now lands on /?q=<term>, and mouse submit, backdrop click, Escape and Enter-on-empty all still behave. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-13 08:25:40 +02:00
3 people	cd66f9ed54	Search modal native submit (#4427) ... * UI - Search - Fix search modal navigating to the host root on sub-path deployments base_path was referenced by search-modal.js but never defined, so searching always jumped to the host root instead of the X-Forwarded-Prefix sub-path. * UI - Search modal - submit natively instead of rebuilding the URL in JS Alternative to defining a `base_path` JS global: give the search form a server-rendered `action`, so url_for() supplies the reverse-proxy sub-path the same way every other link on the page already does, and let the browser submit. Drops the submit handler and the Enter handler from search-modal.js - Enter in the input reaches the footer's submit button via implicit submission, which also runs the `required` validation the synthetic `new Event('submit')` skipped. The hidden tag field is only rendered when a tag is active, so a plain search no longer carries an empty value. Also drops the nginx-job grep for the rendered markup - test_search.py already covers the sub-path case, and asserting on an exact HTML attribute string from a shell grep breaks on any unrelated edit to that tag. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: ponstream24 <87808547+ponstream24@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-12 17:09:10 +02:00
dgtlmoon	35f0294274	UI - Really fix #4413 #4419 Counter bubble in minimal sidebar	2026-09-12 16:03:22 +02:00
滅üanddgtlmoon	f71daee2c4	i18n: Update zh_Hant_TW translations (#4264) ... Co-authored-by: dgtlmoon <dgtlmoon@gmail.com>	2026-09-09 18:49:09 +02:00
dgtlmoon	d901efc8e7	UI - Left menu folds out ONTOP of content, Improving VisualSelector & BrowserSteps width, Darkmode transitions off, Extra sidebar modes #4380 (#4401)	2026-09-09 15:09:27 +02:00
dgtlmoon	3a71777499	UI - Fixing lots of actions that should be a POST style action which led to a 404 ... Also solves some of GHSA-56fq-63vj-9992 Add-watch-UI should be POST/CSRF protected	2026-09-04 12:38:20 +02:00
dgtlmoon	97317398ac	LLM - Per watch/group settings and UI tidyup (#4354) ... * UI - LLM section tidyup * Rebuild translatiosn * UI - Fixing language for prompt adjustement to be more clear * UI - clarify field action * UI - clarify layout for sections * WIP * test tweaks	2026-09-02 10:07:34 +02:00
JDubbandJustin Willhite	5d9c7c6da7	fix: Browser Steps picker cannot select a <select> nested in a <div> (#4336) ... Add select to the element-priority list in the mousemove handler so a <select> wrapped in a similarly sized <div> resolves to the select instead of the div. The process_selected() branch for a select already exists but was unreachable because the select never became the selected element. Fixes #3440. Co-authored-by: Justin Willhite <5132924+thejdubb02@users.noreply.github.com>	2026-08-27 11:34:06 +02:00
dgtlmoon	bb2e6adece	Add watch UI should show which browser(s) are available and set default browser (#4334)	2026-08-25 20:15:59 +02:00
dgtlmoon	89a41c0dda	GHSA-3v57-xv5m-v7m7 - Multiple front-end endpoints lacking CSRF protection	2026-08-20 10:59:38 +02:00
dgtlmoon	6f2e4aa9af	UI - Move rendering of each watchlist row out of the watchlist main template so it can be re-used by the realtime update (#4305)	2026-08-16 18:07:34 +02:00
Jan Kahmen	aac6fcfa59	fix: Visual Selector renders scraped selectors as text, not markup (#4282)	2026-08-04 09:11:33 +02:00
dgtlmoon	71d332d5a0	UI full refactor / upgrade (#4183)	2026-07-16 15:08:29 +02:00
dgtlmoon	4a1c1ad78d	[i18n] JavaScript UI strings not covered by translations #4233 (#4255)	2026-07-13 10:44:14 +02:00
dgtlmoon	43bb196aa4	UI - Preview problem fix for extract_text/ignore_text #4138 (#4169)	2026-05-20 13:57:17 +02:00
dgtlmoon	00d26e3656	UI - LLM - SSRF guard for the LLM api_base setting (#4157)	2026-05-19 11:05:02 +02:00
dgtlmoon	866b442576	Security - Stored XSS via Tag Name in Modal Dialog	2026-04-27 16:36:28 +10:00
dgtlmoon	e9e8c8d218	LLM / AI Change detection rules and Summaries	2026-04-24 15:21:09 +02:00
dgtlmoon	37eac0aab4	Notifications - Discord #3721 - Dont use &nbsp; for discord (Actually Discord:// notifications should always use plaintext format anyway)	2026-04-11 09:25:44 +02:00
dgtlmoon	5f9fa15a6a	Realtime - Suppress socket.io errors in logs (#3991)	2026-03-19 18:02:07 +01:00
dgtlmoon	93630e188d	UI - Search modal - fixes for running in sub path	2026-02-18 10:27:12 +01:00
dgtlmoon	4b94de7e0c	UI - Browser Steps - First step was missing Clear / Remove / Pic buttons	2026-02-16 13:20:34 +01:00
dgtlmoon	fe465de73c	Browser Steps - Clean off empty fields on save/update (UI and API), small refactor Re #3874, #3879 (#3880)	2026-02-16 13:05:46 +01:00
dgtlmoon	6e90a0bbd1	UI - Bulk checkbox operations modal confirmation fix Re #3853	2026-02-11 06:29:59 +01:00
dgtlmoon	af193e8d7a	UI - Fixes for search dialog #3778 (#3781)	2026-01-19 16:18:23 +01:00
dgtlmoon	15f16455fc	UI - Show queue size above watch table in realtime	2026-01-15 17:28:09 +01:00
dgtlmoon	3d14df6a11	Development branch merge into release/master ... Multi-language / Translations Support (#3696) - Complete internationalization system implemented - Support for 7 languages: Czech (cs), German (de), French (fr), Italian (it), Korean (ko), Chinese Simplified (zh), Chinese Traditional (zh_TW) - Language selector with localized flags and theming - Flash message translations - Multiple translation fixes and improvements across all languages - Language setting preserved across redirects Pluggable Content Fetchers (#3653) - New architecture for extensible content fetcher system - Allows custom fetcher implementations Image / Screenshot Comparison Processor (#3680) - New processor for visual change detection (disabled for this release) - Supporting CSS/JS infrastructure added UI Improvements Design & Layout - Auto-generated tag color schemes - Simplified login form styling - Removed hard-coded CSS, moved to SCSS variables - Tag UI cleanup and improvements - Automatic tab wrapper functionality - Menu refactoring for better organization - Cleanup of offset settings - Hide sticky tabs on narrow viewports - Improved responsive layout (#3702) User Experience - Modal alerts/confirmations on delete/clear operations (#3693, #3598, #3382) - Auto-add https:// to URLs in quickwatch form if not present - Better redirect handling on login (#3699) - 'Recheck all' now returns to correct group/tag (#3673) - Language set redirect keeps hash fragment - More friendly human-readable text throughout UI Performance & Reliability Scheduler & Processing - Soft delays instead of blocking time.sleep() calls (#3710) - More resilient handling of same UUID being processed (#3700) - Better Puppeteer timeout handling - Improved Puppeteer shutdown/cleanup (#3692) - Requests cleanup now properly async History & Rendering - Faster server-side "difference" rendering on History page (#3442) - Show ignored/triggered rows in history - API: Retry watch data if watch dict changed (more reliable) API Improvements - Watch get endpoint: retry mechanism for changed watch data - WatchHistoryDiff API endpoint includes extra format args (#3703) Testing Improvements - Replace time.sleep with wait_for_notification_endpoint_output (#3716) - Test for mode switching (#3701) - Test for #3720 added (#3725) - Extract-text difference test fixes - Improved dev workflow Bug Fixes - Notification error text output (#3672, #3669, #3280) - HTML validation fixes (#3704) - Template discovery path fixes - Notification debug log now uses system locale for dates/times - Puppeteer spelling mistake in log output - Recalculation on anchor change - Queue bubble update disabled temporarily Dependency Updates - beautifulsoup4 updated (#3724) - psutil 7.1.0 → 7.2.1 (#3723) - python-engineio ~=4.12.3 → ~=4.13.0 (#3707) - python-socketio ~=5.14.3 → ~=5.16.0 (#3706) - flask-socketio ~=5.5.1 → ~=5.6.0 (#3691) - brotli ~=1.1 → ~=1.2 (#3687) - lxml updated (#3590) - pytest ~=7.2 → ~=9.0 (#3676) - jsonschema ~=4.0 → ~=4.25 (#3618) - pluggy ~=1.5 → ~=1.6 (#3616) - cryptography 44.0.1 → 46.0.3 (security) (#3589) Documentation - README updated with viewport size setup information Development Infrastructure - Dev container only built on dev branch - Improved dev workflow tooling	2026-01-12 17:50:53 +01:00
dgtlmoon	431fd168a1	Fixes to notification 'Send test notification' (#3571)	2025-10-28 22:06:39 +01:00
dgtlmoon	46658a85d6	UI - Fix watch table striping on delete #3523	2025-10-23 13:18:16 +02:00
dgtlmoon	64350a2e78	Replace jinja2-time with arrow and improve timedate timezone integration, fixes timezones in templates such as {% now 'Europe/London', '%Y-%m-%d' %} etc (#3496)	2025-10-13 11:52:02 +02:00
dgtlmoon	a95aa67aef	UI - Re #3393 #3419 Implementation of unread counter tab along with realtime updates (#3433)	2025-09-18 11:14:26 +02:00
dgtlmoon	9db7fb83eb	Always extract page <title>, {{watch_title}} added to notification body tokens (#3415)	2025-09-10 14:52:41 +02:00
Jeff Hedlund	8a07459e43	UI - Added "unread" view filter (#3393)	2025-09-06 11:47:57 +02:00
dgtlmoon	55cdcfe3ea	UI - Favicons - Realtime mode - Fixing small bug when favicon needed updating in realtime	2025-07-09 16:41:32 +02:00
dgtlmoon	2f7520a6c5	UI - Favicons in realtime update mode, update after favicon was written to disk only.	2025-07-09 15:47:30 +02:00
dgtlmoon	308f30b2e8	UI - Adding Favicon support to watch overview lister page + FavIcon API (#3196)	2025-07-09 15:16:22 +02:00
dgtlmoon	9beda3911d	Realtime UI - Prefer websocket then fallback to 'polling' mode, increase reconnecting retries.	2025-06-11 13:30:51 +02:00
dgtlmoon	99ca8787ab	UI - Always unset 'unviewed' state when '[History]' button is pressed from watch overview list #3243	2025-06-11 12:12:48 +02:00
dgtlmoon	66bc7fbc04	Realtime UI - Delete watch should update in realtime ( #3255 )	2025-06-11 11:23:05 +02:00
dgtlmoon	79d9a8ca28	Realtime UI - Ability to notify browser/client if there was a notification event (#3235)	2025-06-04 12:03:11 +02:00
dgtlmoon	5c391fbcad	UI - Realtime - Add realtime warning to page if server goes offline	2025-06-04 10:46:32 +02:00
dgtlmoon	d7173bb96e	UI - Adding missing icons lib	2025-06-03 16:13:16 +02:00
dgtlmoon	7f0c19c61c	UI - Also uncheck 'check all' checkbox for group operations in realtime mode	2025-06-03 14:56:31 +02:00
dgtlmoon	30e84f1030	UI - Real time - checkbox operations now realtime without reload	2025-06-03 14:54:13 +02:00
dgtlmoon	08728d7d03	UI - Realtime - Fixing 'last_changed' status re #3224	2025-06-03 10:44:15 +02:00
dgtlmoon	73f3beda00	Realtime UI - Socketio tweaks and refactor (#3220)	2025-06-03 10:17:19 +02:00
dgtlmoon	26833781a7	UI - Remove incorrect error text	2025-05-26 21:25:15 +02:00
dgtlmoon	0f65178190	Realtime UI updates via WebSocket (#3183)	2025-05-26 20:12:32 +02:00
dgtlmoon	a75f57de43	Browser Steps - <Select> by Option Text - #1224, #1228 (#3138)	2025-04-22 14:33:35 +02:00