Reviewing changes
Every screen is approved, unreviewed, or reported as a bug. Decide which, see exactly what moved, and file it where your team works.
When a picture differs from its baseline, Visual stops and waits for a person. That is deliberate: an automatic decision is indistinguishable from not checking.
Three states, and only three
A screen is always in exactly one of them.
| State | Colour | Meaning |
|---|---|---|
| Approved | Green | Someone looked and said this is correct. It is the baseline now. |
| Unreviewed | Yellow | It changed, and nobody has decided yet. |
| Reported as a bug | Red | Someone looked and said this is wrong. |
There is no "rejected", no "pending", no "ignored". A change either becomes the new normal, waits for someone, or is a bug.
You can change your mind. Change status on any screen moves it to either of the states it is not currently in, and the move is recorded in the screen's history.
Deciding
Open Visual → Builds and click any build to see its screens, or go straight to Visual → Review to see everything waiting.
For a screen that changed, you get the approved version and the new one side by side, with the difference marked. Then:
Approve — the change is correct. This new picture becomes the baseline, and future runs are compared against it.
Report a bug — the change is wrong. The screen goes red, and you can file it straight into your team's tracker with the screenshot attached. See below.
Approving is how a baseline moves. Until someone approves, every later run keeps comparing against the old picture and keeps reporting the same difference — which is what you want, but it means a screen left unreviewed will keep shouting.
Seeing the difference
The comparison is pixel by pixel, against a threshold you set per project. Anti-aliasing and small rendering wobble are already tolerated.
Three things you can do when a difference is real but uninteresting:
- Draw an ignore region over the part that always changes — a clock, a carousel, a live counter. Anything inside the box stops counting, for that screen only.
- Raise the project threshold, in Visual → Settings, for pages that never render identically twice. This makes the whole project blinder, so try ignore regions first.
- Approve it, if the change is simply correct.
History
Every screen keeps its history: when it was captured, what happened, and who decided. New baselines, approvals, bug reports and status changes all appear.
Click any row to see the two pictures as they were at that moment — the baseline it was compared against then, not the one it would be compared against today. It is the answer to "when did this screen start looking like this, and who said it was fine".
Filing a bug
Report a bug can create a real ticket in your team's tracker, with the screenshot attached and the browser, operating system and screen size filled in.
Connect a tracker once, at organisation level, under Organization → Integrations → Defects. After that the button is available everywhere a bug can be reported, including here.
GitHub has no attachment API, so issues filed there carry the details but not the picture. Everywhere else the screenshot is attached.
Deleting a screen
Delete screen removes the screen, its baseline, its history and its stored pictures. It cannot be undone, and the next capture with that name starts a fresh baseline.
Use it when a screen is genuinely gone — a page you have retired, or a name you captured by mistake. Do not use it to "reset" a screen you are simply unhappy with; approving the current picture does that without losing the history.