Narrow bisect:
https://chromium.googlesource.com/chromium/src/+log/552dbdc4c66ae49753f84c892d5e3ff54daeb1ab..c5e032910d4c8119f8c40df507fda64e5fec11a0?pretty=fuller&n=10000

Suspecting: r393641 ?

Kindly help to re-assign, if your changes are not cause for this issue.

Marking the above issue RB-Stable, as this is a recent regression.

Thank you!

I don't think this is related to r393641.

My CL makes no behavioral change without the VisualViewportAPI runtime enabled feature. I see that the bisect also includes an upstream from catapult. AFAICT, the 'File size stats' frame was not movable before that, so I think they may have made some change to their UI which makes another bug visible? Don't think it's a regression.

@tdresser, any idea who would know about this change?

Ben's change exposed it, so assigning to ben.

https://chromium.googlesource.com/external/github.com/catapult-project/catapult.git/+/849bc5d4ec90569bceaa29274fc80482947a94dd

Thanks!
Looks like there are a few separate problems.

The mouse-mode-selector is pushed aside as the side panel is manually expanded, though it should probably wait to start moving until the side panel is pulled past it.

The mouse-mode-selector is *not* pushed aside when the side panel pops open, though it probably should be. (This might have predated my change?)

The mouse-mode-selector floats on top of the side panel, which ruins the intended illusion that it floats on top of the timeline-track-view.

The best solution to the mouse-mode-selector's many problems might be to kill it and move its buttons into the timeline-view's control bar, which has been suggested but hasn't been a priority. That might be easy. I'll try it now.

Another problem is that the side panel can be pulled so far that it's under the tracks' tr-ui-headings on the left. Fortunately, the drag handle has a higher z-index than the track headings, so you'd still be able to drag it back if you dropped it under them.

I could try to enforce an invariant that the side panel can never be wider than the viewport minus the headings' width. That would require a layer violation somewhere: there isn't anything that should know about both tracks' headings and the side panel.

Or I could make the side-panel-container prevent the user from dragging the drag handle past the point where the side-panel is fully visible. So whatever width the side panel has when it's first created would be its max-width instead of just its width. That might require more communication between side-panels and the side-panel-container, which would be doable but may be a bit fragile in the long run when side-panels come and go.

Or I could raise the side-panel-container's z-index above the track headings, so that the whole side-panel is always on top of the track headings. It looks like that's what the analysis-panel does, and it's only 3 lines of CSS, so I'll do that.

(open) Move pointer mode controls out of a floating window:
https://github.com/catapult-project/catapult/issues/868

(fixed) Side-panel z-index needs to be elevated:
https://github.com/catapult-project/catapult/issues/2353

I think we should file this bug as WontFix. Its not a really serious regression.

Ben, you uncovered the fact that the way we do zindex is messed up right now, in our architecture. But I think we should take a slow n steady approach to how to fix it.

Seems like partly we should have the embedder set the zindex, and partly we probably want convention where you only set zindex when you also make yourself a stacking context (e.g. by forcing yourself to be pos:abs).

I kinda also wonder if its time to figure out our v2 of trackview, too, since that dom that is showing through wouldn't be dom in the new version...

Finally, I wonder if the bug here is possibly a missing overflow:hidden on the part that is overflowing, or some similar css state taht says "when your given width is smaller than your minimum layout width, crop instead of just showing."

Also, Etouch: please note that we asked not for these kinds of tests to be performed, per https://docs.google.com/document/d/1-4myFLT5tV8fkPz8Ffep6LdyCGg2UsI7X7mMPzOkLv0/edit

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue is Pri-1 but has already been moved once. Lowering the priority and moving to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This is outside the scope of the tracing test plan:
https://docs.google.com/document/d/1-4myFLT5tV8fkPz8Ffep6LdyCGg2UsI7X7mMPzOkLv0/edit

If we notice this bug in the catapult dev server then we'll fix it there.