Page MenuHomePhabricator

"Advanced" option stays open unless you close it from both Reply modes
Closed, ResolvedPublic

Description

Steps to reproduce:

  1. Open the Reply tool.
  2. Open the Advanced option.
  3. Switch to the other Reply mode (for example: Source mode).
  4. Click on "Cancel" to close the Reply tool.
  5. Open the Reply tool again.

Observe that the Advanced option is still open inside the Reply tool source mode. I think it should not.

Now do the following:

  1. Close the Advanced option.
  2. Close the Reply tool.
  3. Open the Reply tool again.

Observe that, the Advanced option is still open even though you closed it in your previous session.

Now do the following:

  1. Close the Advanced option.
  2. Switch to the other Reply mode.
  3. Now close the Reply tool.
  4. Open the Reply tool.

Observed that, this time the "Advanced" option has remained closed.

Browser: Chrome

Wiki: English

Environment: Beta cluster

Page: https://en.wikipedia.beta.wmflabs.org/wiki/User_talk:RYasmeen_(WMF)/sandbox

Event Timeline

Change 628926 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/DiscussionTools@master] Collapse advanced drawer when clearing

https://gerrit.wikimedia.org/r/628926

Change 628926 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Collapse advanced drawer when clearing

https://gerrit.wikimedia.org/r/628926

@matmarex/@Esanders: I checked this on Patch Demo, this seems to be not fixed.

Change 630217 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/DiscussionTools@master] ReplyWidget: Pass initial config values to #setup, not to constructor

https://gerrit.wikimedia.org/r/630217

Change 630217 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] ReplyWidget: Pass initial config values to #setup, not to constructor

https://gerrit.wikimedia.org/r/630217

@Ryasmeen Thanks for spotting this, it should be really fixed now.

@Ryasmeen Thanks for spotting this, it should be really fixed now.

This works as is described in the task; however, @Esanders, will it conflict with what we are planning to implement in T261539?

No, I don't see why it would conflict.