I am planning to release Firebug 1.9a2 on Friday.
Bunch of issues have been fixed (some of them ported into 1.8)
---
One thing I would like to do yet in 1.9a2 is to put entire Firebug
into its own (i)frame and isolate it from the other extension.
Something what we already did, but abandoned since it cased issues in
the 1.8 release.
Now I think it's good time to try it again since we have time to solve
all small issues during the alpha and beta phase of 1.9
The advantages of such solutions are:
1) Solves SeaMonkey status bar problem (issue 4804) Note that the
problem can happen in Firefox too and could be the explanation why
some users don't see the status bar icon even if we couldn't reproduce
it (we could try again based on Neils comments here:
http://groups.google.com/group/mozilla.dev.platform/browse_thread/thr...)
2) RequireJS and the rest of Firebug is not loaded into the global
scope: browser.xul. This is big and it avoids possible collisions with
other extensions (what if other extension would also use RequireJS).
3) It solves the RoboForm problem (issue 4720)
---
Embedding of Firebug in the (i) frame should be done slightly
differently than before. It should be inserted into <browser> element
(coming from XUL) instead of <iframe> element (coming from HTML) to
avoid UI font size problems.
> Embedding of Firebug in the (i) frame should be done slightly
> differently than before. It should be inserted into <browser> element
> (coming from XUL) instead of <iframe> element (coming from HTML) to
> avoid UI font size problems.
Sounds like you want to keep the <browser> element, but put an
<iframe> into it. Is that correct?
If so, I guess the issue mentioned above will probably not be solved.
this also will simplify detaching firebug to separate window, and placing it into sidebar or top, since we can use browser.swapDocShells to move whole firebug to other window using it will also simplify code in chromeFactory and in places where we had to use getElementById every time since element could be changed
(i had almost working patch for this last time, will try to resurrect it)
- Firefox.js probably needs to remain in browser.xul with tabWatcher - require will not need namespace anymore which will be good for extensions (loading modules only when required, using require('foo/bar') style)
> this also will simplify detaching firebug to separate window,
> and placing it into sidebar or top,
> since we can use browser.swapDocShells to move whole firebug to other window
> using it will also simplify code in chromeFactory and in places where
> we had to use getElementById every time since element could be changed
> (i had almost working patch for this last time, will try to resurrect it)
> - Firefox.js probably needs to remain in browser.xul with tabWatcher
> - require will not need namespace anymore which will be good for
> extensions (loading modules only when required, using
> require('foo/bar') style)
> > Embedding of Firebug in the (i) frame should be done slightly
> > differently than before. It should be inserted into <browser> element
> > (coming from XUL) instead of <iframe> element (coming from HTML) to
> > avoid UI font size problems.
> Sounds like you want to keep the <browser> element, but put an
> <iframe> into it. Is that correct?
> If so, I guess the issue mentioned above will probably not be solved.
On Sep 7, 8:55 am, Harutyun Amirjanyan <amirjan...@gmail.com> wrote:
> this also will simplify detaching firebug to separate window,
> and placing it into sidebar or top,
> since we can use browser.swapDocShells to move whole firebug to other window
> using it will also simplify code in chromeFactory and in places where
> we had to use getElementById every time since element could be changed
Good point
> (i had almost working patch for this last time, will try to resurrect it)
> - Firefox.js probably needs to remain in browser.xul with tabWatcher
You mean firebug.js, right? I think that this file would be included
within the iframe and a reference exposed to the global scope.
I think this module should be also loaded together with all other AMD
modules
within the frame. Or is there anything blocking us from doing that?
I believe that all modules should be loaded in the iframe and only
necessary
references (such as Firebug) created in the global scope to keep
compatibility
with existing extensions.
Firebug UI will be presented in two scopes:
- Firebug UI within the frame (toolbar, panels, etc.)
- Firebug Start button, web-developer menu, page context menu in
browser.xul
Loading into an iframe/browser is essentially what Chrome does. The big question I have is what about extensions? I would imagine that they should be in the same context. I can't remember where the discussion went last time on this issue. Anyhow, I think it a great idea. What are the other side effects of using a browser tag instead of an iframe tag?
Steven Roussey
On Tue, Sep 6, 2011 at 11:10 AM, Jan Honza Odvarko <odva...@gmail.com>wrote:
> I am planning to release Firebug 1.9a2 on Friday. > Bunch of issues have been fixed (some of them ported into 1.8)
> ---
> One thing I would like to do yet in 1.9a2 is to put entire Firebug > into its own (i)frame and isolate it from the other extension. > Something what we already did, but abandoned since it cased issues in > the 1.8 release.
> Now I think it's good time to try it again since we have time to solve > all small issues during the alpha and beta phase of 1.9
> The advantages of such solutions are:
> 1) Solves SeaMonkey status bar problem (issue 4804) Note that the > problem can happen in Firefox too and could be the explanation why > some users don't see the status bar icon even if we couldn't reproduce > it (we could try again based on Neils comments here:
> 2) RequireJS and the rest of Firebug is not loaded into the global > scope: browser.xul. This is big and it avoids possible collisions with > other extensions (what if other extension would also use RequireJS).
> 3) It solves the RoboForm problem (issue 4720)
> ---
> Embedding of Firebug in the (i) frame should be done slightly > differently than before. It should be inserted into <browser> element > (coming from XUL) instead of <iframe> element (coming from HTML) to > avoid UI font size problems.
On Sep 7, 5:34 pm, Steven Roussey <srous...@gmail.com> wrote:
> Loading into an iframe/browser is essentially what Chrome does. The big
> question I have is what about extensions? I would imagine that they should
> be in the same context.
Firefox extensions that overlays chrome://firebug/content/firebugOverlay.xul
are still living in the same context (relatively to Firebug).
The difference is that firebugOverlay.xul itself doesn't live in
browser.xul,
but in firebugFrame.xul
> I can't remember where the discussion went last time
> on this issue. Anyhow, I think it a great idea. What are the other side
> effects of using a browser tag instead of an iframe tag?
I know about following:
- There are font size issues
- Security is handled a bit differently
> this also will simplify detaching firebug to separate window, > and placing it into sidebar or top, > since we can use browser.swapDocShells to move whole firebug to other > window > using it will also simplify code in chromeFactory and in places where > we had to use getElementById every time since element could be changed
> (i had almost working patch for this last time, will try to resurrect it)
Considering that moving all of our UI to a web-based implementation (thus using an iframe) is part of our mid-to-long term, I would not invest time in a solution that will require changes now and won't work in the future (that is, will require more changes later).
On Wed, Sep 7, 2011 at 10:31 PM, Pedro Simonetti Garcia
<pedrosimone...@gmail.com> wrote: > Harutyun, > Considering that moving all of our UI to a web-based implementation (thus > using an iframe) is part of our mid-to-long term, I would not invest time in > a solution that will require changes now and won't work in the future (that > is, will require more changes later).
yes, but whatever we do we will have a lot of firebug specific code, unless we remove some features from firebug,
changes here are about firefox specific part, (outer browser which must live in browser.xul not in page) so we will have to do them anyway
> On Sep 7, 8:42 pm, Harutyun Amirjanyan <amirjan...@gmail.com> wrote:> yes, but whatever we do we will have a lot of firebug specific code,
> > unless we remove some features from firebug,
> > changes here are about firefox specific part,
> > (outer browser which must live in browser.xul not in page)
> > so we will have to do them anyway
> > and web-based UI will live inside that browser
> Agree, firebug-frame layout/position management can happen
> independently of the
> content (content == Firebug UI).
> On Wed, Sep 7, 2011 at 10:31 PM, Pedro Simonetti Garcia > <pedrosimone...@gmail.com> wrote: > > Harutyun, > > Considering that moving all of our UI to a web-based implementation (thus > > using an iframe) is part of our mid-to-long term, I would not invest time > in > > a solution that will require changes now and won't work in the future > (that > > is, will require more changes later).
> yes, but whatever we do we will have a lot of firebug specific code, > unless we remove some features from firebug,
> changes here are about firefox specific part, > (outer browser which must live in browser.xul not in page) > so we will have to do them anyway
> and web-based UI will live inside that browser
Okay, it makes sense. Forget what I said earlier :)
I guess I misunderstood the behavior of the swapDocShells function. By reading the documentation it seems to be a good choice using it in the detached UI:
