Closed
Bug 900231
Opened 11 years ago
Closed 10 years ago
Tracer breaks on tab navigation / reload
Categories
(DevTools :: Debugger, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
Firefox 34
People
(Reporter: rjacob, Assigned: jjurovych)
References
Details
Attachments
(1 file, 2 obsolete files)
16.39 KB,
patch
|
Details | Diff | Splinter Review |
After navigation, the Debugger API hooks for attached trace actors are no longer called. The trace actor can only be used on the new page by detaching and re-attaching the client, causing the actor to initialize a new Debugger instance.
Reporter | ||
Comment 1•11 years ago
|
||
http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/webbrowser.js#825 It might make sense to replace DebuggerProgressListener with a more general ProgressListener, which emits events instead of the threadActor-specific behavior. Thread actors and extra actors interested in tabNavigated events could listen to these events.
Comment 2•11 years ago
|
||
The current listener is a result of merging the debugger's and console's listeners to have a single point where tabNavigated protocol events are fired. Can't the trace actor also add it's own housekeeping stuff in there? If you meant that we should have actors attach listeners to the progress listener for decoupling purposes, that would work too, but note that there are quite a few corner cases in that code that we must make sure are still handled properly.
Reporter | ||
Comment 3•11 years ago
|
||
That's what I meant, yeah. It seems a little awkward to just add traceActor housekeeping there since it's added as an extra actor.
Comment 5•10 years ago
|
||
I think we might want to just end up moving the tracer actor into script.js, as much as I hate to say it. Would also make bug 949754 and bug 949762 easier.
Updated•10 years ago
|
Assignee: nobody → nfitzgerald
Comment 6•10 years ago
|
||
Actually I think this is a Debugger API bug. I don't think onEnterFrame gets called after page reloads.
Comment 7•10 years ago
|
||
(In reply to Nick Fitzgerald [:fitzgen] from comment #6) > Actually I think this is a Debugger API bug. I don't think onEnterFrame gets > called after page reloads. Nevermind... This bug is leaving me completely bewildered. We shouldn't need to instantiate new Debugger objects for each reload. I have no idea why our onEnterFrame isn't being called after refreshes.
Comment 8•10 years ago
|
||
Updated•10 years ago
|
Status: NEW → ASSIGNED
Component: Developer Tools → Developer Tools: Debugger
Summary: Trace actor needs to be detached/reattached after tab navigation → Tracer breaks on tab navigation / reload
Comment 9•10 years ago
|
||
Hmmm, refreshing, stopping the tracer and restarting it, you still don't get anything.
Comment 10•10 years ago
|
||
Finally figured out the issue. Needed to update the |TraceActor|'s |this.global| and call |this.globalManager.findGlobals| every time a new window is created. This patch has the tracer tests passing when run individually, but when run as part of the whole debugger mochitest suite they fail. Blech.
Attachment #8350425 -
Attachment is obsolete: true
Comment 11•10 years ago
|
||
Getting a bunch of weird dead object errors, and the tab actor is missing its browser property, but exit isn't being called...
Updated•10 years ago
|
Priority: -- → P3
Updated•10 years ago
|
Assignee: nfitzgerald → nobody
Assignee | ||
Comment 12•10 years ago
|
||
I have tried to update the patch and resolve conflicts. The tests seem to pass, but tracer still doesn't work correctly. Right now, tracer will run only on a page where DevTools was opened for the first time. This results in some interesting behaviors: a) 1. Go to page A. 2. Open DevTools. 3. Run tracer, it works. b) 1. Go to page A. 2. Open DevTools. 3. Go to page B in a NEW tab. 4. Open DevTools. 5. Run tracer on page B, it doesn't work. 6. Run tracer on page A, it works. c) 1. Go to page A. 2. Open DevTools. 3. Go to page B in the SAME tab. 4. Run tracer, it doesn't work. 5. Go back to page A. 6. Tracer is already running and works. When the first "traces" packet is sent (the first packet after "startedTrace"), I get this error: > DBG-SERVER: Got an exception: metadata is undefined > ThreadActor.prototype.globalManager.onNewGlobal@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/script.js:714:9 > ClickEventHandler.handleEvent@chrome://browser/content/content.js:265:9 Tracer stops working after a refresh. When I refresh the page and start the tracer, "traces" packets are no longer being sent, just this error shows up. I also got this error once, but cannot reproduce it anymore: > Handler function threw an exception: TypeError: this.traceClient is undefined > Stack: Tracer.prototype.startTracing@chrome://browser/content/devtools/debugger-controller.js:1509:5 > TracerView.prototype<._onStartTracing@chrome://browser/content/devtools/debugger-panes.js:1227:5 > makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:83:14 > TracerView.prototype<._onToggleTracing@chrome://browser/content/devtools/debugger-panes.js:1208:7 > makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:83:14 I will continue working on this tomorrow.
Attachment #8356342 -
Attachment is obsolete: true
Updated•10 years ago
|
Assignee: nobody → jjurovych
Comment 13•10 years ago
|
||
In bug 1039952 I'm refactoring the way we manage debuggee globals, and after that lands I think fixing this will be a lot easier.
Depends on: 1039952
Assignee | ||
Comment 14•10 years ago
|
||
Looks like Bug 1039952 fixed this.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Updated•10 years ago
|
Target Milestone: --- → Firefox 34
Updated•10 years ago
|
QA Whiteboard: [qa-]
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•