889530 - Source maps are permanently cached

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P3)

Description

[Thomas Andersen]

Attachment: dev-tools-tests5.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:25.0) Gecko/20130702 Firefox/25.0 (Nightly/Aurora)
Build ID: 20130702031131

Steps to reproduce:

Using 25.0a1 (2013-07-02)

1. Unizip the attached zip to a standard apache http server public folder
2. Open the debugger and check the Show original sources in the debugger's configuration menu
2. With the browser navigate to http://localhost/~{$user}/path/to/dev-tools-tests5/
3. Everything is working as expected. The .ts file is displayed in the source list etc.
4. Rename the file dev-tools-tests5/ts/Greeter.ts to dev-tools-tests5/ts/Greeter2.ts
5. Recompile  tsc ts/* --sourcemap --out ./all.js
6. Refresh the test case

If you do not have the TypeScript compiler at hand I guess you can:

4. Rename the file dev-tools-tests5/ts/Greeter.ts to dev-tools-tests5/ts/Greeter2.ts
5. Manually manipulate the sources property in all.js.map

I guess this also applies to eg. Coffee Script




Actual results:

After the renaming and re-compiling, the debugger tries to load ts/Greeter.ts resulting with a 404 response in the source code view


Expected results:

The debugger should have loaded ts/Greeter2.ts

Comment 1

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

We haven't been loading the original sources from cache since bug 865252, but we are loading the source map from cache which points at the old source.

I suspect just changing http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/script.js#2655 to pass in { loadFromCache: false } to |fetch|'s will fix this problem.

Comment 2

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

Attachment: bug-889530-source-maps-cached.patch

https://tbpl.mozilla.org/?tree=Try&rev=002dab4ea743

Comment 3

[Victor Porof [:vporof][:vp]]

Comment on attachment 793687 [details] [diff] [review]
bug-889530-source-maps-cached.patch

Review of attachment 793687 [details] [diff] [review]:
-----------------------------------------------------------------

r+ with green try run.

Comment 4

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

New try push with the actual patch: https://tbpl.mozilla.org/?tree=Try&rev=4e4cdc68463d

Comment 5

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

Grrr, tests pass locally, but it looks like bug 907839 is bigger than I thought and NetUtil.asyncFetch won't grab .json files in xpcshell tests on some platforms or something. It passes locally :-/

(Removing other dep because it only depends on that bug to avoid test file name clashes).

Comment 6

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

Still working locally. Here's another try push, this time with some logging so if it fails on try, maybe we can get some incite into why.

https://tbpl.mozilla.org/?tree=Try&rev=0c6c210b0668

Comment 7

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

I think that this isn't actually asyncFetch's fault, but when we access the contentType of the request it goes through nsBlocklistService. New attempt: https://tbpl.mozilla.org/?tree=Try&rev=14cd44de9519

Comment 8

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

Attachment: bug-889530-source-maps-cached.patch

After talking with bz, figured out that attempting to get the content type of an unknown extension was the fault here, so I renamed the source map with .txt.

https://tbpl.mozilla.org/?tree=Try&rev=05a22066479b

Comment 9

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

https://hg.mozilla.org/integration/fx-team/rev/668d5c3eec49

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/668d5c3eec49