Warn on rejected sourcemaps
Categories
(DevTools :: General, enhancement, P2)
Tracking
(Not tracked)
People
(Reporter: mbalfanz, Unassigned)
References
Details
(Whiteboard: [dt-q])
We recently updated our sourcemaps library. This causes some maps to be rejected that previously worked in Firefox and may work in other browsers. See bug 1520136 and bug 1519166 for examples.
DevTools should log warnings warnings if sourcemaps are invalid and/or rejected.
Comment 1•6 years ago
|
||
I agree with this, and this seems important.
We somehow need the error that is raised from within the source-map parsing worker to make it to the UI.
Here's where the worker throws errors for invalid maps:
https://searchfox.org/mozilla-central/source/devtools/client/shared/source-map/worker.js#2691
To test this, you can download the reduced test case linked from bug 1520136.
I think we might be able to do something like this:
-
try/catch around this line:
https://searchfox.org/mozilla-central/rev/60c4067b1cbb0f94d7dc2d7cdfa27ed579817fee/devtools/client/framework/source-map-url-service.js#265 -
also try/catch around this line:
https://searchfox.org/mozilla-central/rev/60c4067b1cbb0f94d7dc2d7cdfa27ed579817fee/devtools/client/framework/source-map-url-service.js#296
This should let us catch the various promise rejections and do whatever we want with the error.
One possibility would be to call the callback that consumers of the source-map-url-service subscribe, but with a different argument.
To be clearer, the rule-view subscribes to this service here:
https://searchfox.org/mozilla-central/rev/60c4067b1cbb0f94d7dc2d7cdfa27ed579817fee/devtools/client/inspector/rules/views/rule-editor.js#381
So, whenever a stylesheet url is resolved to its original location, the callback this._updateLocation
is executed.
This happens here: https://searchfox.org/mozilla-central/rev/60c4067b1cbb0f94d7dc2d7cdfa27ed579817fee/devtools/client/framework/source-map-url-service.js#301
When there is an error, we could call that same callback, but with just 1 argument, being the error object.
Or we could make it possible for subscribers to define 2 callbacks, 1 for normal use, and 1 for when errors occur. This might make the code clearer.
At the end of the day, this would allow us to bubble the error all the way up to the rule-view, and therefore mark the url in red, or underline, or something.
Updated•6 years ago
|
Updated•2 years ago
|
Description
•