Reposting my comment to Marc for future reference: The overall scope, long term, is to have the urlbar components/modules usable in more than one field. Currently a lot of the code is a singleton and it only works with the single urlbar field. I started some time ago to do some of the work in https://bugzilla.mozilla.org/show_bug.cgi?id=1628016 (ad you can see from some of the fixed dependencies) that consisted mostly in making providers instantiatable, unifying some of the code, making some methods static... Then I started looking into the one-instance-per-input-field problem, with the WIP patch in https://bugzilla.mozilla.org/show_bug.cgi?id=1628016 that I didn't finish. The idea was to have the providersManager own the providers instances, so each providersManager has its own providers instances. Then I wanted each input field have its own providersManager... But there was a problem there, the urlbars in different windows often want to share some states. So I ended up thinking to have one providerManager per input type, where by input type I mean "urlbar", "searchbar", "virtual-reality bar" and so on... so the urlbar in different windows share the same providers manager, the (once coded) legacy search bars in different windows share their own manager. My WIP here was an initial attempt but it's likely unclean, and there may be a better way to do that. What you want is probably a providersManager getter in UrlbarInput that gets the right instance depending on the input DOM node id. Since js modules are unique per process, you could have a providersManagers' Manager (sorry for the ugly name) that has an id -> providersManager instance.Then it's pretty much matter of ensuring each provider doesn't store state in its global scope but rather keeps it in their instance.
Bug 1628016 Comment 7 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Reposting my comment to Marc for future reference: The overall scope, long term, is to have the urlbar components/modules usable in more than one field. Currently a lot of the code is a singleton and it only works with the single urlbar field. I started some time ago to do some of the work in bug 1628016 (ad you can see from some of the fixed dependencies) that consisted mostly in making providers instantiatable, unifying some of the code, making some methods static... Then I started looking into the one-instance-per-input-field problem, with the WIP patch here that I didn't finish. The idea was to have the providersManager own the providers instances, so each providersManager has its own providers instances. Then I wanted each input field have its own providersManager... But there was a problem there, the urlbars in different windows often want to share some states. So I ended up thinking to have one providerManager per input type, where by input type I mean "urlbar", "searchbar", "virtual-reality bar" and so on... so the urlbar in different windows share the same providers manager, the (once coded) legacy search bars in different windows share their own manager. My WIP here was an initial attempt but it's likely unclean, and there may be a better way to do that. What you want is probably a providersManager getter in UrlbarInput that gets the right instance depending on the input DOM node id. Since js modules are unique per process, you could have a providersManagers' Manager (sorry for the ugly name) that has an id -> providersManager instance.Then it's pretty much matter of ensuring each provider doesn't store state in its global scope but rather keeps it in their instance.
Reposting my comment to Marc for future reference: The overall scope, long term, is to have the urlbar components/modules usable in more than one field. Currently a lot of the code is a singleton and it only works with the single urlbar field. I started some time ago to do some of the work in bug 1628016 (ad you can see from some of the fixed dependencies) that consisted mostly in making providers instantiatable, unifying some of the code, making some methods static... Then I started looking into the one-instance-per-input-field problem, with the WIP patch here that I didn't finish. The idea was to have the providersManager own the providers instances, so each providersManager has its own providers instances. Then I wanted each input field have its own providersManager... But there was a problem there, the urlbars in different windows often want to share some states. So I ended up thinking to have one providerManager per input type, where by input type I mean "urlbar", "searchbar", "virtual-reality bar" and so on... so the urlbar in different windows share the same providers manager, the legacy search bars in different windows share their own manager. My WIP here was an initial attempt but it's likely unclean, and there may be a better way to do that. What you want is probably a providersManager getter in UrlbarInput that gets the right instance depending on the input DOM node id. Since js modules are unique per process, you could have a providersManagers' Manager (sorry for the ugly name) that has an id -> providersManager instance.Then it's pretty much matter of ensuring each provider doesn't store state in its global scope but rather keeps it in their instance.
Reposting my comment to Marc for future reference: The overall scope, long term, is to have the urlbar components/modules usable in more than one field. Currently a lot of the code is a singleton and it only works with the single urlbar field. I started some time ago to do some of the work in bug 1628016 (ad you can see from some of the fixed dependencies) that consisted mostly in making providers instantiatable, unifying some of the code, making some methods static... Then I started looking into the one-instance-per-input-field problem, with the WIP patch here that I didn't finish. The idea was to have the providersManager own the providers instances, so each providersManager has its own providers instances. Then I wanted each input field have its own providersManager... But there was a problem there, the urlbars in different windows often want to share some states. So I ended up thinking to have one providerManager per input type, where by input type I mean "urlbar", "searchbar", "virtual-reality bar" and so on... so the urlbar in different windows share the same providers manager, the legacy search bars in different windows share their own manager. My WIP here was an initial attempt but it's likely unclean, and there may be a better way to do that. What you want is probably a providersManager getter in UrlbarInput that gets the right instance depending on the input DOM node id. Since js modules are unique per process, you could have a providersManagers' Manager (sorry for the ugly name) that has an id -> providersManager instance Map. Then it's pretty much matter of ensuring each provider doesn't store state in its global scope but rather keeps it in their instance.
Reposting my comment to Marc for future reference: The overall scope, long term, is to have the urlbar components/modules usable in more than one field. Currently a lot of the code is a singleton and it only works with the single urlbar field. I started some time ago to do some of the work in bug 1628016 (ad you can see from some of the fixed dependencies) that consisted mostly in making providers instantiatable, unifying some of the code, making some methods static... Then I started looking into the one-instance-per-input-field problem, with the WIP patch here that I didn't finish. The idea was to have the providersManager own the providers instances, so each providersManager has its own providers instances. Then I wanted each input field have its own providersManager... But there was a problem there, the urlbars in different windows often want to share some states. So I ended up thinking to have one providerManager per input type, where by input type I mean "urlbar", "searchbar", "virtual-reality bar" and so on... so the urlbar in different windows share the same providers manager, the legacy search bars in different windows share their own manager. My WIP here was an initial attempt but it's likely unclean, and there may be a better way to do that. What you want is probably a providersManager getter in UrlbarInput that gets the right instance depending on the input DOM node id. Since js modules are unique per process, you could have a providersManagers' Manager (sorry for the ugly name) that has an id -> providersManager instance Map. Then it's pretty much matter of ensuring each provider doesn't store state in its global scope but rather keeps it in their instance.