Bug 90423 - Web Inspector: Option to ignore exceptions/breakpoints during page unload
Summary: Web Inspector: Option to ignore exceptions/breakpoints during page unload
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated) (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Vsevolod Vlasov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-02 18:44 PDT by James Darpinian
Modified: 2014-08-03 19:05 PDT (History)
13 users (show)

See Also:


Attachments
Patch (4.53 KB, patch)
2012-07-04 08:58 PDT, Vsevolod Vlasov
no flags Details | Formatted Diff | Diff
Patch (4.58 KB, patch)
2012-07-04 09:02 PDT, Vsevolod Vlasov
pfeldman: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description James Darpinian 2012-07-02 18:44:31 PDT
Breakpoints and the "Pause on all exceptions" feature often delay page reload, because the page won't reload until you hit "continue" once for each breakpoint/exception hit during the page unload process. An option to ignore breakpoints and exceptions during page unload would really speed up "edit/reload" style iterative development.
Comment 1 Pavel Feldman 2012-07-03 03:09:05 PDT
Could you use "deactivate breakpoints" for that? Creating a dedicated action for such a corner case scenario does not sound great to me.
Comment 2 James Darpinian 2012-07-03 12:18:40 PDT
This is hardly a corner case; it happens all the time when you are paused at a breakpoint and want to reload the page. Pressing reload will continue past one breakpoint at a time, but if you have multiple breakpoints (or exceptions) you have to hit reload over and over before the page will actually reload. But if you hit it too many times you will interrupt the next page load, so you have to be really careful.

Using "deactivate breakpoints" and disabling "Pause on exceptions" every single time you want to reload the page is a chore, and it's impossible if you're debugging page load issues because you don't have time to re-enable them before the page re-loads.
Comment 3 Andrey Adaikin 2012-07-04 01:04:02 PDT
FYI, I faced the same problem couple of times, and tend to agree with James on the request. Quite hard to workaround existing behavior.

Although adding a new option to "ignore on reload" seems too complex. Maybe we should just disable all breakpoints upon hitting the Reload button until the page starts being loaded again? or have two different behaviors, for example, on Ctrl+R and Ctrl+Shift+R?
Comment 4 Pavel Feldman 2012-07-04 05:25:12 PDT
> Although adding a new option to "ignore on reload" seems too complex. Maybe we should just disable all breakpoints upon hitting the Reload button until the page starts being loaded again? or have two different behaviors, for example, on Ctrl+R and Ctrl+Shift+R?

Sounds good to me.
Comment 5 Vsevolod Vlasov 2012-07-04 08:58:51 PDT
Created attachment 150807 [details]
Patch
Comment 6 Vsevolod Vlasov 2012-07-04 09:00:20 PDT
This patch does not change behavior for ctrl-r or f5 pressed when focused on inspected window, but since inspector receives focus on pause in docked mode this will make a large part of the users happy.
Comment 7 Vsevolod Vlasov 2012-07-04 09:02:16 PDT
Created attachment 150810 [details]
Patch
Comment 8 Pavel Feldman 2012-07-04 09:43:02 PDT
Comment on attachment 150810 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=150810&action=review

> Source/WebCore/inspector/front-end/inspector.js:736
> +WebInspector.reloadPage = function(ignoreCache, scriptToEvaluateOnLoad)

Could we move this method to the debuggerModel? It seems to call into it with every line.

> Source/WebCore/inspector/front-end/inspector.js:740
> +        setTimeout(WebInspector.debuggerModel.setBreakpointsActive.bind(WebInspector.debuggerModel, true), 0);

Front-end timer is not synchronized with inspected page / protocol, so you should not need it. I would do

setBreakpointsActive(false);
PageAgent.reload()
setBreakpointsActive(true);
Comment 9 Pavel Feldman 2012-08-02 06:44:17 PDT
Downstream bug: http://code.google.com/p/chromium/issues/detail?id=134310
Comment 10 piersh 2012-10-09 10:49:39 PDT
two points
1) how about refreshing the page by re-typing the URL (or just hitting enter in the address bar)? currently this also exhibits the stop-at-breakpoint problem.
2) how about debugging 'onbeforeunload' scripts?