The issue is still present on desktop and mobile - checked in wmf.19 On mobile the issue might prevent a user to read an article.
There is a similar issue - T342465: [mobile] Add link drawer cannot be minimized after a user interacts with drawer's controls , the similarity is that the drawer's minimizing/close controls are not responsive to users' clicks.

@Etonkovidova I just tested on https://test.wikipedia.org/ and I can't replicate this using Chrome on desktop. Is it only an issue on mobile or certain browsers?

I noticed a different issue: when I complete an "add a link" edit, I don't receive a post edit dialog at all. Is that a quirk of test wiki, or a new bug?

In T336717#9072536, @KStoller-WMF wrote:

@Etonkovidova I just tested on https://test.wikipedia.org/ and I can't replicate this using Chrome on desktop. Is it only an issue on mobile or certain browsers?

Thank you, @Kirsten for testing! The issue turned out to be tricky to reproduce consistently. I re-checked the issue on testwiki wmf.20 - the issue is not 100% reproducible, but in the majority of cases the issue looks as the following

• when the green banner is present, the minimizing chevron is not responsive
• initially it requires two clicks to minimize the post-edit dialog.
• the first click on the close button will outline it, and the second click on the clickable area will close the post-edit dialog.

• if only one click on the close button ('x' button) is done, and then a user clicks on the clickable area (including the chevron button), the post-edit dialog will be closed.

Also checked (just in case) T342465: [mobile] Add link drawer cannot be minimized after a user interacts with drawer's controls - the issue is still present.

I noticed a different issue: when I complete an "add a link" edit, I don't receive a post edit dialog at all. Is that a quirk of test wiki, or a new bug?

I checked on testwiki in different browsers and on mobile - the post-edit dialog was always present. The only possible scenario for the post-edit dialog not to appear, it's when the level-up dialog fails to appear. I'll check it today.

Thanks, Elena! OK, hopefully an engineer can replicate and track down the underlying issue!

And hopefully the issue I noticed was just a edge case quirk. I'll see if I can replicate it again.

@Sgs - to summarize what behavior I observe ( testwiki wmf.20 on Chrome or FF). Let's compare with the Help dialog behavior:

• click on a suggested edit task
• a page opens with Help panel open
• if 'x' (close button) is clicked - the panel closes
• publish an edit. The post-edit dialog and the green banner appear:
  • when the green banner is present, the post-edit dialog is not responsive when clicked (a double-click works)
  • one click on the collapse button won't do anything; clicking again (or a double-click) will collapse the post-edit dialog
  • in a collapsed state, clicking on 'x` won't dismiss the dialog, only a second click will close

Below are gifs to illustrate that double (or more) clicks:

@Etonkovidova thank you for the detailed steps, I must be missing something because I'm still failing to see this behavior in testwiki. Without knowing yet what is affecting our different results, there are chances the same issue is preventing me to reproduce T342465, more details in T342465#9081167.

In T336717#9081169, @Sgs wrote:

@Etonkovidova thank you for the detailed steps, I must be missing something because I'm still failing to see this behavior in testwiki. Without knowing yet what is affecting our different results, there are chances the same issue is preventing me to reproduce T342465, more details in T342465#9081167.

I did some more testing

• checked my Mac OS in case there are some clicking settings options that might interfere with normal clicking behavior. There are no such settings except Accessibility settings for Pointer control which is set to default.
• checked on a Windows machine - the issue is not present
• checked again on Mac OS in different browsers (FF, Chrome, and Safari) - the issue is present on desktop and mobile.

The workaround exists - repetitive clicks will result in an action (co lapsing/un-collapsing or closing the drawer). Since there are some problems with reproducing the issue, and there are no user complaints so far, I'm moving the task to Blocked .

@Etonkovidova I tried to reproduce again with no luck :/. I might be missing something obvious, I suggest we jump into a quick sharing screen sync session, next week. Ty!