New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 646417 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Feb 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

Mus+Ash: We should probably clip windows to their parent's bounds by default

Project Member Reported by fsam...@chromium.org, Sep 13 2016

Issue description

Right now we don't do any clipping in the Mus window server. We should probably turn on clipping by default (except maybe for transient windows?) so that the child client area does not stick outside the bounds of the parent (eg Chrome renderer sticking outside the bounds of the Chrome window).
 
Labels: -Proj-Mustash-Chrome Proj-Mustash-Mus-WS Proj-Mustash-Milestone-Tadpole

Comment 2 by sky@chromium.org, Sep 13 2016

I don't believe we clip by default with aura::Windows (or rather ui::Layer). But we may want to for embedded windows, such as renderers.
Labels: Proj-Mustash-Mus-GPU
Mus-gpu needs a way to clip an oopif to the clip prop tree provided by the embedder. I think we could reuse this mechanism for clip if the ws generated such a clip prop tree?

BTW: how do popups currently work? i.e. if an oopif has a combo box? Does it ask the browser to make the unclipped window for the combo-box.

Comment 4 by sky@chromium.org, Sep 15 2016

I suspect the browser ends up handling popups so that they aren't clipped by frames. I'm not positive though.
Components: MUS
Components: Internals>MUS
Once we complete surface ID propagation, clipping will happen in the parent client.
Status: Available (was: Untriaged)
Status: WontFix (was: Available)
Now that we do surface ID propagation, I feel like this bug is obsolete. Marking as WontFix.
Components: -Internals>MUS Internals>Services>WindowService
Components: -MUS

Sign in to add a comment