Blackboxing doesn't prevent pausing in a blackboxed script that throws
Reported by
monfera....@gmail.com,
Nov 18
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36 Steps to reproduce the problem: 1. Blackbox a script that throws 2. Run over the throw with dev tools on 3. What is the expected behavior? It shouldn't pause according to the very explicit old doc https://developer.chrome.com/devtools/docs/blackboxing (Exceptions thrown from library code will not pause ([even] if Pause on exceptions is enabled)) and new doc implies it too: https://developer.chrome.com/devtools/docs/blackboxing "Blackbox a script when you want to ignore that script while debugging" - Yes I want to ignore that script, that's why I'm blackboxing it What went wrong? It will pause the execution while I have no interest in that script which is why I blackboxed it in the first place Did this work before? N/A Chrome version: 70.0.3538.77 Channel: n/a OS Version: OS X 10.13.6 Flash Version: This is super big friction in development, causing lost minutes and hours, because 1) Babel throws routinely; 2) The app I'm working on has some totally unrelated in-dev component that throws, and I'm not interested in it, which is why I'm blackboxing. I don't care if blacboxing excludes a script for both stepping through and exceptions, or if there's a separate mechanism or flag to let either or both behaviors. But it should work for both handled and unhandled exceptions. Eg. ideally I can blackbox all Babel scripts that throw handled exceptions (modus operandi, no idea why., there must be a reason for this otherwise bad and deopt-triggering practice...) and maybe stop on unhandled ones (while stopping eg. on all handled and unhandled errors in non-blackboxed scripts)
,
Nov 18
,
Nov 18
,
Jan 10
Experiencing this on 71.0.3578.98 windows x64 as well
,
Jan 11
My expectation based on the original documentation and a reasonable work process would be, also, that:
While in the debugger, hitting "Step into next function call" should NOT stop in a blackboxed script, it should stop at the next NON-blackboxed point. I lost count of how many times I see things like
var payload = finalPayloadCreator.apply(undefined, arguments);
and other super generic, tedious glue code which I hold no interest in following or exploring whatsoever. Blackboxing means blackboxing.
To rub salt into the wound, Dev Tools is leaving around these frameworkey source files left and right, and ALSO adds a super annoying, salient warning sign with an attention catching yellow background:
⚠️ This script is blackboxed in debugger
Which isn't even true - apparently. Otherwise it should take an _effort_ to get into these files, eg. by opening it expressly as a file, or finding some global text search hit in it (though it'd be nice if search could also be constrained to non-blackboxed scripts, or would list blackboxed hits separately)
|
|||
►
Sign in to add a comment |
|||
Comment 1 by monfera....@gmail.com
, Nov 18