UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36

Steps to reproduce the problem:
1. Open any website that uses Babel (or another transpiler) and source maps. 
2. Open a pre-transpiled source file 
3. Set a breakpoint on a line in that file. 
4. Run the app, hit the breakpoint. Now, imagine that you need to debug further and want to see the actual (post-transpilation) JS code being executed. I know you can disable source maps, but that requires restarting the debugging session which can take a long time for intricate debugging states.  Also, variable names are sometimes different in post-transpiled code, which makes debugging harder unless you're actually looking at the post-transpilation code. 

What is the expected behavior?
There should be an easy way to navigate from the pre-transpilation code to the post-transpilation code, and vice versa. 

What went wrong?
The only way I could figure out during a debug session to find the post-transpilation code corresponding to a particular line of pre-transpilation code is to open bundle.js in the sources pane and then Cmd+F to find a snippet of code that's not changed by transpilation. Given that transpilation can change lots of things in the code, this trial-and-error grepping is time consuming.

These days, many (most?) sophisticated web apps use transpilation. Chrome should make it easier to debug them!

Did this work before? No 

Chrome version: 67.0.3396.87  Channel: n/a
OS Version: OS X 10.13.5
Flash Version: