ScreenProxy syncIPCs to the parent process

RESOLVED DUPLICATE of bug 1194751

Status

()

defect
RESOLVED DUPLICATE of bug 1194751
3 years ago
3 years ago

People

(Reporter: Ehsan, Unassigned)

Tracking

(Blocks 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Instead of in a profile, I noticed this in a shutdown crash (bp-c8283550-4b6c-41dc-8ec2-f31522170124) where we get killed while this sync IPC is in progress.

The coding pattern here is very interesting.  the getters all call ScreenProxy::EnsureCacheIsValid() where we do the sync IPC, remember these results, and then call InvalidateCacheOnNextTick() which clears the cache when we're done processing the current runnable!  I guess this avoids doing several sync IPC calls per runnable, but... surely the cached data is not actually stale at each frame.

Also, this is the kind of thing where instead of sync IPCing to the parent, we should get the parent to notify the child asynchronously when the screen info changes (which should be quite rare).

Mike, any idea what's going on here?
Flags: needinfo?(mconley)
Yep, this is a dupe of bug 1194751.

We should basically do exactly what you're describing: when a TabChild is created, have it be told the screen dimensions that it belongs to, and have it cache them. If the associated TabParent's FrameLoader is moved to a new display, send down an update message asynchronously.

I take full blame on having taken this synchronous approach - it was one of the first things I did for the e10s project, and was probably one of the first major things I wrote that wasn't in /browser, so I was pretty green. :/
Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(mconley)
Resolution: --- → DUPLICATE
Duplicate of bug: 1194751
No worries, thanks for looking at this!
You need to log in before you can comment on or make changes to this bug.