When the system default skin is not Elastic and user authentication fails, the skin will be reset to the system default. It is because of rcmail::$default_skin and what we do with it in kill_session().
The plugin MUST be put first on the plugins list otherwise the skin will be set too late and other plugins will use system/user skin instead. E.g. enable Archive plugin before elastic4mobile to see the problem.
$rcmail->output->set_env('skin', $skin); in the code is redundant, because set_skin() will do this.
I encountered these issues in my pwa plugin I'm working on. It also forces elastic skin in pwa mode similar to your plugin.
Maybe we could somehow improve core code to handle issue 1. and 2. more nicely. Something in plugin api that would allow to execute some code before plugin init? Also, rethink that rcmail::$default_skin.
rcmail::$default_skinand what we do with it inkill_session().$rcmail->output->set_env('skin', $skin);in the code is redundant, becauseset_skin()will do this.I encountered these issues in my pwa plugin I'm working on. It also forces elastic skin in pwa mode similar to your plugin.
Maybe we could somehow improve core code to handle issue 1. and 2. more nicely. Something in plugin api that would allow to execute some code before plugin init? Also, rethink that
rcmail::$default_skin.