1125322 - (dt-open-slow) [meta] Open developer tools slow down page load

Status: NEW

(DevTools :: General, defect, P2)

Description

[Dane MacMillan [:danemacmillan]]

I recently started running performance tests against a big and unwieldy Web site. It's slow, and the long-term goal is to make it faster. Part of that testing involves the use of Firefox's and Chrome's Developer Tools Network panels. I've completed innumerable tests in each. In every case, Chrome reports a significantly faster overall load time. For example, a page that will take 2.74s to fully load in Chrome, will take 8.84s to load in Firefox. These are averages--and to iterate, averages that have been calculated after dozens of tests in each. When I disable Firefox's Developer Tools, however, the load times appear, at least anecdotally, to load in the 2s to 3s range. Ultimately, it feels like it loads in the same time that it loads in Chrome (but Chrome's tools are open).

I've always noticed a fairly significant lag in page load when Firefox's Developer Tools were open, especially on large-ish sites, but this has really hammered that fact into consciousness. This renders load time reporting in Firefox's Developer Tools almost unusable.

Network panel aside, simply having the Developer Tools open causes significant, demonstrable lag. This is beyond "prove it with numbers," because it's just apparent to anyone. Simply trying to scroll during a page refresh with the Developer Tools open is not possible because the browser is in an unresponsive, schizophrenic state; a normal state is resumed once every asset of the page has been downloaded and parsed.

Something I want to make clear is that these such issues don't appear to exist in Chrome with their tools open; there's a certain steadfast, unrockable assurance from the page loads in Chrome, while in Firefox there's just that expectation that between page loads with the tools open, you just have to weather the shaky, histrionic storm until the browser stops choking, settles down, and the elements on the page become clickable and scrolling finally responds (usually with some delayed scroll that compounds the already janky experience). I'm a die-hard Firefox supporter, but I can't shake this feeling.

What can be, or is being, done to improve the performance of this? I'd really like some feedback on this. As it stands, I can't rely on the load times being reporting in Firefox.

---

My current hardware is latest OSX Mavericks, 64bit, 512GB SSD, 16GB RAM. My Internet speed is 100Mbps down and identical up. These stats would definitely not be the bottleneck.

Comment 1

[richard.cocks]

I find this as well. A site which takes 2-3 seconds to open without FF developer tools open is taking 12-15 seconds with it open.

Comment 2

[Panos Astithas (he/him) [:past] (please ni?)]

A link to the sites that behave like this is necessary for further investigation. Also, the tool that is open when such slowdown occurs and whether it happens with a specific tool or all of them.

Comment 3

[Alexandre Poirot [:ochameau]]

The scrolling slowness if quite easy to see when opening complex websites, like this french newspaper: http://www.lemonde.fr/
May be related to bug 1066581 and bug 1073926

Comment 4

[richard.cocks]

I have finally managed to reproduce this behaviour.

http://rcocks.github.io

This renders fast with no developer tools open. It runs slowly enough in Firefox (37.0.2 normal edition) with developer tools open that it crashes my firefox.

In Developer edition (39.0a2) it runs the same speed with or without developer tools open except if you try to record performance. Then it runs extremely slowly and does not show any time spent in anything but "(root)" when it has finished.

Comment 5

[Dane MacMillan [:danemacmillan]]

Richard, that page legitimately almost crashed my browser when the devtools were open. When they're closed, the page runs smoothly. Good job on that. That page was very similar to my experience on the production site I was auditing for performance bottlenecks when I initially wrote this ticket.

I accessed your test page with Nightly 41.0a1 (2015-05-20) with e10s disabled and enabled. In OSX I was beachballing hard regardless of the e10s setting.

I'm really curious to know how this will be addressed, because there is no denying the performance degradation when the tools are open.

Comment 6

[Dane MacMillan [:danemacmillan]]

There's a uservoice suggestion for this exact issue, with a few votes: 

https://ffdevtools.uservoice.com/forums/246087-firefox-developer-tools-ideas/suggestions/7263501-improve-general-devtools-performance-especially-c

Comment 7

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to richard.cocks from comment #4)
> I have finally managed to reproduce this behaviour.
> 
> http://rcocks.github.io
> 
> This renders fast with no developer tools open. It runs slowly enough in
> Firefox (37.0.2 normal edition) with developer tools open that it crashes my
> firefox.
> 
> In Developer edition (39.0a2) it runs the same speed with or without
> developer tools open except if you try to record performance. Then it runs
> extremely slowly and does not show any time spent in anything but "(root)"
> when it has finished.

If you test the latest Nightly build, do you still see a slowdown on this site?  I wasn't able to reproduce it, even when trying the Performance tools.

Comment 8

[richard.cocks]

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #7)

> If you test the latest Nightly build, do you still see a slowdown on this
> site?  I wasn't able to reproduce it, even when trying the Performance tools.

Yes, I do still see slowdown in the latest nightly (41.0a1). I am wondering if it is related to profiles, as there was one time I was unable to reproduce this behaviour when I was running a clean user profile. Having said that, even running in safe mode in nightly didn't help here since I still got the crash. Thankfully now thanks to e10s it only took down that tab!

Comment 9

[richard.cocks]

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #7)
> If you test the latest Nightly build, do you still see a slowdown on this
> site?  I wasn't able to reproduce it, even when trying the Performance tools.

I should have added, I'm on windows 7 [6.1.7601] if that makes a difference.

Also, the actual timings returned on the page show similar timings, but the whole site freezes for a long time. So the javascript thinks it is executing quickly but somehow it is locking up the browser anyway.

Comment 10

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to richard.cocks from comment #9)
> (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #7)
> > If you test the latest Nightly build, do you still see a slowdown on this
> > site?  I wasn't able to reproduce it, even when trying the Performance tools.
> 
> I should have added, I'm on windows 7 [6.1.7601] if that makes a difference.
> 
> Also, the actual timings returned on the page show similar timings, but the
> whole site freezes for a long time. So the javascript thinks it is executing
> quickly but somehow it is locking up the browser anyway.

I retested on Windows 8.1, but still appeared to work fine there.  I don't have a Windows 7 setup at the moment.

Can you capture the data in about:support to a file for your profile where you do see the issue, and attach it to this bug?

Comment 11

[richard.cocks]

Attachment: firefox.txt

I've attached this file which is the about:support data, I hope this helps.

Comment 12

[richard.cocks]

To help narrow this down, if I open the developer tab but never go to the "Inspector" tab then I don't get this behaviour.

Comment 13

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to richard.cocks from comment #12)
> To help narrow this down, if I open the developer tab but never go to the
> "Inspector" tab then I don't get this behaviour.

That was the hint I needed, I can reproduce now!  I feel like this bug is describing multiple different issues across various sites, so I'll make this a meta bug.

I've created bug 1170848 for this specific issue.

Comment 14

[Dane MacMillan [:danemacmillan]]

I can also confirm that the open Inspector panel cripples performance, but the others do not.

One thing I should mention, now that at least the Inspector panel slow down can be reproduced, is the general makeup of the page I was testing in the Network panel:

 13 CSS files
 47 JS files
  7 font files
162 images
  1 HTML document
--------------
230 requests (it was above 250 before I started documenting the progress)


The size of all downloaded assets:
3735.63 KB (3.7 MB)

From that, the HTML document averaged 142.43 KB, so its constructed DOM was massive.

Knowing this, could it be possible that when that many requests are made, some of which being quite large, that the Network panel could be a crippling point as well? Could it be possible that the massive DOM that needed to be constructed could have impacted the performance of other tools in the DevTools? Just having the tools open, regardless of panel, were causing slowdowns, as mentioned in the opener of this ticket.

Comment 15

[Brian Grinstead [:bgrins]]

(In reply to Dane MacMillan from comment #0)
> I recently started running performance tests against a big and unwieldy Web
> site. It's slow, and the long-term goal is to make it faster. Part of that
> testing involves the use of Firefox's and Chrome's Developer Tools Network
> panels. I've completed innumerable tests in each. In every case, Chrome
> reports a significantly faster overall load time. For example, a page that
> will take 2.74s to fully load in Chrome, will take 8.84s to load in Firefox.
> These are averages--and to iterate, averages that have been calculated after
> dozens of tests in each. When I disable Firefox's Developer Tools, however,
> the load times appear, at least anecdotally, to load in the 2s to 3s range.
> Ultimately, it feels like it loads in the same time that it loads in Chrome
> (but Chrome's tools are open).
> 
> I've always noticed a fairly significant lag in page load when Firefox's
> Developer Tools were open, especially on large-ish sites, but this has
> really hammered that fact into consciousness. This renders load time
> reporting in Firefox's Developer Tools almost unusable.

Bug 1143224 (even the part that have already landed) should help a lot with netmonitor timings, and there is one more patch there that should improve things further.

> Network panel aside, simply having the Developer Tools open causes
> significant, demonstrable lag. This is beyond "prove it with numbers,"
> because it's just apparent to anyone. Simply trying to scroll during a page
> refresh with the Developer Tools open is not possible because the browser is
> in an unresponsive, schizophrenic state; a normal state is resumed once
> every asset of the page has been downloaded and parsed.
> 
> Something I want to make clear is that these such issues don't appear to
> exist in Chrome with their tools open; there's a certain steadfast,
> unrockable assurance from the page loads in Chrome, while in Firefox there's
> just that expectation that between page loads with the tools open, you just
> have to weather the shaky, histrionic storm until the browser stops choking,
> settles down, and the elements on the page become clickable and scrolling
> finally responds (usually with some delayed scroll that compounds the
> already janky experience). I'm a die-hard Firefox supporter, but I can't
> shake this feeling.
> 
> What can be, or is being, done to improve the performance of this? I'd
> really like some feedback on this. As it stands, I can't rely on the load
> times being reporting in Firefox.

The best bet for getting these fixed is to file bugs with a link to a page (or attached test case) that demonstrates the slowness on a particular tool.  We now have a performance test to measure toolbox open / close and page reload time for each of the panels, so hopefully that will give us data to validate that the work we are doing is helping: https://wiki.mozilla.org/Buildbot/Talos/Tests#DAMP.

One more thing - if you enable multiprocess mode, there is a good chance that these problems will go away or at least become a lot less bad.

Comment 16

[Boris Zbarsky [:bzbarsky]]

I filed bug 1188526 with some profiling info on comment 4.

Comment 17

[raphael777777]

Hello! I have FF 47.0.1, and I am experiencing this issue. I work on an intranet site that is password protected. Due to the sensitive nature of the data on our site I can't provide a link. However, I created a small (7MB) video demonstrating this issue. I can send this directly to the developers (I would prefer to not post it on a random website). Please let me know how I can get it to you.

I can provide any FF log/browser data needed. Just let me know what you need and how I can get it to you. I want to do anything possible to help get this fixed.

Comment 18

[Brian Grinstead [:bgrins]]

(In reply to raphael777777 from comment #17)
> Hello! I have FF 47.0.1, and I am experiencing this issue. I work on an
> intranet site that is password protected. Due to the sensitive nature of the
> data on our site I can't provide a link. However, I created a small (7MB)
> video demonstrating this issue. I can send this directly to the developers
> (I would prefer to not post it on a random website). Please let me know how
> I can get it to you.
> 
> I can provide any FF log/browser data needed. Just let me know what you need
> and how I can get it to you. I want to do anything possible to help get this
> fixed.

Hi, can you give some more details about what tool / actions are triggering the slowness - is it the network monitor, inspector, etc?  As far as the video, you can send me an email with a link to the video (or include it as an attachment) at [e-mail].

Comment 19

[raphael777777]

Brian,

I just emailed the video to you. 

I am using the built-in FF Inspector. The slowdown happens regardless of which tab I have open. It happens on a page with many textboxes on the blur event. When the blur happens, the page has to do some updating, which includes an AJAX call. When the Inspector is open, it takes about 5-8 seconds to update. When the Inspector is closed, the update is instantaneous.

Comment 20

[Nelson]

Using 47.0 on (Linux Mint 17.3, 8 Cores, 8 GB RAM) the CPU spikes to 105% when editing a property in the CSS.
And by that I mean just going to one property value, hitting Enter (which moves cursor down to type a new property name) and doing nothing else. CPU spikes.
The CSS file used by this page is about 2.2MB in size.
What I find interesting is, that at to that point, I have not changed anything, so not sure why the browser will be "trying" to do something.

Comment 21

[Nelson]

Also, same computer as above, I notice that page slows down when doing AJAX requests (I'm using angular with promises). When tools are hidden, everything flights. When open, it just takes a long time (in Network pane, it doesn't show as the call taking a long time, just nothing right before that)

Comment 22

[Brian Grinstead [:bgrins]]

(In reply to Nelson from comment #21)
> Also, same computer as above, I notice that page slows down when doing AJAX
> requests (I'm using angular with promises). When tools are hidden,
> everything flights. When open, it just takes a long time (in Network pane,
> it doesn't show as the call taking a long time, just nothing right before
> that)

Could you please provide a link to the page you are seeing these network issues on?

Comment 23

[Brian Grinstead [:bgrins]]

(In reply to Nelson from comment #20)
> Using 47.0 on (Linux Mint 17.3, 8 Cores, 8 GB RAM) the CPU spikes to 105%
> when editing a property in the CSS.
> And by that I mean just going to one property value, hitting Enter (which
> moves cursor down to type a new property name) and doing nothing else. CPU
> spikes.
> The CSS file used by this page is about 2.2MB in size.
> What I find interesting is, that at to that point, I have not changed
> anything, so not sure why the browser will be "trying" to do something.

The tools are likely trying to tokenize this file even before attempting to make an edit.  If you could provide a link to the page, that would be helpful

Comment 24

[Nelson]

(In reply to Brian Grinstead [:bgrins] from comment #23)
> (In reply to Nelson from comment #20)
> > Using 47.0 on (Linux Mint 17.3, 8 Cores, 8 GB RAM) the CPU spikes to 105%
> > when editing a property in the CSS.
> > And by that I mean just going to one property value, hitting Enter (which
> > moves cursor down to type a new property name) and doing nothing else. CPU
> > spikes.
> > The CSS file used by this page is about 2.2MB in size.
> > What I find interesting is, that at to that point, I have not changed
> > anything, so not sure why the browser will be "trying" to do something.
> 
> The tools are likely trying to tokenize this file even before attempting to
> make an edit.  If you could provide a link to the page, that would be helpful

Here is one (to avoid automatic links, just type it in your address bar, replacing - for dots):
truereligion-ngcxpress-com

Comment 25

[Nelson]

Attachment: Network pane taking a long time between files

Comment 26

[Nelson]

(In reply to Brian Grinstead [:bgrins] from comment #22)
> (In reply to Nelson from comment #21)
> > Also, same computer as above, I notice that page slows down when doing AJAX
> > requests (I'm using angular with promises). When tools are hidden,
> > everything flights. When open, it just takes a long time (in Network pane,
> > it doesn't show as the call taking a long time, just nothing right before
> > that)
> 
> Could you please provide a link to the page you are seeing these network
> issues on?

Unfortunately the places (using Angular) are internal or password protected. I made a screen shot attachment of another site (not using Angular) that is displaying the same behavior. What I noticed is that the file where it takes a long time (in the image is the last javascript before some images) it's a language file (creates an array with language keys, about 600 of them). The same thing that the internal site is doing using Angular.
It seems like for some reason it is getting slow when processing that javascript file.
Notice that when tools are not open, this page flies (no delay whatsoever)

Comment 27

[Brian Grinstead [:bgrins]]

Filed Bug 1288493 based on a test case provided by raphael777777

Comment 28

[Maciej Jaros]

Seems like a general problem with pages that load many scripts (JS) in background.

Uncompiled (unmerged) ExtJS app loads VERY slowly (x10 factor) on FF with dev tools open.

FF: https://youtu.be/Z95TcgS94RM
Chrome: https://youtu.be/YKgg9aa913Q

Code not public, sorry but I assume you can reproduce with any ExtJS app with 100+ classes.

Comment 29

[Maciej Jaros]

Also note that I see no difference between HTTPS/2 and plain HTTP on FF. Both complete loading the page in about 34 s in FF (Chrome is always below 3 s).

Comment 30

[canessa.alex]

It (In reply to Maciej Jaros from comment #28)
> Seems like a general problem with pages that load many scripts (JS) in
> background.


The problem presents when you're trying to use source map and you have many JS files.
The same website with source map off, loads as expected.

Comment 31

[Stephen Donner [:stephend] Not actively reading bugmail]

Mass-removing myself from cc; search for 12b9dfe4-ece3-40dc-8d23-60e179f64ac1 or any reasonable part thereof, to mass-delete these notifications (and sorry!)

Comment 32

[Pavlos Karakalidis]

This is still a problem to be honest. This isn't something that the average user will notice but makes the life of developers very very difficult. I have also noticed that the source maps are reason for this slowdown. But I also tried compiling a big angular project without source maps, the website loaded, but until dev tools parsed all the files, the website remained unresponsive.

(In reply to canessa.alex from comment #30)

It (In reply to Maciej Jaros from comment #28)

Seems like a general problem with pages that load many scripts (JS) in
background.

The problem presents when you're trying to use source map and you have many
JS files.
The same website with source map off, loads as expected.

Comment 33

[:Harald Kirschner :digitarald]

Pavlos, we addressed the known slow paths (see closed bugs) and are looking for more real-life case that we can further do root cause analysis on.

Could you record a slow page devtools session with profiler.firefox.com (Firefox Platform preset) on your heavy JS project (preferrably using Nighty or DevEdition)?

Comment 34

[Pavlos Karakalidis]

I have uploaded the profiles. Here are the urls to those.

I am loading the same exact component with the same data and the same network connection.

Here is the profile with the Dev Tools closed:

https://profiler.firefox.com/public/0862ad5fa4f4bca149c717de3e8513d8029ccaa6/calltree/?globalTrackOrder=5-6-7-0-1-2-3-4&hiddenGlobalTracks=1-2-3&hiddenLocalTracksByPid=48173-0-2-3~48343-0&localTrackOrderByPid=48173-4-0-1-2-3~48343-0~48281-0~&thread=9&v=4

and here with the Dev Tools open:
https://perfht.ml/3gbCE6T

As it can be seen, the page loads, but is unusable until the file parsing is finished.

Note: When I run the profiler with the dev tools open, I didn't let them finish parsing the js files as that would have taken a long time and I wouldn't be able to upload the profile. (>50MB)

Comment 35

[:Harald Kirschner :digitarald]

Logan, do you have any idea what could cause the main thread thrashing of addSources/< and insertSourceActors/< in https://share.firefox.dev/2B5GXk7 ?

Comment 36

[Logan Smyth [:loganfsmyth]]

This seems to be primarily perf issues around updating the data neeed to drive the Debugger's source-file list tree as new sources appear. I know it's something others have looked into in the past, but it may be worth me digging into it to see if I can see anything we'd want to address.

One change that I think is relatively low-hanging would be addressing https://bugzilla.mozilla.org/show_bug.cgi?id=1622191, but I don't know if eval is at all involved with the code being debugged in the case of this profile so that could be entirely separate.

Comment 37

[jaysmith696]

I've been experiencing this bug for a couple years now, any site I go to, loads smooth, If I pop open dev tools, it takes 10-15 seconds to fully load.
Is there a fix for this? 🤯 I can't properly do any benchmarking with performance tests with this bug.

Please help

Comment 38

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Are there any specific/shared characteristics of the pages you load and experience the perf issue with?
E.g.

1. Happens on pages with a lot of HTTP requests
2. Happens on pages with a lot of JS files
3. Happens on pages with a high JS activity

Also, can you please attach a profile?
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler

Thanks,
Honza

Comment 39

[David Silva]

Hey, not sure if my issue correlates directly to this, but whenever opening devtools on https://csgohub.com the page hangs for ~2 minutes and devtools only renders post that. Seems like opening devtools causes a full 'rerender behind the scenes?'

I have successfully captured a profile, but I'm stumped as to why this only happens in the production build of this.

https://profiler.firefox.com/public/m58x2j59k4tran9nntwrwetpjk4tbscgt26r3tg/calltree/?thread=10&v=5&view=active-tab

Thanks,
David

Comment 40

[supersonicsnow]

TLDR - SEE SOLUTION AT BOTTOM!

Firefox Dev edition 93.0b1 64 bit Linux 5.10 Kernel
I just encountered this on a webapp I've been developing over a long period of time.
It only occurred yesterday, when I was working on a new big commit.
So I stashed and went back to previous commit, where loading the site with the console open was fast... but it was also slow.
That's weird. I could have sworn the slowness only started on the latest commit.

Then I tested with Chromium, fast with dev console open or closed.

Then I realized I have a ton of plugins in FF.

!!!!!!!!!!!!!!!!!SOLUTION!!!!!!!!!!!!!!!!!!!!
So I disabled all plugins one by one. Then all my tabs suddenly self closed.
I opened the site with console open. It was fast.
I enabled each plugin and retested each time one by one.
It was fast.
Eventually I had all the same plugins enabled again, and it was fast with the dev console open.

So I guess Firefox got a bit crusty with the Addons.
Might be an addon crustyness bug.

Comment 41

[michal.zubkowicz]

I can confirm that issue permanently exists.
I've created repository with frontend app, which has multiple files and you can clearly see there slowdown:
https://github.com/michalzubkowicz/slow-vite-demo
npm install
npm run dev

Comment 42

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:Honza, could you please find another way to get the information or close the bug as INCOMPLETE if it is not actionable?

For more information, please visit auto_nag documentation.

Comment 43

[Xavier OTTOLINI]

The behavior of the developer tools is much better with Firefox 103 as it was 8 years ago. Especially the duration to load the sources in the Debugger tab.
But the "Network" tab is still twice longer as in Chrome and Edge.

Comment 44

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Alex, is there anything actionable on this meta or should we close it? (all dependencies are closed)

Comment 45

[Alexandre Poirot [:ochameau]]

(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #44)

Alex, is there anything actionable on this meta or should we close it? (all dependencies are closed)

The value of this bug is mostly about the user reports rather than bugs management.
It could be worth looking at comment 41 and see if that's still slow and also request more information about comment 43 slowness on the netmonitor.

(In reply to Xavier OTTOLINI from comment #43)

The behavior of the developer tools is much better with Firefox 103 as it was 8 years ago. Especially the duration to load the sources in the Debugger tab.
But the "Network" tab is still twice longer as in Chrome and Edge.

Xavier, would you have a test page to demonstrate a significant difference between firefox and chrome/edge?

Comment 46

[michal.zubkowicz]

In https://bugzilla.mozilla.org/show_bug.cgi?id=1125322#c41 I've provided test case, and I can confirm that it's still valid.
Reproduction is quite simple. Clone the repository, run: npm i && npm run dev , and then You'll see that in chrome with network tab open in FF everything is loading 1s, in Chrome it's 133ms.

Comment 47

[Shara Huey]

(In reply to michal.zubkowicz from comment #46)

In https://bugzilla.mozilla.org/show_bug.cgi?id=1125322#c41 mapquest directions I've provided test case, and I can confirm that it's still valid.
Reproduction is quite simple. Clone the repository, run: npm i && npm run dev , and then You'll see that in chrome with network tab open in FF everything is loading 1s, in Chrome it's 133ms.

Thanks for the detailed explanation

Comment 54

[Ambica Singh]

When you're working with source maps and you've got a bunch of JavaScript files, that's when things start getting tricky. But if you turn off the source map for the same website, everything loads just fine.

Comment 55

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Comment 56

[flack]

Not sure if this is the right place, I never had a big issue with the speed of dev tools opening, but starting two or so weeks ago, it became really slow. When I press F12 now, an empty window appears almost instantly, and then it takes around 7 seconds until it is filled with content and operational. This happens both on Linux and on macOS, and the sites I'm working with are the same, could it be that there was a regression somewhere?

Comment 57

[flack]

Attachment: devtools.mp4

Added screen capture of devtools loading

Comment 58

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.