Closed Bug 1132474 Opened 6 years ago Closed 6 years ago

TabTarget#getActorDescription should explain in more detail its restrictions

Categories

(DevTools :: Framework, defect)

37 Branch
x86
macOS
defect
Not set
normal

Tracking

(firefox39 fixed)

RESOLVED FIXED
Firefox 39
Tracking Status
firefox39 --- fixed

People

(Reporter: jsantell, Assigned: jsantell)

Details

Attachments

(1 file)

Currently, `actorHasMethod` calls getActorDescription, which is only available after the actor registers itself. If the actor exists (available sync via client properties), we should poll until we find an actor description for the actor.

Ran into this using FxOS 2.2 (Gecko 37) where memory actor exists, but at time of performance tools opening, the actor description is not yet registered.
Status: NEW → ASSIGNED
Component: Developer Tools → Developer Tools: Framework
(In reply to Jordan Santell [:jsantell] [@jsantell] from comment #0)
> Currently, `actorHasMethod` calls getActorDescription, which is only
> available after the actor registers itself. If the actor exists (available
> sync via client properties), we should poll until we find an actor
> description for the actor.

I am a bit wary of polling in a loop (if that's what you mean)...

I hope we can devise a way to wait until the actor is known to exist and then call these methods as needed.
I've never ran into this before, as the description existed after the Front was loaded, but running into a different scenario on Fx2.2, and there is no event or any mechanism to say that the actor was loaded, AFAIK :[
(In reply to Jordan Santell [:jsantell] [@jsantell] from comment #2)
> I've never ran into this before, as the description existed after the Front
> was loaded, but running into a different scenario on Fx2.2, and there is no
> event or any mechanism to say that the actor was loaded, AFAIK :[

Is it possible to wait until you have the front in hand before calling |actorHasMethod|, or is it required to call this before that?
We had some lazy loaders in this case, so seeing if changing those/moving around will fix it :D
Possibly due to bug 988237, which lazily loads actors until first invocation. Only seen on B2G AFAICT. This doesn't solve the perf++ use case, but can still be used where one would use the actor anyway (rather than mock the entire front, which is unique to perf++).

Will investigate some more, but will not do polling.
No longer blocks: 1130202
Summary: TabTarget#getActorDescription should wait until actor is registered if actor exists → TabTarget#getActorDescription should explain in more detail its restrictions
Assignee: nobody → jsantell
Rather than changing the tab target methods, I further elaborated on their restrictions so others don't run into the same issues I did!
Attachment #8568049 - Flags: review?(jryans)
Comment on attachment 8568049 [details] [diff] [review]
1132474-tabtarget-descriptions.patch

Review of attachment 8568049 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, thanks!
Attachment #8568049 - Flags: review?(jryans) → review+
comments only patch
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/0d39893538fc
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 39
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.