913280 - Electrolysis: Refactor RemoteWebProgress

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Tom S [:evilpie]]

Attachment: WIP

As promised in Bug 910838. I refactor RemoteWebProgress to have a manager, that decide, which WebProgress should be used. There is one static WebProgress for the top-level. All the updating of browser variables is done in the manager as well.

Comment 1

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 800500 [details] [diff] [review]
WIP

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

\o/

::: toolkit/content/widgets/remote-browser.xml
@@ +55,5 @@
>                let jsm = "resource://gre/modules/RemoteWebProgress.jsm";
> +              let RemoteWebProgressManager = Components.utils.import(jsm, {})
> +                                              .RemoteWebProgressManager;
> +              this._remoteWebProgress = new RemoteWebProgressManager(this)
> +                                         .topLevelWebProgress;

nit: shorten Components.utils to Cu

::: toolkit/modules/RemoteWebProgress.jsm
@@ +92,3 @@
>    },
>  
> +  fixSSLStatusAndState: function (aStatus, aState) {

nit: this function should probably be "private", i.e. "_fixSSLStatusAndState"

Comment 2

[Tom S [:evilpie]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/3d72fcbf22a5

Comment 3

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/3d72fcbf22a5

Comment 4

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

Doesn't this patch mean that all top-level windows will share the same nsIWebProgress object? I thought the whole point was to use different objects for different windows.

Comment 5

[Tom S [:evilpie]]

No. Every top-level DOMWindow per browser still gets their own nsIWebProgress. Subframes always get a new object.

Comment 6

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

Oh, OK, I see. There's a new manager for each <browser>.