weifangsun@/ yoshiki@ / yamaguchi@ -
I added an UMA stat, Apps.Window.Type (see link in previous comment). We are seeing a bit more usage of 'panel' than I would expect (around 2.5%), although only 17% of users are opening app windwos at all, and only .64% of users are opening panels.
I am wondering if this is primarily due to the audio player.
What do you think of explicitly changing the player to not use panels? That is probably a good idea anyway since we should explicitly position the window someplace reasonable in the absence of panels.
Beta channel histograms show 1.39% of app windows are panels which is still cinsiderably higher than I would expect.
I created a separate issue 800990 to track making the file manager audio player not use panels; this might be the primary reason for the usage?
I wonder if the stat will drop significantly in stable channel. I'm guessing many of our beta channel users are non-enterprise consumers, who might use the audio player more. We don't know until we look, though. :-)
(From chatting with calamity@ - in the past we've had machines that customers were using for automated tests, so a few machines would report the same UMA stat over and over. That doesn't see likely here, though, since the user count breakdown roughly matches the usage counts.)
Beta channel (67) is down to .46% of users and .26% of sessions. I think we can safely plan to deprecate panels in 68 and remove the code in 69.
I will put up a patch to turn panels off and plan to merge that to 68 unless there are objections.
Nice! To confirm, when removing support, the fallback will be to just open a normal window, is that correct? (said differently, this won't *totally* break for those users?)
That is correct (and is the current behavior on Windows). We log a message to the console and treat the window as a normal app window. Only the placement and docking will "break".
It was used to create floating no decorated window which IME keyboard needs to show things like suggestion, alt text. Not sure the current state thought as I didn't work on VK anymore.
+wuyingbing
+shuchen
Sorry, I forgot to mention that it also needs to be unfocusable. We don't want to steal focus from current input box when user choose a text from a popup window for example. I am not familiar with frameless window. Could it be unfocusable?
Is the panel window support for IMEs left over from when the system tray menu for "Show input options in the shelf" setting was going to be implemented with panels?
https://codereview.chromium.org/2563343002 and related CLs?
Rather than merging this to 68, I will wait until the start of M70 to remove the old panel code, so we will have a full release cycle with panels disabled.
The above CL still didn't remove/deprecate everything, see the cl description comment.
Feel free to pass this bug to me or someone else for the remaining cleanup.
Some more code should be deprecated/deleted after this CL. For instance:
views::Widget::InitParams::TYPE_PANEL
aura::client::WINDOW_TYPE_PANEL
ash::kPanelAttachedKey
ui::mojom::WindowManager::kPanelAttached_Property
extensions::LAUNCH_CONTAINER_PANEL
Comment 1 by steve...@chromium.org
, Nov 23 2017