The Devtools panel seems to be causing a dramatic slowdown when reloading our app (i.e. pressing the browser Reload button). Here's how to reproduce it: wget https://github.com/mozilla/addons-frontend/archive/8944b1d63294cb1f991dd274d408e2a2d0e1daa7.zip -O addons-frontend-tmp.zip unzip addons-frontend-tmp.zip cd addons-frontend-8944b1d63294cb1f991dd274d408e2a2d0e1daa7 npm install npm run dev:amo Wait for the server to start and the webpack bundle to build. You'll see a message containing 'Addons-frontend server is running...' Load this URL in Nightly: http://127.0.0.1:3000/en-US/firefox/addon/chillout-page-action/ Press the browser Reload button. It should reload quick-ish (within a few seconds). Open the Devtools panel. Now press the Reload button. The bug is that it takes about 20 seconds to load when the panel is open. Something is dramatically slowing it down. Observations: - another developer on my team confirmed this behavior - it doesn't happen in Firefox stable - this doesn't happen in Chrome stable - it happens in today's FDE and Nightly - disabling e10s doesn't make it go away Sorry for the heavyweight STR, I didn't have time to try and craft a lightweight example app. Even if it's something in our app, it still feels like a Devtools bug :)

I actually can't reproduce this. I clicked on various tools to make sure they were enabled, and opened that page, and it loads with a few seconds with the tools open. 51.0a1 (2016-09-12) (64-bit)

If I disable source maps in the Debugger panel's gear menu then the slowness goes away. It sounds like that's the culprit. If someone can ping me when the new source maps implementation lands I can try it out again :)

Just FYI, after the new debugger landed (earlier this week, I think?) my workaround no longer worked...around. I've been using Chrome just to get work done but let me know when there's something ready to test and I'll try it out. The other devs on my team are experiencing the same exact thing. We don't really want to disable our source maps because we need them for development.

(In reply to Kumar McMillan [:kumar] (needinfo all the things) from comment #3) > Just FYI, after the new debugger landed (earlier this week, I think?) my > workaround no longer worked...around. I've been using Chrome just to get > work done but let me know when there's something ready to test and I'll try > it out. The other devs on my team are experiencing the same exact thing. We > don't really want to disable our source maps because we need them for > development. That's good to know, thanks. I'm a little surprised this has regressed since source maps are temporarily disabled on the new debugger frontend - but there's work in progress to move the source maps to the client side. In the mean time if perf is preventing you from using it, you can disable the new frontend in Nightly with the devtools.debugger.new-debugger-frontend pref. Jason, can you point to the bug / issue where source maps are being converted to client side? Also,

Forwarding needinfo to James

(In reply to Kumar McMillan [:kumar] (needinfo all the things) from comment #3) > Just FYI, after the new debugger landed (earlier this week, I think?) my > workaround no longer worked...around. I've been using Chrome just to get > work done but let me know when there's something ready to test and I'll try > it out. The other devs on my team are experiencing the same exact thing. We > don't really want to disable our source maps because we need them for > development. I wonder about something. I can't reproduce it with the latest new debugger in nightly. It refreshes very quickly. What version of Firefox are you using? We used to have a bug where the new debugger didn't forcefully turn off sourcemaps on the server (bug 1303177). What this means is if you had sourcemaps turned on previously, and started using the new debugger, the server would still sourcemap sources. Can you check if `devtools.debugger.source-maps-enabled` is true in `about:config` ? If so, the sourcemap work is still happening. Regardless, I can't reproduce it in the new debugger... so not sure. If you can make sure you're on the latest nightly, I'll try to look into it more.

needinfo for Comment 6

> `devtools.debugger.source-maps-enabled` is true in `about:config` Yes, this was set to true for me (also the styleeditor one). On a second look, I'm a bit confused. Everything in today's Nightly is working flawlessly for me, even when enabling source maps \o/ No lag in the refresh. It's possible that I was accidentally using Dev Edition or something. Sorry about the confusion! I'd say it's fine to close this issue but I wonder if maybe my auto-rebuild cycle was accumulating cruft and maybe that's why I ran into problems before (after a lot of development). Anyway, I can use dev tools again for this app so I'll report back if I see the slowness again.

Let's keep this open for now - I believe the new frontend isn't supporting source maps yet so we should re-confirm it's all working once the latest bundle lands in nightly.

Yeah, this probably would be a good test case for the new sourcemap implementation.

(In reply to Kumar McMillan [:kumar] (needinfo all the things) from comment #8) > > On a second look, I'm a bit confused. Everything in today's Nightly is > working flawlessly for me, even when enabling source maps \o/ No lag in the > refresh. It's possible that I was accidentally using Dev Edition or > something. Sorry about the confusion! That's assuming you're only testing the new debugger, right? That's what we fixed: we permanently turn of sourcemaps on the server regardless of that setting now. So I bet that fixed it.

re: "everything ... working flawlessly for me" I just meant that there is no slowness on refresh while using the console and network inspector. Those are really the only two tools I use for this specific app.

If you could try again, that would be great. I think on nightly, source maps are enabled in the debugger. They're using the new client-side service, so I wouldn't expect a slowdown. If things are still slow, that would be good to know, as I'm actively working on source maps now.

> I'm actively working on source maps now. That's great news! I tried it in today's Nightly just now and source maps are not being used by the console or debugger. I saw an error in the browser console saying: SyntaxError: The URI is malformed. in _fetchSourceMap/req< resource://devtools/client/shared/source-map/worker.js:833:61 About our app: we use devtool: inline-source-map with webpack 2. See https://webpack.js.org/configuration/devtool/#for-development I don't know exactly what URI it was choking on but here is an example of what webpack puts in our JS bundle: //# sourceMappingURL=data:application/json;base64,eyJ2ZXJzaW9uIjozLCJzb3VyY2VzIjpbIi4uLy4uL3NyYy9UZW1wbGF0ZVRhZy9pbmRleC5qcyJdLCJuYW1lcyI6WyJkZWZhdWx0Il0sIm1hcHBpbmdzIjoiQUFBQTs7cUJBRW9CLGU7cUJBQWJBLE8iLCJmaWxlIjoiaW5kZXguanMiLCJzb3VyY2VzQ29udGVudCI6WyIndXNlIHN0cmljdCdcblxuZXhwb3J0IGRlZmF1bHQgZnJvbSAnLi9UZW1wbGF0ZVRhZydcbiJdfQ== (The source maps seem to be working fine in a release build of Chrome.) Let me know if you'd like more info about our application. Feel free to ping me as 'kumar' on IRC too.

> About our app: we use devtool: inline-source-map with webpack 2 For inline source maps, follow bug 1360357. I'm hoping to land that soon.

I've got the same problem in an Angular project that uses webpack 2 and I noticed something else that may be triggering this issue: Sometimes webpack will simply append the sourceMappingURL comment without removing an already existing sourceMappingURL and it also doesn't add any whitespace so that you end up with something like this: //# sourceMappingURL=script.js.map//# sourceMappingURL=data:application/json;base64,...

(In reply to hbenl from comment #16) > Sometimes webpack will simply append the sourceMappingURL comment without > removing an already existing sourceMappingURL I think the best thing to do here is to report this bug to webpack. This is not valid according to the sourcemap standard, and I don't think that it would be a good idea to try to work around the bug. I'm going to close this bug now, because inline source map handling has landed and I think that everything here that can be fixed has been fixed. Please reopen if that's in error.