1084534 - Firefox takes a very long time to load sourceMap

Status: RESOLVED WORKSFORME

(DevTools :: Debugger, defect)

Description

[Ian Bentley]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141014145224

Steps to reproduce:

Create a relatively complex javascipt application which is processed by browserify as part of its build process. Let Browserify be responsible for generating the sourceMaps.  

In my case the javascript totals to ~12MB.

Navigate to page without developer tools open - confirm that javascript works, and that site loads quickly.

Open developer tools, and navigate to the debug tab.

I can reproduce with FF 33.0 on Linux and Mac OS X Mavericks


Actual results:

The browser consumes 100% of one of my cores for ~60s. It eventually completes the processing (sometimes firefox reports a slow script, but if it is allowed to run, it finishes), and performs normally - sourceMaps seem to work properly.

Subsequent refreshes to the page are also very slow


Expected results:

The browser should parse the sourcemaps relatively quickly, and proceed as normal.

In chrome the same sourceMaps are processed instantaneously.

Comment 1

[Loic]

It would be nice to have a testcase to test and debug.

Comment 2

[Ian Bentley]

I'm making some progress towards getting a testcase put together, but in my investigations I noticed something relevant.

There seems to be a significant implication related to the meta tag:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

In case that this tag appears, the page loads in ~ 65s; in case I remove the tag the page load tim drops to ~ 10s.

I will continue to prepare a full testcase.

Comment 3

[Ian Bentley]

Attachment: Filesize of js assets doesn't match actual size

Comment 4

[Ian Bentley]

Attachment: Both assets have the wrong filesize

Comment 5

[Ian Bentley]

I've attached two screenshots that show the network tab reporting the incorrect filesize.  I don't know if that is related or not, but it seemed odd.

Testcase still forthcoming.

Comment 6

[Loic]

Thanks for working on the testcase, it could be a regression in FF33 maybe.

Comment 7

[Ian Bentley]

Haven't been able to satisfactorilly create a minimal testcase (that I can release from my company), but I think that this: https://bugzilla.mozilla.org/show_bug.cgi?id=1007565 is the same issue.

Comment 8

[josh.ribakoff]

This is happening for me & my users, I'm in FF 39. It happens sometimes & not others. My JS file is also around 12MB, but is created via gulp & gulp-sourcemaps. When I use the "profile" tab, it shows links to my combined JS file & not to the original source files. Hovering over them, it says "view source in debug tab", Clicking on them, it goes to the debug tab but does not go to the right source (the JS file) rather it goes to the HTML file's source.

My app uses AngularJS & bootstraps, and loads the page in under a second, normally (In Chrome & in FF w/ no sourcemaps).

If I load it in FF with devtools open, it sometimes hangs for 40+ seconds at 100% CPU. My users got the same thing, but did not have devtools open. For me, it does not happen unless I have devtools open, and even then, only intermittently.

I can record in the "performance" section of FF devtools, and I see this 40+ seconds cost quite clearly. The trouble is I can't tell where the cost is coming from. In the default view, its attributed to tinymce.min.js, but as I zoom in with the profiler, it seems to show the 40+ second delay associated not to that script, but to my own code instead. Like I said, when I click it to go to that code, it doesn't work, the profiler seems broken. See screenshots:

http://imgur.com/EwFQ9yD,8EPnFWI
http://imgur.com/EwFQ9yD,8EPnFWI#1

If I close devtools & reload the page, it loads in under a second or so. If I open devtools, then reload, same results (works fine). If I visit the "debugger" tab, it shows all my source files right away, but reloading again results in another 40s delay. I also tried commenting out tinymce.min.js, but Firefox still freezes if I've loaded the debugger tab within the current devtools session. Its also happening to my users in production when I enable sourcemaps to debug live, my users do not use devtools. Devtools in FF is totally broken when used on my app. I'm not at liberty to post the code, it'd be a 12MB+ jsfiddle anyways. Its also happening on lots of websites, for example on imgur.com if I open "debugger" in devtools & then reload, it freezes firefox, I get prompted to kill the process/wait, and eventually the page loads & works fine.

I guess the TL;DR of my rant is this - this issue is real, it happens to me too, and I'm not sure why except that it seems to happen when using the "debugger" in devtools & reloading the page, or also seems to sometimes happen even without devtools open if I have a large JS file that contains inline sourcemaps at the end.

Comment 9

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to josh.ribakoff from comment #8)
> This is happening for me & my users, I'm in FF 39. It happens sometimes &
> not others. My JS file is also around 12MB, but is created via gulp &
> gulp-sourcemaps. When I use the "profile" tab, it shows links to my combined
> JS file & not to the original source files. Hovering over them, it says
> "view source in debug tab", Clicking on them, it goes to the debug tab but
> does not go to the right source (the JS file) rather it goes to the HTML
> file's source.

The profiler doesn't use source maps at the moment. It is being worked on in https://bugzilla.mozilla.org/show_bug.cgi?id=923396 and dependent bugs.

> If I load it in FF with devtools open, it sometimes hangs for 40+ seconds at
> 100% CPU. My users got the same thing, but did not have devtools open. For
> me, it does not happen unless I have devtools open, and even then, only
> intermittently.

How many megabytes big is your source map? On my machine we are parsing 16Mb source maps in just over 2 seconds, and that is a relatively large source map. There were a few speed ups to source map parsing that I don't think have made their way to the main release channel yet. Can you try on dev edition or nightly?

Is the source map embedded as a data URI within the js script or at a remote URL?

Comment 10

[Ian Bentley]

I still see this behaviour with FF 39.0.  This is not a problem related to minor speed ups, something more severe is happening here.

There are 3 Sourcemaps on the page two ~8.5m, one 67k.  Sourcemap is embedded as a data URI in each.

Upon opening debug for the first time sourcemap resolves quickly < 5s.  A refresh causes a CPU to spike to 100% for ~30s-1m.  Closing dev tools, and refreshing occurs in normal time.

Can I capture any data from while this runs to assist in bug hunting?  It's difficult for me to create  a minimal testcase because every test takes over 1m to run.

Comment 11

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to Ian Bentley from comment #10)
> I still see this behaviour with FF 39.0.  This is not a problem related to
> minor speed ups, something more severe is happening here.

Can you also try in one of Beta, Dev Edition, or Nightly? I take your word that this is severe (a minute is quite a long time and very suboptimal) but I somewhat recently shaved off 75% of source map parsing time and it hasn't quite made its way to release yet. I would be very interested to know if the hang drops to about 15-20 seconds in newer releases, as that would indicate that we are spending most of our time parsing the source map here.

> There are 3 Sourcemaps on the page two ~8.5m, one 67k.  Sourcemap is
> embedded as a data URI in each.
> 
> Upon opening debug for the first time sourcemap resolves quickly < 5s.  A
> refresh causes a CPU to spike to 100% for ~30s-1m.  Closing dev tools, and
> refreshing occurs in normal time.

Just open -> refresh? Are you doing open -> set breakpoint -> refresh by chance?

> Can I capture any data from while this runs to assist in bug hunting? 

Thanks for offering to help. You can use the browser toolbox[1] to get an instance of the devtools scoped to the whole browser and then use the performance tool to record a profile of what is happening when you open the normal page-scoped devtools / refresh / whatever is triggering the hang. You can then save the profile as an attachment to this bug (if the profile is really big, you may need to gzip it first).

[1] https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox

> It's difficult for me to create  a minimal testcase because every test takes over
> 1m to run.

Yeah, that's most likely because this is related to the size of the source maps which is related to the size of the code.

If you can share your non-minimal test case, that would help as well.

Thanks!

Comment 12

[josh.ribakoff]

(In reply to Nick Fitzgerald [:fitzgen][:nf] from comment #9)
> (In reply to josh.ribakoff from comment #8)
> The profiler doesn't use source maps at the moment. It is being worked on in
> https://bugzilla.mozilla.org/show_bug.cgi?id=923396 and dependent bugs.
> 

That is fine, however that's not what I meant. I would expect it to take me to the correct line within my combined JS. Instead, it just takes me to the "debugger" tab without going to any JS file at all.

> How many megabytes big is your source map? On my machine we are parsing 16Mb
> source maps in just over 2 seconds, and that is a relatively large source
> map. There were a few speed ups to source map parsing that I don't think
> have made their way to the main release channel yet. Can you try on dev
> edition or nightly?

The total JS file is 12MB including the sourcemap, which results in 40 seconds of 100% cpu exactly. If I repeat the steps on google.com or yahoo.com, there is no CPU spike, but on imgur.com it spikes to 100% cpu for about 15 seconds (if I open "debugger" then press reload). This should suffice for a test case, no?
 
> Is the source map embedded as a data URI within the js script or at a remote
> URL?

Embedded.

(In reply to Nick Fitzgerald [:fitzgen][:nf] from comment #11)
> (In reply to Ian Bentley from comment #10)
> > I still see this behaviour with FF 39.0.  This is not a problem related to
> > minor speed ups, something more severe is happening here.

I agree.

> > Upon opening debug for the first time sourcemap resolves quickly < 5s.  A
> > refresh causes a CPU to spike to 100% for ~30s-1m.  Closing dev tools, and
> > refreshing occurs in normal time.

This is exactly the behavior I'm seeing as well.
 
> Just open -> refresh? Are you doing open -> set breakpoint -> refresh by
> chance?

Yes, just that. No, no breakpoints.

> Yeah, that's most likely because this is related to the size of the source
> maps which is related to the size of the code.

Yes, it appears that on websites where this occurs, the CPU spike happens for a duration of time proportional to the size of the JS file & sourcemap. It does not happen on all websites though.

Comment 13

[Ian Bentley]

Attachment: Browser Toolkit run of page refresh that too 160s

Comment 14

[Ian Bentley]

Attachment: The same test done on Firefox Beta

Comment 15

[Ian Bentley]

One thing that has changed since I originally filed this ticket is that when you first open the debug console it doesn't hang.  It only hangs after the first refresh.  No idea about what may have changed, but I'm including this here for completeness.

Comment 16

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Thanks for the profiles. Right off the bat, something funny is going on because I see source map's mappings parsing in there, but that shouldn't happen unless a breakpoint is actually set.

The jank when refreshing imgur.com with the debugger open was unrelated to source maps. I just landed a couple patches that take it from two big ~2000ms janks to a period of about 1000ms where we are dropping a lot of frames but largely remaining somewhat responsive rather than beach balling altogether. Profiling imgur refresh without debugger doesn't look super different.

https://bugzilla.mozilla.org/show_bug.cgi?id=1189694
https://bugzilla.mozilla.org/show_bug.cgi?id=1189677
https://bugzilla.mozilla.org/show_bug.cgi?id=1189664

Comment 17

[Kanchan Kumari QA]

Removing the 'Testcase-wanted' keyword as test case has been provided by Ian.

Comment 18

[Loic]

Ian, is it still an issue with FF44 or Nightly?

Comment 19

[Ian Bentley]

The performance is significantly improved, to a point where it's very usable now.

Feel free to close out this ticket.

Comment 20

[dan.leahu]

I'm still having this with Firefox 50.1.0, GWT 2.8 and a 12MB sourcemap. 

Was there anything that you did specifically apart from just retrying on a newer version of Firefox?

Comment 21

[Loic]

(In reply to dan.leahu from comment #20)
> I'm still having this with Firefox 50.1.0, GWT 2.8 and a 12MB sourcemap. 
> 
> Was there anything that you did specifically apart from just retrying on a
> newer version of Firefox?

Could you file a new bug report and a testcase, please.

Comment 22

[Julien BETI]

I do have the issue with Firefox Developer Edition 55.0b14 (64bits) on Linux Fedora 25, with a quite heavy application (SourceMap: 32MB). The application performs well without devtools opened.

When opening the debugger, it loads all the webpack:///scripts in the left pannel, which takes around 30 seconds, then it automatically selects the fist one. At this moment, "loading..." is displayed on the main panel and Firefox freezes for about a minute, and then it crashes: the developer panel is closed and "Gah. Your tab just crashed" is displayed in the tab. It is then impossible to use nor close Firefox, it have to be killed.

I don't know how to efficiently produce a test case as it obviously happens only with big sourcemaps, but I do think this issue should be re-opened, as Firefox cannot be used as development browser anymore for this kind of apps.

Comment 23

[ich]

For others arriving here with similar issues:

I experienced such issues with webpack and dataurl sourcemaps when there was a bug in the package loading of the framework I used (**openui5** is that framework).

The reason was a regexp that parsed the sourceMappingURL for resolving relative paths if needed. This regexp slowed the loading time with similar symptoms, since the regexp checker needed to run through the whole dataurl content. Running the profile gave clear hint on what was happening.

Issue in UI5: https://github.com/SAP/openui5/issues/1915