Introduce non-blocking version of RunMoveLoop |
||
Issue descriptionOn some platforms like ChromeOS, window-move is not blocking at all, but the API of views::Widget is blocking -- so a RunLoop is involved internally to achieve this mechanism. This type of nested message loop potentially causes unexpected behaviors and causes weird errors. Maybe we can just have a non-blocking version of this feature when the platform allows it. This can be beneficial to Mash, we could reuse the same window move for Mash window frame.
,
Nov 11
The reason we went with a nested message loop is consistency with windows. If we offer two variants (one nested, one not) it means client code has to deal with both. This makes client code more complex than if it can assume the same implementation always. I'm inclined not to do this.
,
Dec 18
As far as I checked, only Windows requires this blocking interface while other platforms use RunLoop to emulate the blocking. It may be worthwhile to provide an #ifdef. Anyways, this is not an urgent task, let's discuss later when we have time. |
||
►
Sign in to add a comment |
||
Comment 1 by mukai@chromium.org
, Nov 9