I have tested this item ? unsuccessfully on f66c516

Applied Patch but Modal still trapped. Test on "Article > Version" and "Article > Preview".

@franz-wohlkoenig you cannot just use patchtester for this as it is an scss file and i have not committed the css as I wrote in the pr. You will need to run the buildcss script

I have not tested this item.

@franz-wohlkoenig Please see docs

@wojsmol thanks for Link. To be honest: Patchtester is my Limit.

I am only committing the scss as I assume we no longer commit the compiled assets

Rather hard on the testers isn't it?

As far as I am aware that is the way forward - not that I agree.

@C-Lodder till someone fixes https://github.com/joomla-projects/joomla-testing

PS wrong repo, I meant this: https://github.com/joomla-projects/gsoc17_pr_testing_platform

@franz-wohlkoenig do you use brew on your Mac?

@wojsmol i don't use brew (and i didn't know what it is until i searched after your Question :-).

Open notifications dropdown

To fix you can remove the z-index from the subhead but I suspect that will just pass the problem else where

grrrh - well I give up. Increasing the z-index on the modal-backdrop didnt work either

@ciar4n patchtester is more important than the dropdown

@ciar4n patchtester is more important than the dropdown

True. I'm just pointing out that these z-indexs are a house of cards once we start removing them. The modals will rely on them unless we move modal markup outside of the toolbar.

In other words... by loading the modal markup with the modal trigger (in this case a button in the toolbar), the modal will inherit the z-index of the triggers container (in this case the toolbar). It is for this reason that modal markup is usually moved to the root.

If I rightly remember, we had this discussion regarding modals when starting custom elements and ensured they were injected just before the closing body tag

Injecting the modal to just before the closing body tag would solve this issue.

I just want a fix so that testers can use the patch tester. Dimitris has said he is rewriting the modal stuff so the fix will only be temporary until then.

The fix is fine for now, at least for me.

PS just comment out the line instead of deleting it and add a // @todo restore when new modals merged

I have tested this item ✅ successfully on f66c516

As a temporary fix this is fine by me.

As the CSS is not been included with the PR, does this mean all style related PRs can not be tested with the patchtester?

When you don't have node/npm installed, then not as it needs a recompile 8f the assets. Perhaps parchtester should detect that in the future that a sass or js file has changed and a recompile is needed.

Patch tester is borderline unsuitable for the 4.0 environment with all the changes that have been made. If you are not using a git client and command line, there are really only two viable options:

1. The PR testing platform, if it is ever put online
2. Building installable packages for every PR (similar to what's done for #20800 but more generic) that can be put through Upload & Install in the update component, there's just no reliable rollback mechanism here (well, in theory you can rollback by re-installing either the tagged release package or nightly build you started from, but if there are database changes, you're out of luck)

@mbabker +1 for number 2 until number 1 is ready at let for PR's with js or scss changes.