Using KendoReact DropDownList into ReactBootstrap Modal - javascript

when I use a KendoReact DropDownList into a ReactBootstrap Modal the expanded list appears UNDER the modal so it can't be interacted with.
I read several issues that was pointing to a focus loss, which is not exactly my case, due to the fact that Kendo PopUp was append to body instead of the Modal itself, and the 'appendTo' prop seems to be a good solution for me but it exists only for the Kendo PopUp component, not for the Kendo DropDownList one (which uses PopUp underlying)...
I've made a repo illustrating this issue : https://github.com/lePioo/react_kendo_dropdown_into_bootstrap_modal
And a LIVE demo for this repo (take some time to load):https://react-kendo-dropdown-into-boot.herokuapp.com/

Set bigger z-index for the animation container of the popup using CSS. And it will be on top of the modal to resolve it.
.k-animation-container{
z-index: 10000
}
Leave it to be rendered into the document. Since if you render it using appendTo to the Modal, the DropdDown will not be entirely visible when opened, or scrollbar will appear in your dialog. This is the purpose it is rendered into the document.

#Xizario's answer didn't work with V4.14.x
The solution that finally worked was to use ZIndexContext.Provider from '#progress/kendo-react-common':
<ZIndexContext.Provider value={10003}>
<DropDownList {...yourProps} />
</ZIndexContext.Provider

Related

ant design background scroll overflow hidden not working properly

i have use antd 4.6.1 in my react project, here i use antd modal, drawer, select, drop down and more here if i open any one of mentioned things, like now i open modal, modal is opened, modal scroll is working, with the modal scroll, body scroll also working just like that all kind of element reacting, by default if any of modal, drawer or select opened, in body overflow hidden property not added that's why it's happening, i don't know why it's occurred,
i have search lot, https://github.com/ant-design/ant-design/issues/21539 here they said to need to add overflow hidden property manually when those all open and remove it when those closed using normal javascript code, this is actually not a best solution for this situation,
so kindly assist me, how do i resolve this issue, Hope here i can get better solution
Helping hands are appreciable,

CKEditor 4 having problem when used in Material UI dialog

I am working on a React project where I have used CKEditor 4 on Material UI dialog. When I am trying to use advance options like Math. I am not able to type in, anything on input, textarea fields. I have searched for solutions but all the solutions are with respect to Bootstrap Modal. If anyone has faced the same issue using the Material UI dialog. It will be a great help if you can share the solution.
Solution for Bootstrap Modal: http://stackoverflow.com/a/18554395/778587
Material UI dialog: https://material-ui.com/demos/dialogs/
Attaching the Screenshot for the reference.
Steps to reproduce the issue. - Open https://codesandbox.io/s/vv50789765 for code example
Step 1: Open CKEditor and click on the picture icon highlighted in the screenshot.
Step 2: Once you click on the picture icon another popover will be opened with some input form elements. None of the input form elements is editable, I am not able to type anything in the form elements. Please refer the screenshot.
One of the Modal props is disableEnforceFocus:
If true, the modal will not prevent focus from leaving the modal while open.
Generally this should never be set to true as it makes the modal less accessible to assistive technologies, like screen readers.
Without this property set, every time you try to change focus to one of the input fields in the ckeditor image dialog, the Material-UI Dialog (which uses Modal) automatically brings focus back to itself.
Here's a version of the sandbox with disableEnforceFocus specified which then works:
https://codesandbox.io/s/80pu0

Switchery rendered wrong when triggering click after View is shown

I am using switchery for my app checkboxes. In my code when a user opened a modal view, I read the saved checkbox state and update the checkboxes accordanly using
$('.switchery:nth(3)').click();
So in the line above, the forth checkbox is toggled depends whether the saved state is true or false. This works without a problem.
The problem is that when I triggered the click dynamically after the view is shown, the rounded part of the switch appears at the right side of its container, instead at the inner right part as it should be.
When I clicked the switchery switch one the screen, it shows it correctly. Only when I run a code to toggle it after the view is shown, it shows incorrectly.
Looking at the CSS, I see that the <small> elements (the one that responsible to render the rounded element) has left: 50px; which causes it to render outside the switch boundaries (should be less). I think that the plugin calculated something wrong, but I have no idea how to solve it.
The switch rendres inside a phonegap app in KendoUI mobile view. It is wrapped around an li element
Open switchery.js and replace jack.offsetWidth by 30 in Switchery.prototype.setPosition function.
This worked for me.

qTip with jQuery dialogs

I'm using qTip to show validation errors in a grid. The tooltip appears after a failed row save and doesn't disappear until the row is resaved or the changes are canceled.
The problem with this is that opening a dialog while the tooltip is visible causes the tooltip to be rendered on top of the dialog. That is because the z-index is hard-coded to 6000+ for all tooltips, while jQuery dialogs are set to 1000+.
I could fix this problem by changing the hard-coded value in qTip to <1000, but then tooltips fired from the dialog will appear behind the dialog.
Is there anything I can do, aside from changing the qTip code or using a different tooltip library?
Completely untested, but you might be able to put something together like this:
Hack the base qTip z-index so the tips will appear below the jQuery dialogs.
Use the qTip onRender callback to selectively raise the z-index of tips triggered only from within those dialogs so they are above the 1000 range.
As a side note, it looks like the current version of qTip actually uses 15000 as its base z-index.
Why not make the dialog's z-index 6500, and then give all qTips fired from the dialog a z-index of 7000?
Edit: Oh, you still can't set qTip's z-index on a per-tooltip basis. Rats. Perhaps hide all the existing tooltips when the dialog is shown, and re-show them when it closes?

Trouble having a modal dialog to open a secondary dialog

I have a modal dialog form which has some "help links" within it which should open other non-modal panels or dialogs on top of it (while keeping the main dialog otherwise modal).
However, these always end up behind the mask. YUI seems to be recognizing the highest z-index out there and setting the mask and modal dialog to be higher than that.
If i wait to panel-ize the help content, then i can set those to have a higher z-index. So far, so good. The problem then is that fields within the secondary, non-modal dialogs are unfocusable. The modal dialog beneath them seems to somehow be preventing the focus from going to anything not in the initial, modal dialog.
It would also be acceptable if i could do this "dialog group modality" with jQuery, if YUI simply won't allow this.
Help!
By default, YUI manages the z-index of anything that extends YAHOO.widget.Overlay and uses an overlay panel. It does this through the YAHOO.widget.Overlay's "bringToTop" method. You can turn this off by simply changing the "bringToTop" method to be an empty function:
YAHOO.widget.Overlay.prototype.bringToTop = function() { };
That code would turn it off for good and you could just put this at the bottom of the container.js file. I find that approach to be a little bit too much of a sledge hammer approach, so we extend the YUI classes and after calling "super.constuctor" write:
this.bringToTop = function() { };
If you do this, you are essentially telling YUI that you will manage the z-indices of your elements yourself. That's probably fine, but something to consider before doing it.
The original dialog can't be modal if the user is supposed to interact with other elements—that's the definition of modal. Does the original dialog really need to be modal at all? If so, have you tried toggling the modal property of the original dialog before you open the other elements?

Categories