21

It appears that the recent UI change for the close vote review dialog introduced a bug when it concerns suggested dupes.

Reproducing in Firefox 78.0.1 (Mac OS). In this dialog there are two tabs, "Question" that shows the question to be closed, and "Duplicate" that shows the suggested duplicate. When the latter tab is active, the "Close" button produces no action though it is not disabled.

enter image description here

Only when on the "Question" tab can you successfully vote to close the question.

enter image description here


There seems to be an uncaught exception raised by JQuery, when called from review.en.js:

SyntaxError: Document.querySelectorAll: '.close-question-link[data-questionid=63380604]' is not a valid selector

Looks like the original question ID may be lost when switching to the "Duplicate" tab.

2
  • 6
    Reproduced on Chrome version 84.0.4147.125 (64 bit). Spam-clicking the Close button with the Duplicate tab selected yields the "You can only load the close dialog every (x) seconds." error message, which indicates that Stack Exchange thinks the close dialog was correctly opened, I suppose.
    – Spevacus
    Aug 12, 2020 at 15:55
  • Cross-site report on MSO: Close popup in review doesn't show after switching to Duplicate tab. Aug 23, 2020 at 15:03

2 Answers 2

4

This is fixed by an accident of design.

One design requirement for the new review queues UX is to hide the task actions when you aren't looking at the review task's post.

This means, when you're looking at a Duplicate you can't not get a popup when clicking "Close" because there's no "Close" button to click. This may not be the solution anyone was expecting, but it is certainly solved.

If the UX ever changes back here, the issue will need to be resolved differently. The root cause is that the close and flag popups are hosted within an element adjacent to the menu element that actual close button. When the menu is hidden, by way of the question being hidden, the dialog ends up being hosted in an invisible element.

Two conceivable solutions to the problem, should it arise again, would be:

  1. moving to a redesigned modern modal for flagging/closure. This is something that hasn't yet made it to the roadmap because it's a technically complex set of popups.
  2. moving the popup container outside of the post, possibly at the document level, like we do for our Stacks modals. This has some tradeoffs in that our legacy popup has little to no accessibility considerations compared to the modern one, and placing it so close in the DOM mitigates those issues by making it possible to quickly tab/advance into them. Moving it further away would necessitate baking additional features into that UI.
3
  • 1
    No idea what "status-" tag would be right for this one. Mar 2, 2021 at 0:09
  • I think the current completed tag makes sense. The bug became a non-issue as the feature it was related to was removed. That said, this used to work in the past. What changed that caused it to stop working? Mar 2, 2021 at 0:44
  • 1
    Although I (sort of) understand the technical reason, I was hoping that the new review queues would actually solve this bug by improving the UX - i.e., my preferred workflow is 1. look at question in the queue 2. look at the proposed duplicate 3. if I agree with the duplicate press 'close'. Now there is (still) another step in between where I need to return to the question before being able to close. So please keep it on the roadmap somewhere to save us poor users millions of extra clicks :)
    – Marijn
    Mar 2, 2021 at 6:53
3

We'll take a look at this as part of the review queue visual overhaul currently in progress and make sure things are working as intended. Thanks for the report!

We'll post an update here once that's done.

3
  • Great. Though taking six months to acknowledge the problem would lead to some fun performance review questions where I work...
    – mustaccio
    Feb 20, 2021 at 0:22
  • In the past SE used to have a developer work once in a while on fixing bugs not related to any roadmaps or bigger projects, just simply.... fix a bug. Did this policy come to an end, and you now fix bugs which are only part of something bigger, and reject all other bugs? (Just curious) Feb 20, 2021 at 16:13
  • 2
    @ShadowWizardisVaccinating That still exists. In general, don't think of every developer who works here as someone who works on public Q&A. The team that does has six devs, two at a reduced capacity (tech lead duties take up some of my time, community advocacy takes up some of Yaakov's). We have a bug duty rotation, but what we target still has to be triaged and prioritized. Proximity to current (or recent) projects and the severity of overall impact are two of the things we look at. For this bug, we have a project on the go in the same area, so it makes sense to fix it while we're at it.
    – Adam Lear StaffMod
    Feb 20, 2021 at 22:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .