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

Status: RESOLVED DUPLICATE of bug 1081879

(Firefox :: Extension Compatibility, defect)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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.

Comment 2

[Ian Nartowicz]

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?