Hover to show event handlers

[argyleink]

https://twitter.com/_baxuz/status/1088066681656750081?s=20

the tooltips are ready to go, just need the data and a template made

[fxnoob]

Hi @argyleink,
As we can’t get all the event connected to an element directly eg jquery keeps track of all the events attached to an element internally but in vanilla js there’s no track of it at all but we can achieve it by overriding the definition of addeventListener and adding this definition before content load maybe as content script in the extension.
Thoughts ?
Inspiration from : https://gist.github.com/cmbaughman/61ad5b49f10832e07b21993a20b94d8a
or
we can use chrome devtools apis to evaluate the result of getEventListeners api available in chrome console and communicate content script with devtools script through background script(visbug.js)
ref: https://developer.chrome.com/extensions/devtools

[argyleink]

nice clever gist there, but i'm not sure we can guarantee our script is first. which, lucky for us, we've got the background script yep, which can get the data from devtools. the only reason that's not 100% the best choice, is that it would be the first feature that requires devtools and ultimately makes visbug not just a simple portable web component, which is ok.

you gonna attack this one?! follow what the metatips are doing and you should be good to go. metatip flow is like this:

• hover event passes hover node to a new events feature function
• feature function extracts data for tooltip
• create a tooltip element and give it the data
• feature function manages tooltip lifecycle

hm, seems like hard parts will be these:

• toolbar needs a new icon to represent event inspection and we're getting low on vertical space see bar is taking up lots of vertical space, consider grouping some features  #97
• accessibily and metatip features are quite similar but i havent made a base class/function yet for them because there's only 2. this event inspect mode would be a 3rd and be an opportunity to refactor a bit (if we wanted, not required yet imo)
• i've explored patterns for message passing between visbug and devtools in a PR (Feature: Design Tab (WIP) #205), curious if we can use the class i made

[fxnoob]

I was able to load that mentioned gist script before any script included on the page. by mentioning in content script setting in the manifest.json like:

{
  "name": "My extension",
  ...
  "content_scripts": [
    {
      "matches": ["<all_urls>"],
      "run_at": "document_start",
      "js": ["contentScript.js"]
    }
  ],
  ...
}

ref: https://developer.chrome.com/extensions/content_scripts
Then I put the gist code in the contentScript.js file. By that, regular scripts got the ability to list all the event listeners attached to an element and remove them by name or all at once. what could be the side effect of this method?
Second way also seems another hacky way to me. I would go with the first way as it seems much natural to me. Thoughts?
Why can't we just add event listeners list on Accessibility popup like in the screenshot below? Further we can provide the ability to detach eventlisterner by putting checkbox after each event name on popup.

[argyleink]

rad work! side effects unknown, but we could test. looks like you're building the extension and loading it and trying it around the web, awesome.

you know, dropping the event information into the a11y inspector looks like a fine idea.

and your idea about checkboxes being in there, i'd love it if those tooltips were reactive and interactive, but that's a longer term goal. feel like it wouldn't take much though in your current workflow to add that? unsure if designers need to control them, but front end might like that a ton.

2 things i'm unsure/concerned about:

• running a script on every page even if they arent using visbug
• the information isn't really a11y related, maybe it's better for the regular inspector tip? i feel like it's overloading the purpose of the a11y inspect tip

curious too what felt hacky about a devtools message passing architecture?

again, this is very exciting work, looks like you're having fun!
have a branch!? i'd love to make a glitch out of it and play.

final question(s): having been the first user and tried it out a few places, what are your thoughts!? useful? is it creepy how many listeners are on things? can we show a count next to the listeners name?

[fxnoob]

• running a script on every page even if they arent using visbug

I was thinking about it. We can provide a control to the user of enable/disable the visbug.By defining a popup page and putting two buttons in there. one for enable/disable and second one is to open the visbug in the active tab. by saving the selected option using chrome storage apis. we can include /exclude the main content of the content script by checking the options saved in storage through message passing to background script.

• the information isn't really a11y related, maybe it's better for the regular inspector tip? i feel like it's overloading the purpose of the a11y inspect tip

yes. regular inspector tip is good for that.

curious too what felt hacky about a devtools message passing architecture?

As stated on the page https://developer.chrome.com/extensions/devtools :-

When sending a message from a content script, there is no ready-made method to deliver a message to the correct DevTools page instance associated with the current tab. As a workaround, you can have the DevTools page establish a long-lived connection with the background page, and have the background page keep a map of tab IDs to connections, so it can route each message to the correct connection.

So what is the prupose of devtools apis are accessible only from devtools page? It would be easier to have these apis accessed from background scripts.

final question(s): having been the first user and tried it out a few places, what are your thoughts!? useful? is it creepy how many listeners are on things? can we show a count next to the listeners name?

yes it makes sense just as inspect feature. Sometimes it feels creepy sometimes its not. yes we can show counts of listener

[argyleink]

first off, great conversation and excellent research and insights so far, this is really nice!

running a script on every page even if they arent using visbug

yeah, could put a checkbox behind an options flyout. the ux has a few bummers though:

• could forget you had it on and now you've got a script running on every page cuz you forgot to turn it off and who knows when/where it'll strike (cause a side effect and break something)
• opening the options, turning it on, refreshing, then invoking visbug just isn't smooth

seems like it'll be a decent amount of work making the above interaction smooth, but maybe not? thoughts?

yes. regular inspector tip is good for that.

I think we could drop the event information into the normal tooltip pretty quick and put off any new ui work until later (when we've got more data and we're more informed). Maybe for now follow the "local modifications" header pattern and make a new section called "Events" if there are events to report?

devtools protocol woes

I'm still not 100% sold the devtools protocol isn't the way to go. could be the way to best ux:

• launch visbug
• visbug requests a 1 time array of all events and their nodes on the page
• on hover, visbug looks into that hash and pulls out any events for the node being hovered

this means no storage bool, no potential side effects, no scripts on every page, etc. only work it means we need to do is make sure we're getting the events for the tab we're launched in (which certainly isn't broken). thoughts? it feels like devtools has already captured the events, we should ask them for it? wonder if we get more data?

scaling the presentation of events data

can you tell me a little about some of the event lists you've seen that are super large? like elements with lots of listeners? i'm curious what the high end of our dataset can be so I can think about how to handle it's presentation tier.

too bad we can't use chrome's handy "getEventListeners()" feature they have in the console!