My favorites | Sign in
Project Home Wiki Issues
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 4989: Separate global UI (browser.xul) from Firebug UI (firebugFrame.xul)
3 people starred this issue and may be notified of changes. Back to list
Status:  Started
Owner:  odva...@gmail.com
Cc:  sroussey, sebastia...@gmail.com
1.9
ui


Sign in to add a comment
 
Project Member Reported by odva...@gmail.com, Nov 18, 2011
Firebug UI is currently composed from two parts:

- Global UI running in the global (browser.xul) scope - Web Developer menu, page context menu, start button, ...
- Local UI running within Firebug iframe (firebugFrame.xul) - The main Firebug toolbar, all panels (panel.html), ...

These parts should be clearly separated in the architecture and global UI would perhaps deserve to live within separate dir/modules.

Essentially, local Firebug UI should not depend on global UI and the communication (mainly command events) should be based on events.

This clear separation should also help us to improve Firebug activation and e.g. delay Firebug load so, it doesn't slow down Firefox start up. Only the global UI needs to be applied at the beginning - local UI can be loaded at the first time the user actually needs it. Such support should be implemented as part of further report.

Upon some analysis (e.g. impact on extensions) we should decide whether such separation can be part of 1.9 beta or rather postponed to the next Firebug branch.

Honza

Nov 18, 2011
Project Member #1 odva...@gmail.com
Trying to identify all the global parts:

== browser.xul ==
* firebug/firefox/browserOverlayWithFrame.xul
* firebug/firefox/start-button/startButtonOverlay.xul
* firebug/firefox/start-button/startButton.css
* firebug/firefox/start-button/startButton.xml
* firebug/firefox/browserMenuOverlay.xul
* firebug/content/firebug.css
* firebug/content/trace.js
* firebug/content/legacy.js
* firebug/content/moduleConfig.js
* firebug/editor/external/editorsOverlay.xul
* firebug/editor/external/editorToContextMenu.js

== customizeToolbar.xul ==
* firebug/firefox/start-button/customizeToolbarOverlay.xul

== about.xul ==
* firebug/firefox/aboutOverlay.xul
* firebug/firefox/aboutOverlay.js

Anything missing?

---

Suggestions:

1) We could move all these pieces into: "firebug/firefox/ui/*" directory (some of the files could be split into two, e.g. firebug.css)

2) All these pieces need to be loaded at Firefox start up

3) browserMenuOverlay.xul is not complete, it's content is dynamically populated by firebugMenu.js. The (cloned) content comes from firebugMenuOverlay.xul. The cloning happens when "initializeUI" event is fired (ie. when Firebug UI is loading). That's wrong it needs to happen at Firefox startup and Firebug icon menu needs to do the cloning as soon as Firebug UI is actually loaded.

4) firebugMenuOverlay.xul "mainCommandSet" is directly calling a lot of Firebug.* and Firebug.chrome.* methods. That's also wrong, Firebug doesn't have to be loaded yet and so, these methods doesn't have to exist. All the command dispatching must go through a command-dispatcher that loads Firebug UI (firebugFrame.xul) at the first time any of these methods is used. This could help: https://developer.mozilla.org/en/XUL_Tutorial/Commands

---

Unless extensions are overlaying the start-button popup-menu, I wouldn't expect many problems with compatibility.

Thoughts?

Honza


Nov 18, 2011
#2 sebastia...@gmx.de
I agree, that things should be tightened up before we release the final version of 1.9.
Though if that has any effect on extensions, we'd better postpone this change to 1.10.

> Anything missing?
Is legacy.js really a global part?

> 1) We could move all these pieces into: "firebug/firefox/ui/*" directory (some of 
> the files could be split into two, e.g. firebug.css)
Sounds fine to me.

> 2) All these pieces need to be loaded at Firefox start up
Yes.

> 3) browserMenuOverlay.xul ...
Agree.

> 4) firebugMenuOverlay.xul ...
Sounds logical.

So generally spoken, the global parts should also work regardless of the local parts already being available.
My question is, if that needs changes in the way the activation works. If so, I am thinking of Haruytun, which wanted to change the activation code anyway. And then I'd say it would definitely be too late for 1.9.
But I'm not enough into the activation model so far, so I'd need to have a deeper look first to understand the coherences.

Sebastian
Nov 18, 2011
Project Member #3 odva...@gmail.com
> Though if that has any effect on extensions, we'd better postpone
> this change to 1.10.
That's why I am doing these analysis.

> Is legacy.js really a global part?
It's included in the global space and creating global FBL variable.

> So generally spoken, the global parts should also work regardless
> of the local parts already being available.
Roughly saying, the global parts must be available since the beginning since the represent the way how to access (open) Firebug. They need to:
- make sure Firebug is loaded when accessed the first time
- transfer all (command) event to Firebug

> My question is, if that needs changes in the way the activation works.
No

> If so, I am thinking of Haruytun, which wanted to change the activation
> code anyway. 
This issue is based on my email conversation with Haruytun.

> And then I'd say it would definitely be too late for 1.9.
I don't think this issue should impact the activation logic.

Honza

Nov 19, 2011
Project Member #4 sroussey
Conceptually, we really have three "zones".

Global/Chrome/Server
Firebug UI
Content

The last one (Content) is the user's page. It is also a place Firebug lives. In fact, Global needs to be sure to inject the console into the user's Content. I think our inspector/highlighter stuff also still lives in Content via Global Chrome. Depending on how e10s goes, we may have more to go into "Content". Should we id the code that is injected or injects into Content? Or maybe just a subdir inside the global one?

I don't have much of an opinion about when it goes in (1.9 or 1.10), but I do think we should release more often, not less. Honestly, I'm fine if 1.10 goes out only a month after 1.9. 
Cc: sroussey
Nov 27, 2011
#5 sebastia...@gmx.de
> Honestly, I'm fine if 1.10 goes out only a month after 1.9.
I already dislike the full version release cycle of Mozilla. Also our team is way too small to have such a short release cycle (for full versions).
This being said, we already do provide bug fix releases relatively often (every 1-2 months) after a full release.
Also backporting fixes can be pretty difficult with Subversion. So if we want to make more (bug fix) releases, we'd probably better move to Git, because there it seems to be (I still don't really have experience with using Git) much easier to apply patches to different branches.
Jan 10, 2012
Project Member #6 odva...@gmail.com
(No comment was entered for this change.)
Labels: blocks-1.10
Jan 16, 2012
Project Member #7 odva...@gmail.com
(No comment was entered for this change.)
Status: Started
Owner: odva...@gmail.com
Cc: -odva...@gmail.com
Aug 21, 2012
Project Member #8 odva...@gmail.com
(No comment was entered for this change.)
Labels: -blocks-1.10 blocks-1.11
Feb 13, 2013
Project Member #9 sebastia...@gmail.com
In https://groups.google.com/forum/#!topic/firebug-working-group/EY2WhziH2dA we decided that this issue is not a blocker.

Sebastian
Labels: -blocks-1.11
Mar 23, 2013
Project Member #10 sebastia...@gmail.com
(No comment was entered for this change.)
Cc: sebastia...@gmail.com
Apr 4, 2013
Project Member #11 sebastia...@gmail.com
(No comment was entered for this change.)
Cc: -Amirjanyan@gmail.com -sebastia...@gmx.de
Sign in to add a comment

Powered by Google Project Hosting