Closed Bug 1118880 Opened 5 years ago Closed 4 years ago

[e10s] nsIWebProgress shim needs to be synchronous when used by add-ons

Categories

(Firefox :: Extension Compatibility, defect)

34 Branch
x86_64
Linux
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1081879
Tracking Status
e10s + ---

People

(Reporter: billm, Unassigned)

References

Details

Right now the nsIWebProgress shim notified the parent process of events like onStateChange  using an async message. After the message is sent, the content process moves on to other things. Consequently, if an add-on uses the .DOMWindow property of the nsIWebProgress, it may not get the result it expects. We should fix this problem by using a synchronous shim when an add-on is the one calling addProgressListener.

In addition, we should use our usual interposition tricks to ensure that .DOMWindow is not exposed to FF code, but only to add-on code.
Blocks: e10s
tracking-e10s: --- → ?
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1081879
The documentation still describes this as a limitation.  Possibly it is a limitation, but not the one described.  Now that the shim is synchronous, perhaps a performance warning not to sit in onStateChange() or onLocationChange() for too long?
See Also: → 1246077
You need to log in before you can comment on or make changes to this bug.