-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
fix(b-modal): handle enforce focus case where tinyMCE editor inside modal (fixes #4537) #4538
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
Conversation
Codecov Report
@@ Coverage Diff @@
## dev #4538 +/- ##
==========================================
+ Coverage 99.92% 99.92% +<.01%
==========================================
Files 251 251
Lines 5220 5224 +4
Branches 1381 1385 +4
==========================================
+ Hits 5216 5220 +4
Misses 3 3
Partials 1 1
Continue to review full report at Codecov.
|
@tmorehouse Not sure if we should add something that only effects a fraction of users that are using tinyMCE. |
@jackmu95 yeah... it is mainly an issue with embedded Although there is a way to get TinyMCE to not use an |
Maybe we can consider add a hook to let developer decide how to stop the focus event, otherwise it has no any way to stop this event now. |
@asika32764 You can set the prop |
Seems works for my project. Can this prop caused any side-effects? |
@asika32764 the downside is that if you press tab several times, then the focus will move to an element behind the modal, which can make it hard for keyboard only users to get back into the modal. And other option you could try is to put the editor inside a DIV that prevents bubbling of the focusin/out events (so that they do not reach the focus management listener in the modal): <b-modal .... >
<div @focusin.stop @focusout.stop>
<!-- place MCE editor component here -->
</div>
</b-modal> |
Closed in favor of #4702. |
Describe the PR
Handle enforce focus case when tinyMCE editor is inside a modal.
fixes #4537
PR checklist
What kind of change does this PR introduce? (check at least one)
Does this PR introduce a breaking change? (check one)
The PR fulfills these requirements:
dev
branch, not themaster
branch[...] (fixes #xxx[,#xxx])
, where "xxx" is the issue number)fix(alert): not alerting during SSR render
,docs(badge): update pill examples
,chore(docs): fix typo in README
, etc). This is very important, as theCHANGELOG
is generated from these messages.If new features/enhancement/fixes are added or changed:
package.json
for slot and event changes)If adding a new feature, or changing the functionality of an existing feature, the PR's
description above includes: