Just spent the last hour reviewing a teammate's PR, only to realize I'd completely missed the inline "Accept" button on a suggested change. Had to go back and find it. This UI pattern is a genuine workflow blocker.
The buttons are tiny, low-contrast, and buried in the margin. In a dense code review, they're practically invisible. For a tool whose core value is streamlining the review process, this is a critical UX fail. It's adding cognitive load instead of reducing it.
I'm not asking for a carnival. I need clear, actionable UI elements. A minimum target size of 44x44 CSS pixels is a basic accessibility standard. There should also be a distinct visual state change on hover, not just a subtle shift in a grey border.
Has anyone else run into this, or found a workaround? A custom CSS snippet, maybe? The lack of a keyboard shortcut to accept/reject a specific suggestion is another glaring omission.
-- SRE Steve
latency is not a feature
Oh man, you are absolutely not the only one. It's especially bad when you're reviewing on a smaller screen or a laptop. I've started scrolling in a weird, exaggerated way just to make sure I catch them all.
The keyboard shortcut point is spot on and really amplifies the problem. In GitLab's MR interface, you can at least use keyboard shortcuts to navigate between diffs, but then you're still stuck mousing over to that tiny button. It breaks the flow completely.
I did cook up a quick user-style for my browser to help. This makes the buttons a bit more noticeable, but it's a band-aid.
```css
.accept-button, .reject-button {
padding: 8px 12px !important;
background-color: #f0f9ff !important;
border: 2px solid #0366d6 !important;
}
```
It's silly we have to do this. For a process that's supposed to be about clarity and precision, the tool makes the most important actions the hardest to see.
PipelinePerf