Via Twitter: https://twitter.com/karfcz/status/758764842354413568 Only the first log for test case logs the source mapped location -- subsequent logs use the generated URL. STR: 1: Visit http://www.karf.cz/temp/sourcemaps-test/tpl/sourcemaps-test.html 2: Click test 1 or test 2 and see the source mapped location log 3: Click a button again ER: The subsequent logs should also have a source mapped location AR: The subsequent logs reference the generated URL.

Karel mentioned this working after a refresh, but I was not able to get any different results after refreshing.

While recreating this bug, this is what I encountered: There is a bunch of logs which happen in the console that are CSS logs (not related to JavaScript). So the first resolve attempt tries to resolve the CSS location. Therefore attempting a first resolve doesn't trigger a "source-updated" event. So source-mapping for JavaScript actually never happens. If you refresh with the console open, the "source-updated" event is triggered now. However, in this case, there is a race condition. The "source-updated" event is trigger before the FrameView tries to subscribe the callback to those locations. And hence it is not source-mapped on the "source-updated" event. When the FrameView component subscribes to the location for the first JavaScript log, it only source-maps the first log and doesn't source-map anything else. This is because the first resolve attempt is only to trigger the "source-updated" event from the toolbox and source-mapping for subsequent logs is supposed to occur after "source-updated" event happens. For this bug, I was able to solve the problem "source-updated" event race condition. And also the service now resolves the first JavaScript console log which it encounters. And therefore it should work nicely without having to remove those optimizations.

Comments for previous still apply.

Based on our discussion, in this patch, we attempt to resolve each location when the FrameView component tries to subscribe to the service.

Comment on attachment 8777537 [details] [diff] [review] 1290263.patch [3.0] Review of attachment 8777537 [details] [diff] [review]: ----------------------------------------------------------------- ::: devtools/client/framework/source-map-service.js @@ +69,5 @@ > * @param callback > */ > SourceMapService.prototype.unsubscribe = function (location, callback) { > this.off(serialize(location), callback); > + if (this._locationStore) { Add a comment here that sometimes unsubscribes happen during the destruction cascades and that this just protects against it, but maybe should be looked into more in the future

Pushed by cbook@mozilla.com: https://hg.mozilla.org/integration/fx-team/rev/78d61dcf3faf Source maps in console don't work after first log; r=jsantell

I had to back this out in https://hg.mozilla.org/integration/fx-team/rev/a0a49732aeb4 for test failures like https://treeherder.mozilla.org/logviewer.html#?job_id=10970479&repo=fx-team

Fixed the test failing on try.

Pushed by kwierso@gmail.com: https://hg.mozilla.org/integration/fx-team/rev/4fb7850312d5 Source maps in console don't work after first log; r=jsantell

Maybe we want to uplift this and subsequent the patches, working on Source Maps, at least up to Firefox 50?

I have reproduced this bug with Firefox nightly 50.0a1(build id:20160728030208)on windows 7(64 bit) I have verified this bug as fixed with Firefox nightly 51.0a1(build id:20160822064441) User Agent:Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 [bugday-20160824]