Bug 127998 - Web Inspector: Ability to break on any line that will/did trigger a focus or caret change: focus(), blur(), etc.
Summary: Web Inspector: Ability to break on any line that will/did trigger a focus or ...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Matt Baker
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2014-01-31 10:35 PST by James Craig
Modified: 2017-02-09 20:12 PST (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Craig 2014-01-31 10:35:21 PST
Web Inspector: Ability to break on any line that will/did trigger a focus or caret change: focus(), blur(), etc.
Comment 1 Joseph Pecoraro 2014-01-31 10:37:08 PST
This would be enabling the DOMDebugger to break on events. Should be a dup of something.
Comment 2 Radar WebKit Bug Importer 2014-01-31 10:37:35 PST
<rdar://problem/15958228>
Comment 3 James Craig 2014-01-31 10:39:06 PST
I don't think so. Calling focus() and blur() does not trigger an event, specifically to avoid loops.
Comment 4 Joseph Pecoraro 2014-01-31 10:42:44 PST
Ahh, okay. That sounds reasonable.
Comment 5 bradley.meck 2014-01-31 11:21:33 PST
The key feature here is tracking the cause of a blur, focus, or caret change. The cause of the change and its location are not able to be determined at the time of an event (relatedTarget may give hints but not an actual location). For example, when you call element.focus() it queues a focus but the event that event lifecycle has no way to get back to the line that originally started the lifecycle. Even more useful than the actual location is the ability to add a breakpoint to debug around lines that are queueing changes in focus and/or caret. This becomes increasingly useful for tracking focus changes across multiple ticks that are the result of one another.