That level of detail isn't really provided in the Perf tab, as it's quite invasive and can have significant perf overhead in a busy webapp. (DevTools does have a hidden experiment called "Timeline: Invalidation Tracking" which does report on various DOM/CSS changes, though. It's cool).
Also, I should point out a _very_ similar extension my mate built: https://github.com/kdzwinel/DOMListenerExtension Same basic idea, but just reporting every change to DOM nodes that a MutationObserver can see.
Really nice explanation in detail, I do really learn a lot from your reply.
And I'm so glad to hear that your mate has done a great job relevant to this topic, I have search for a long time but didn't get any relative work. I will look over his repo and learn more from there.
As a sidenote, they might want to add a little "play" button on the video's preview image. At first glance, I scrolled past without understanding that the image was a link to the video.
Enough to be noticeable in a busy webapp with lots of DOM manipulations. You'll probably want to keep its instrumentation disabled when you're not actively using it.
That's right. Especially for doing animations. There will be a lot of additional tracking work even though those operations have been tracked. Performace issue will be a challenge future work
This might work on Firefox, but I doubt it, given it extends Chrome Dev Tools and Firefox doesn't have Chrome Dev Tools, it has its own very different dev tools.
I'm not sure what you mean by a "true" WebExtension; Firefox and Chrome addons are two types of webextension. They have a lot of compatibilities and generally share the same APIs on shared features, but each also has its own extra, unique features that will likely never be supported by the other.
> was the firefox quantum move a failure?
If you're choosing to define "failure" as not changing Firefox entirely to be a carbon copy of Chrome, then yes. Otherwise, no.
Firefox recently deprecated their entire legacy extension system, in favour of a new, more secure system based on Chrome's extension system, and also on the W3C's draft spec[0]
This means that many things should be identical between them: including but not limited to the packaging format, manifest format, security model, and the basic APIs for simple common browser features like tabs, page loads, network connections, etc. which gives you a very high compatibility surface area.
Naturally, APIs for any innovative features either browser have will be unique to that browser. e.g. Firefox has unique APIs for it's Container system, and it's Sidebar. I guess Chrome has some unique features too.
This is so impressive. These insights are really informative and helpful. I have much more concepts of these two browser after reading your reply. Really thanks for your sharing and amazing effort :)
I only focus on Chrome so far and haven't do much survey to the entension sysytem of Firefox. Integrate with Firefox could be a next challenge to move on
Another reply touched on the possible differences in extending devtools, I can't speak to that.
I've built several extensions now that worked seamlessly in both Firefox and Chrome. Firefox exposes a `chrome` object that very nearly matches the Chrome extension API and a `browser` object that goes beyond it (e.g. Promise-based async handling instead of callbacks, some additional functionality).
The only incompatibility between the two that I've specifically come across is that Firefox doesn't allow background pages to be specified as persistent. Otherwise if you're doing fairly standard stuff with content scripts, background scripts, browser actions and page actions everything should Just Work.
