Ian Gilman [:iangilman] Reporter
	Description • 14 years ago

Someone I was discussing TabCandy integration with (I forget whom, unfortunately) suggested: 

* All of TabCandy should become a jsmodule rather than being loaded on a page: https://developer.mozilla.org/en/Using_JavaScript_code_modules 

Knowing what we know now, is this a good idea? If so, how do we proceed?

	Ed Lee :Mardak Assignee
	Comment 1 • 14 years ago

A jsmodule script only gets loaded once no matter how many times you Cu.import it, so it's also able to keep state across multiple imports. If we go down this path, we'll probably want to expose a callback to handle the tabcandy page load.

Also, modules get to export certain objects, so we can export just one or multiple. I'm not sure if we want to keep doing the #include into tabcandy.js or import multiple files that each exposes a top-level object.

This also means no implicit access to the window object and modifications to objects are local, e.g., Object.prototype changes.

	Raymond Lee [:raymondlee]
	Comment 2 • 14 years ago

Js code module is used to create a *true* global JavaScript singleton.  I see that there are objects like Storage, TabItem, Item, etc don't need to exist in each browser window, and can be shared across windows using JS code modules.  UI related code can remain as they are and other service object (e.g. Storage) and data transfer objects (i.e. TabItem, Item, etc) can be converted into JS code modules.

	Ed Lee :Mardak Assignee
	Comment 3 • 14 years ago

Jsmodules also let you import/export only certain objects, so each file only needs to import scripts that it actually depends on, and we no longer need to make sure we have the right ordering of scripts.

We could just have one top-level script get imported from tabcandy.html, and the various dependent scripts will get loaded as necessary. We'll just need to have a TabCandy.load(window) or something to handle ui view loading.

	Aza Raskin [:aza]
	Comment 4 • 14 years ago

Do we have resolution here. It sounds like there is a proposal to use Jsmodules for some of the core functionality, but keep the Tabcandy page and per-window instantiation of Tabcandy as a non-Jsmodule. Am I understanding the proposal correctly? Also do we want to bother making the change? Is it required for landing on trunk?

	Michael Yoshitaka Erlewine [:mitcho]
	Comment 5 • 14 years ago

(In reply to comment #4)
> Do we have resolution here. It sounds like there is a proposal to use Jsmodules
> for some of the core functionality, but keep the Tabcandy page and per-window
> instantiation of Tabcandy as a non-Jsmodule. Am I understanding the proposal
> correctly? Also do we want to bother making the change? Is it required for
> landing on trunk?

I think part of this decision depends on whether TabCandy is global across windows or not. If TabCandy is global across windows, a JSM has the advantage that JSM-ed singleton objects would be the exact same across imports, as they're cached. If TabCandy is not global across windows, we would simply have to restructure the JSM's a bit so that we make sure only the classes (prototypes) or factory functions are in the JSM, and the actual singletons are tied to the window.

Either way, though, I'm all for JSMing.

	Ed Lee :Mardak Assignee
	Comment 6 • 14 years ago

Right. The code currently seems to be structured to have function constructor+prototype and immediately creating an instance to attach to window.<foo>.

We'll probably want to just EXPORTED_SYMBOLS the constructor and create the global instances from tabcandy.html/.js.

Some files have different initialization paths though like core/mirror.js creates a local closure to declare TabMirror to then export it to window.TabMirror. Seems like it's just trying to keep its privates private. Not sure how important that is, but having a local variable in a module that doesn't get exported does the same thing.

	Ian Gilman [:iangilman] Reporter
	Comment 7 • 14 years ago

So do we need to do this before submitting for review?

	Ed Lee :Mardak Assignee
	Comment 8 • 14 years ago

If the decision is to have tabs across all windows managed by tabcandy in bug 578033, it would be useful to share some state through jsmodules instead of recreating the tab structure/data across all open windows.

There's still a separate issue if making sure tabcandy ui stays in sync if one window repositions a tab/group.

	Aza Raskin [:aza]
	Comment 9 • 14 years ago

It sounds like we do not need to do this before submitting for review, though we do know that we want all windows to be managed by tabcandy. Is it possible to begin doing this work before knowing the exact spec for how tabcandy ui stays in sync? Does knowing that exact spec help?

	Ed Lee :Mardak Assignee
	Comment 10 • 14 years ago

Without it being in a module, we'll need some way to keep the ui/groups in sync. I believe if we just do the one-step of gathering all-windows' tabs instead of one-window's tabs, each tabcandy view in each window will end up with its own grouping/arrangement of tabs.

	(no longer active)
	Comment 11 • 14 years ago

Mass moving all Tab Candy bugs from Mozilla Labs to Firefox::Tab Candy.  Filter the bugmail spam with "tabcandymassmove".

	Michael Yoshitaka Erlewine [:mitcho]
	Comment 12 • 14 years ago

Punting to the future.

	Paul [pwd]
	Comment 13 • 13 years ago

What happened with this? It seems to have died despite being able to fix some of the usability issues that Panorama faces. Is this bug now WONTFIX?

	Tim Taubert [:ttaubert] (inactive)
	Comment 14 • 13 years ago

(In reply to Paul [sabret00the] from comment #13)
> What happened with this? It seems to have died despite being able to fix
> some of the usability issues that Panorama faces. Is this bug now WONTFIX?

I guess we'd still consider this bug but we'll have to refactor some underlying stuff first. When addressing bug 578512 this might come in handy.

	Dão Gottwald [:dao]
	Comment 15 • 13 years ago

More precisely, this mostly only makes sense together with bug 578512, imho. As long as there's a strong panorama <-> browser window link, using JS modules seems pointless.

	Tim Taubert [:ttaubert] (inactive)
	Comment 16 • 12 years ago

Moving the TabGroups logic into a JSM would definitely still make sense but we have no plans to do that. So, WONTFIX.