Narrow Bisect :
https://chromium.googlesource.com/chromium/src/+log/477b394820e9c1308ccde24f69ddf5d0504ee609..8c6639a24a1df1f7e78ab630419e41048778b785?pretty=fuller&n=100

Suspecting: r444175 from Narrow bisect

@alph: Could you please help to reassign if your change is not the cause for this change.

Adding release block label, please undo if not the case.

The bisect seems to be wrong. added "pointer-event: none" could not affect scrollbar.

Looks like a flex layout bug to me.

Re-executed per-revision bisect and got the same suspect provided in Comment#1.
Providing the suspected commit from per-bisect revision.
https://chromium.googlesource.com/chromium/src/+log/477b394820e9c1308ccde24f69ddf5d0504ee609..1b769b1c19470c4df1b369bd4ebfeb40afc4dc3d

Commit#
https://chromium.googlesource.com/chromium/src/+/1b769b1c19470c4df1b369bd4ebfeb40afc4dc3d

Thank You.

Thanks for the second bisect.
It just confirms that something is wrong with layout if changing pointer-events property affects it.

cbiesinger@ Since this issue is marked as RB-Stable for M-57, can we get any latest update on this issue?

Thanks!

A friendly reminder that M57 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Tested this issue on Mac 10.12.3 with chrome canary #58.0.3011.0, as per steps mentioned in the comment #0

Observed that in step 2, when we drag dev tools window to RHS, no horizontal bar is seen.

mnikam@ could you please confirm this ???

With response to comment #12 :

Rechecked the above issue on latest canary chrome version : 58.0.3011.1 on Windows and Mac OS and the issue is not reproducible.It looks like scroll bar doesn't appear any more in 'Performance' section of devtools.

I'm confused -- the bug is not that pointer-events affects layout, it is that it affects whether the scrollbar works. That totally seems like something that could be affected by pointer-events. Why was this assigned to layout?

Putting this back in devtools, and Input for the pointer-events thing.

Also per comment 13 this seems to be working now, so adding needs-bisect to see if we can find out what fixed this.

It works because we changed layout of the page since then. To reproduce please apply the patch:

====================
diff --git a/third_party/WebKit/Source/devtools/front_end/timeline/timelinePanel.css b/third_party/WebKit/Source/devtools/front_end/timeline/timelinePanel.css
index 96eca8c24852..a9a7bcd7ec64 100644
--- a/third_party/WebKit/Source/devtools/front_end/timeline/timelinePanel.css
+++ b/third_party/WebKit/Source/devtools/front_end/timeline/timelinePanel.css
@@ -658,7 +658,8 @@
 }
 
 .timeline-landing-page > div {
-    max-width: 450px;
+    /* max-width: 450px; */
+    width: 450px;
     margin: 10px;
 }
 
======================

Not sure it's really related to pointer-events. I tried to remove the property, but it didn't help.

Closing as this now works as expected. If there is a specific issue with pointer events  and scrollbars please file a separate issue for that.

Sorry, I couldn't get why it is WAI?

I see two problems here:
  - the inner div is positioned past the left edge of the flex parent.
  - it's impossible to scroll there

Please see the attached screenshot.

Deleted: Screenshot from 2017-02-15 11:28:49.png 235 KB

	Screenshot from 2017-02-15 11:28:49.png 235 KB View Download

That's a different bug from what was originally reported. The reason as shown in your screenshot is that you're using justify-content: center. If you do that, any content that overflows to the left (in a row flexbox) will be outside the element and you can't scroll to that. We do not support scrolling in both directions which is what this would need.