Closed
Bug 1506718
Opened 6 years ago
Closed 6 years ago
Console evaluation fails (JSPropertyProvider)
Categories
(Core Graveyard :: Web Replay, defect, P1)
Core Graveyard
Web Replay
Tracking
(firefox65 fixed)
RESOLVED
FIXED
mozilla65
Tracking | Status | |
---|---|---|
firefox65 | --- | fixed |
People
(Reporter: jlast, Assigned: bhackett1024)
References
Details
Attachments
(1 file)
992 bytes,
patch
|
loganfsmyth
:
review+
|
Details | Diff | Splinter Review |
STR:
1. go to https://firefox-dev.tools/debugger-examples/examples/todomvc/
2. start recording
3. add a breakpoint in todo-view.js#54
4. pause at 54
5. evaluate this.$el in the console
> Handler function JSPropertyProvider threw an exception: Error: [Exception... "Factory not registered" nsresult: "0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED)" location: "JS frame :: http://localhost:7999/todomvc/js/views/todo-view.js :: render :: line 54" data: no]
> Stack: ThrowError@resource://devtools/server/actors/replay/debugger.js:783:17
> _sendRequest@resource://devtools/server/actors/replay/debugger.js:93:7
> _sendRequestAllowDiverge@resource://devtools/server/actors/replay/debugger.js:104:12
> _ensureNames@resource://devtools/server/actors/replay/debugger.js:738:21
> names@resource://devtools/server/actors/replay/debugger.js:750:5
> getProperties@resource://devtools/shared/webconsole/js-property-provider.js:708:19
> getMatchedPropsImpl@resource://devtools/shared/webconsole/js-property-provider.js:582:19
> getMatchedPropsInEnvironment@resource://devtools/shared/webconsole/js-property-provider.js:538:10
> JSPropertyProvider@resource://devtools/shared/webconsole/js-property-provider.js:374:16
> exports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:109:14
> autocomplete@resource://devtools/server/actors/webconsole.js:1208:22
> onPacket@resource://devtools/server/main.js:1324:15
> receiveMessage@resource://devtools/shared/transport/child-transport.js:66:5
> enter@resource://devtools/server/actors/utils/event-loop.js:118:5
> _pushThreadPause@resource://devtools/server/actors/thread.js:188:5
> _pauseAndRespond@resource://devtools/server/actors/thread.js:496:7
> pauseAndRespond@resource://devtools/server/actors/thread.js:743:52
> _makeOnStep/<@resource://devtools/server/actors/thread.js:667:16
> setReplayingOnStep/</<@resource://devtools/server/actors/replay/debugger.js:561:17
> Line: 783, column: 17
Reporter | ||
Updated•6 years ago
|
Priority: -- → P1
Assignee | ||
Comment 1•6 years ago
|
||
This patch fixes the error logged to the console, and allows autocomplete to work when evaluating things in the console. I haven't seen the problem of the console going blank when doing this evaluation so don't know if that will be fixed.
When getting names in the environment (presumably to populate data for the autocomplete) we would throw an exception that was originally thrown within the Debugger.Env in the replaying process. This exception is probably happening because we don't load new JS components after diverging from the recording (if we tried then the whole debugger operation would fail).
This patch avoids throwing exceptions entirely when getting environment names by returning a bogus value. A (maybe better) alternative would be to handle this separately at call sites in the debugger server, but doing things this way is simpler and is consistent with similar handling in other fallible ReplayDebugger operations.
Assignee: nobody → bhackett1024
Attachment #9026533 -
Flags: review?(lsmyth)
Comment 2•6 years ago
|
||
Comment on attachment 9026533 [details] [diff] [review]
patch
Review of attachment 9026533 [details] [diff] [review]:
-----------------------------------------------------------------
Seems reasonable.
Would we want to log what the error is to help tracing issues, or would that already be logged elsewhere or not worth it?
Attachment #9026533 -
Flags: review?(lsmyth) → review+
Assignee | ||
Comment 3•6 years ago
|
||
(In reply to Logan Smyth [:loganfsmyth] from comment #2)
> Comment on attachment 9026533 [details] [diff] [review]
> patch
>
> Review of attachment 9026533 [details] [diff] [review]:
> -----------------------------------------------------------------
>
> Seems reasonable.
>
> Would we want to log what the error is to help tracing issues, or would that
> already be logged elsewhere or not worth it?
There won't be any logging associated with this. Would it be OK to just dump() a message to stderr, or is there a better way?
Pushed by bhackett@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3578632557aa
Tolerate exceptions being thrown when getting environment names, r=lsmyth.
Comment 5•6 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox65:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
Updated•5 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•