577322 - Make TabCandy a jsmodule?

Status: RESOLVED WONTFIX

(Firefox Graveyard :: Panorama, defect, P2)

Description

[Ian Gilman [:iangilman]]

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?

Comment 1

[Ed Lee :Mardak]

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.

Comment 2

[Raymond Lee [:raymondlee]]

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.

Comment 3

[Ed Lee :Mardak]

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.

Comment 4

[Aza Raskin [:aza]]

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?

Comment 5

[Michael Yoshitaka Erlewine [:mitcho]]

(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.

Comment 6

[Ed Lee :Mardak]

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.

Comment 7

[Ian Gilman [:iangilman]]

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

Comment 8

[Ed Lee :Mardak]

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.

Comment 9

[Aza Raskin [:aza]]

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?

Comment 10

[Ed Lee :Mardak]

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.

Comment 11

[(no longer active)]

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

Comment 12

[Michael Yoshitaka Erlewine [:mitcho]]

Punting to the future.

Comment 13

[Paul [pwd]]

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?

Comment 14

[Tim Taubert [:ttaubert] (inactive)]

(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.

Comment 15

[Dão Gottwald [:dao]]

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.

Comment 16

[Tim Taubert [:ttaubert] (inactive)]

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