Locations with line=0 normally indicate that we have no line information for the location.
In this case, it is useless to query the sourcemap service from the Frame component.
Additionally check if column is 0 or 1 to be more confident that this is a default location.
Differential Revision: https://phabricator.services.mozilla.com/D281033
SmartTrace is actually consuming 1-based columns coming from ObjectActor grip
for JS Error object's stacktrace.
But it maps to 0-based columns as it relies on Debugger Frames components.
This is made uterly complicated as we also have to deal with source maps
and original locations which are 0-based as well.
Differential Revision: https://phabricator.services.mozilla.com/D263580
There was three issues:
* one specific to original source. We were asking to resolve the 1-based column to SourceMapURLService,
whereas it expects a 0-based column (fix made to savedFrameToLocation).
* then for all sources, we were trying to open the debugger from 1-based column for generated sources,
whereas the debugger expects 0-based column. (And original source were 0-based, but mapped from the wrong generated location...)
* log point were emiting CONSOLE_MESSAGE resource whose `frame` objects were using 0-based columns,
whereas regular console message resource were using 1-based columns (as they are pulled from Spidermonkey's SavedFrame
which is 1-based)
Also adapt the tracer to the new behavior of Frame component and acknowledge that frames
use 1-based numbers.
Differential Revision: https://phabricator.services.mozilla.com/D249065
To do this, we need to only have a single SourceMapGenerator instance for all
the inline scripts of an HTML file, for which we add mappings with offsets based
on where the inline script is in the HTML file.
To support that, we add a new prettyPrintInlineScript task, which takes a taskId
so we can have one SourceMapGenerator for a given taskId, that we then pass
to prettyFast.
A test is added to ensure different cases of inline scripts are pretty printed
as expected, that resulting console messages location are updated and that the
event tooltip in the inspector shows the pretty file as well.
`findColumnBreakpoint` helper was fixed to look into the correct location for
original file (which pretty-printed file are)
`assertLineIsBreakable` is modified to show the text of the line so it's easier
to debug failures.
Differential Revision: https://phabricator.services.mozilla.com/D170751
we directly use what's returned from the `Frame` component. We allow to pass
an extra `className` prop to it so we can still add the `message-location` class
that is used in the console.
Differential Revision: https://phabricator.services.mozilla.com/D142097
This simplifies the markup a bit, and hopefully could contribute to improve
layout and styling performance in the console.
Differential Revision: https://phabricator.services.mozilla.com/D142096
This revert the changes made in Bug 1587839, except the added test.
The safer fix to be uplifted is to only fix the original issue
in the SmartTrace component, where we remove any sourceId we might
have when creating the new mapped frame.
We also modify the browser_dbg-pretty-print-console test to ensure
clicking on a prettified location in the console does open the
debugger with the expected location.
Differential Revision: https://phabricator.services.mozilla.com/D50173
This revert the changes made in Bug 1587839, except the added test.
The safer fix to be uplifted is to only fix the original issue
in the SmartTrace component, where we remove any sourceId we might
have when creating the new mapped frame.
We also modify the browser_dbg-pretty-print-console test to ensure
clicking on a prettified location in the console does open the
debugger with the expected location.
Differential Revision: https://phabricator.services.mozilla.com/D50173
The sourceId is then used in the various places where we call the sourcemap service.
A test is added in the console to make sure that we do navigate to the mapped
location in the debugger.
Differential Revision: https://phabricator.services.mozilla.com/D49103
Adding a new opcional property to Frame.js, messageSource, which will allows us to know the source of the Message. We will be using this property to display the correct tooltip message.
Differential Revision: https://phabricator.services.mozilla.com/D38139
We want to go back to ESLint's default complexity level so that newly introduced code is checked for complexity.
At the same time, to make that work, we're excluding all of the more complex functions for now.
We should fix them: make them less complex, and remove the eslint-disable comment.
See bug 1553449 for more information about this.
Differential Revision: https://phabricator.services.mozilla.com/D32139
We want to go back to ESLint's default complexity level so that newly introduced code is checked for complexity.
At the same time, to make that work, we're excluding all of the more complex functions for now.
We should fix them: make them less complex, and remove the eslint-disable comment.
See bug 1553449 for more information about this.
Differential Revision: https://phabricator.services.mozilla.com/D32139
The SourceMapURLService has a subscribe and an unsubscribe
functions to respectively listen and stop listening for
source map changes on a given location (url + line + column).
The unsubscribe function need to be called with the same
parameters as the subscribe function, which means the consumer
need to keep a reference to the callback.
By making the subscribe function return the unsubscribe function,
this makes things a bit easier.
Differential Revision: https://phabricator.services.mozilla.com/D9784
The Punycode-encoded international domain names and URI-encoded filenames are
human-unreadable, so they should be displayed as human-readable Unicode text.
This commit decodes this kind of names in the Web Console.
MozReview-Commit-ID: 8AVLkdaQOh6
There wasn't anything done for this kind of resources, so the URL looked
like resource://devtools/shared/base-loader.js -> resource://devtools/path/to/file.js
and was causing issue in the onClick handler.
MozReview-Commit-ID: GUJOpjDX1zG
I believe this fixes all warnings except for one. This warning appears the first time the memory panel is selected:
"Warning: Failed prop type: Calling PropTypes validators directly is not supported by the `prop-types` package. Use `PropTypes.checkPropTypes()` to call them. Read more at http://fb.me/use-check-prop-types
in MemoryApp (created by Connect(MemoryApp))
in Connect(MemoryApp) (created by bound createElementWithValidation)
in bound createElementWithValidation
in Provider"
This appears to be an issue with `devtools/client/memory/app.js` but I will log a new bug for this.
MozReview-Commit-ID: 341zdQyfgrN
Alexandra Borovova