All users were logged out of Bugzilla on October 13th, 2018

come up with a labeling strategy for PContent::Msg_ParentActivated

NEW
Unassigned

Status

()

P3
normal
a year ago
5 months ago

People

(Reporter: froydnj, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
This is a reasonably common runnable, but we can't send it to SystemGroup, because the message actually pertains to a particular TabChild: we should be sending it to the TabChild's group instead.  Unfortunately, extracting the information on *which* TabChild we need from the message is...not easy.  Extracting a raw integer ID would be a little easier, and we could map that to a particular TabChild when determining the event target for the message itself.

Does that sound reasonable, or can you think of a better way?
Flags: needinfo?(wmccloskey)
This message used to be on PBrowser instead of PContent. I moved it to PContent in bug 1334572 because I was afraid that activating one window would also deactivate another window. I know that happened with the Activate/Deactivate messages. I don't know if it happens for ParentActivated. (I don't really know the specifics of what all these messages do.)

Maybe we could get away with moving just this message back to PBrowser? You'll know if it works based on whether we assert.

If not, then we'll have to somehow split the activation and deactivation into separate runnables. Bug 1334572 has more details on that.
Flags: needinfo?(wmccloskey)

Updated

a year ago
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.