Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't add 'open in new tab' directly and need to click edit first #15503

Closed
jeroenrotty opened this issue May 8, 2019 · 1 comment · Fixed by #15573
Closed

Can't add 'open in new tab' directly and need to click edit first #15503

jeroenrotty opened this issue May 8, 2019 · 1 comment · Fixed by #15573
Labels
[Priority] High Used to indicate top priority items that need quick attention [Type] Bug An existing feature does not function as intended

Comments

@jeroenrotty
Copy link

jeroenrotty commented May 8, 2019

Describe the bug
There is bug when you want to add 'open in new tab' directly from the dropdown, you can't enable the option. You first have to click edit and then you open up the extra dropdown function and it works.
EDIT: Additionally, I'm having a hard time to actually save the option when enabled. You can't click away cause that would not make it save...

To reproduce
Steps to reproduce the behavior:

  1. Create a link in a post.
  2. Save the post
  3. Try to change the 'open in new tab' function directly with the dropdown function.
  4. You can see it won't work.

Expected behavior
You can add the 'open in new tab' directly without interfering with the URL behind it.

Desktop (please complete the following information):

  • OS: [e.g. iOS] Mac OS X latest stable
  • Browser [e.g. chrome, safari] Chrome

Additional context

  • Experienced this while editing a page on a Rosetta site.
@youknowriad youknowriad added [Type] Bug An existing feature does not function as intended [Priority] High Used to indicate top priority items that need quick attention labels May 10, 2019
@aduth
Copy link
Member

aduth commented May 10, 2019

It's quite likely this and #15522 are of the same underlying cause.

As a result of initial debugging and checking out commits before/after the change, I believe this may have been a regression introduced in #14411 (5d6527d, cc @ellatrix).

Specifically, I observe that the activeFormats internal to RichText component are not updated when the button is pressed, but the change is otherwise applied (source). Thus, when the link format is rendered, its activeAttributes do not reflect the change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Priority] High Used to indicate top priority items that need quick attention [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants