Skip to content

[2.x] fix(approval): scope the unapproved fade to text, not the whole post#4836

Open
karl-bullock wants to merge 1 commit into
flarum:2.xfrom
karl-bullock:fix/approval-unapproved-opacity
Open

[2.x] fix(approval): scope the unapproved fade to text, not the whole post#4836
karl-bullock wants to merge 1 commit into
flarum:2.xfrom
karl-bullock:fix/approval-unapproved-opacity

Conversation

@karl-bullock

Copy link
Copy Markdown
Contributor

.Post--unapproved puts opacity: 0.5 on the whole <article>, which gives the post its own stacking context. Everything that pops out of the post is then stuck inside it. The controls dropdown, the post-meta modal and the user card all render at half opacity, and anything that follows the post in the stream paints over them. The practical effect is that the controls menu on a pending post can't be clicked, because the clicks land on the post underneath.

To reproduce, with Approval enabled:

  1. Post a reply, then set is_approved = 0 on its row in the posts table
  2. Make sure there is another post after it in the stream
  3. Open the controls menu on the pending post

This is the same bug #4453 dealt with, moved rather than removed. Before that PR the opacity sat on .Post-header, which trapped the user card. Moving it up to the article freed the card, but pulled .Post-actions into the fade for the first time. The wider version of this has been open as flarum/issue-archive#328 since 2016, with #950 and #3031 closed as duplicates of it, and #4212 closed by #4453.

The change here does what core already does for .Post--hidden: mute the header with color and fade only the children that hold text, so nothing that pops out of the post ends up inside a stacking context.

Worth flagging that this does change how a pending post looks. The avatar, Reply and Like go back to full strength, because .Post--hidden fades neither .Post-actions nor the avatar. The post still reads as pending from the muted header and the "Awaiting approval" label. If uniform greying matters more, say so and I'll look again, but those elements are the ones that have to stay outside the fade for the popups to behave.

Checked on 2.0.0-rc.5 and 1.8.17, in Chromium and Firefox, against a comment post, a discussion's opening post, and an unapproved event post. All three popups go from half opacity to full in every case.

1.x has the same root cause but breaks differently. The controls menu is fine there, and it's the user card and post-meta modal that suffer. The equivalent change fixes it, so I'm happy to open a 1.x PR if that's wanted.

Fixes #4505

Putting opacity on `.Post--unapproved` itself gives the whole `<article>` a
stacking context, so every popup inside the post is trapped in it: the controls
dropdown, the post-meta modal and the user card all render at 50% and get
painted over by whatever follows the post in the stream. On a moderated forum
that makes the controls menu unclickable, since the clicks land on the post
underneath.

This is the same problem flarum#4453 fixed for the user card, just moved. Before that
change the opacity sat on `.Post-header`, which trapped the card; moving it up
to the article freed the card but swept `.Post-actions` into the fade for the
first time.

Follow what core already does for `.Post--hidden`: mute the header with `color`
and fade only the text-bearing children, so nothing above the post body ends up
inside a stacking context.

Fixes flarum#4505
@karl-bullock
karl-bullock requested a review from a team as a code owner July 25, 2026 00:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[2.x] Flagged posts cannot be edited.

1 participant