Fix for: Colordialog is incorrectly positioned when used with another dialog

[Dumluregn]

What is the purpose of this pull request?

Bug fix

Does your PR contain necessary tests?

All patches which change the editor code must include tests. You can always read more
on PR testing,
how to set the testing environment and
how to create tests
in the official CKEditor documentation.

This PR contains

• Unit tests
• Manual tests

What is the proposed changelog entry for this pull request?

[#3559](https://github.com/ckeditor/ckeditor4/issues/3559): Fix for: [Color Dialog](https://ckeditor.com/cke4/addon/colordialog) is incorrectly positioned when used with another dialog.

What changes did you make?

After the fix cell properties dialog is properly fading when color dialog is opened.

Closes #3559.

[jacekbogdanski]

Looks good, just some minor stuff.

[jacekbogdanski]

Would be nice to also add manual test for mobiles, as the regression which has been introduced here is caused by changes dedicated to mobiles. I think that if we change test steps with dev console, it should be possible to do it in the same test file, WDYT?

[Dumluregn]

Yup, should work 👍

[jacekbogdanski]

Only small issue with manual test. It looks like when you open it on some slow machine (e.g. you could check it on IE or Browser Stack mobiles) it may show dialogs in incorrect order once button clicked. It only occurs on the first clean page load and first button click, probably due some caching issue / asynchronous nature of commands.

The fix will probably require chaining commands to make sure that the previous finished or even replacing commands with editor.openDialog, as commands may also open dialogs asynchronously.

[Dumluregn]

I can fix it but I wonder if it's really an issue - more important than dialogs order is the fact that the one on top is accessible, when it's closed the second one becomes active etc. So maybe instead of messing around with commands we could change Expected to sth like "all dialogs close and activate properly" instead, WDYT?

[jacekbogdanski]

I have a feeling that order is important here, note that you actually update code around logic responsible for correct dialog order, which may be messed up if z-index is incorrectly updated (on the wrong element). I'm wondering if it won't be simpler to update the test with 3 buttons (all different dialogs) with some crazy high z-index so they are above dialog. Not sure how it will look/being accessible.

[Dumluregn]

The bug you noticed here has occured before, so I reported it in #3638 to handle it separately if we decide it's important. For now when you click the same button in test more than once it will fail the test, so I included a note to click each one only once.

[jacekbogdanski]

LGTM 👍