Re: Adobe AIR with Firebug 1.3.2

[Marijn van Zon]

The document.write() indeed does not trigger an error. The div is a better option, which gets nicely added when I force the type to "div". Is there an option available through which I can properly have firebug load via div? Though maybe the iframe is still better when sandboxing comes into play (it's one of the ways to create a sandbox). Btw, an issue that I came across but forgot to mention in my previous mail is that AIR uses "app:/my/path/to/firebug-lite.js" as source url. That caused the script tags to incorrectly get src values containing "app:/app:/my/path/to/....". My quick ugly workaround was to set a path.replace('app:/app:/','app:/') in firebug-lite-dev.js, but I'll see if I can do a "clean" fix too :). As far as the "loading from the application directory" is concerned, in terms of location firebug is already placed in the application directory. For AIR the application directory is simply the "document root" of your application. Here however the emphasis is not on "application directory" but on "loading" as in not where but when the code is loaded. eval() can (just like document.write()) be used while the page is still loading for the first time. As soon as the dom has loaded, eval() and document.write() stop working. So it seems to me that that's not going to get us anywhere. The other link also doesn't look help, as the author's original problem seems to be a misplacement or bad naming of his html/_javascript_ page. The sandboxes however look very promising. I've never worked with them in AIR before, but with a simple proof I was able to perform an eval() within a sandbox. Bridging between the application sandbox and the non-application sandbox where eval() can be used shouldn't be hard, but that didn't immediately work, so it's something I'll have to postpone experimenting with until the weekend. Joining the Firebug Working Group is an idea, but first I'd like to experiment a bit more :). Regards, Marijn van Zon. On 08-Jun-11 03:33, Pedro Simonetti Garcia wrote: I just realized I replied to Marijn only, without forwarding this message to the newsgroup too. Here are the messages we exchanged earlier today: ~~~~~~~~~~~~~~~~~~~~~~~~~ Awesome! Great job! 2011/6/7 Marijn van Zon <mar...@suninet.org> Hi Pedro, After some more digging I found out what (part of) the problem is. Adobe AIR ignores document.write() statements after the DOM has loaded. Because the write statement is ignored, the template data is not writting to the iframe's document and that's where firebug gets stuck in its initialization. Okay. Good to know that. I guess calling document.write() does not trigger an error, right? There's a fallback function createChromeDiv() that loads the UI using a DIV and innerHTML instead of IFRAME and document.write() but it seems that this function is not being called because the document.write() does not trigger an error. How are you loading Firebug Lite? According to the following article, "code in the application security sandbox can only use these methods [like eval() and document.write()] while content is loading from application directory": http://help.adobe.com/en_US/AIR/1.5/air_security/WS5b3ccc516d4fbf351e63e3d11c0f598475-7ff4.html So I wonder if it is possible to load Firebug Lite from the "application directory". Do you know if this is possible? Also, is the hint provided in the following article helpful? http://codes.widged.com/node/33   I was able to work around this by instead of doing a document.write() using the innerHTML attribute of the iframe element. A concern there could be that event listeners such as onclick attributes for elements are not loaded, they have to be added via addEventListener, but I couldn't find any occcurances for that in the template data so at least that's not an issue. Though it still may cause other complications and/or issues ... I don't recall having inline events in the template either.   After the iframe had its content loaded via innerHTML the next problem was that the detection whether the frame was loaded didn't function properly. In the check node.contentWindow.document.getElementById('fbCommandLine') would return null, stripping however 'node.contentWindow' from the statement did return the proper element and made the check work. This might have to do with the above change where innerHTML was used instead of document.write(). Ok.   After that however I got stock on FireBug depending on eval() commands for futher initialization, because eval() is prohibited in AIR. In FireBug Lite 1.2 eval() also does not work, but it is not used in its initialization and thus only affects the Console. I tried a bit to see what would happen if I removed the eval commands, but quickly got stuck on the eval's used in domplate.js, having no clear idea on how they could be rewritten. That certainly is a problem because Firebug Lite depends upon eval() to accomplish things like command line execution, but also the template generation (aka Domplate). Specially the Domplate dependency on eval() will be something hard to overcome because Domplate is kinda crypt and very hard to understand / debug, but at the same time, is an important piece of code responsible for generating the rich representation of objects we used to see in Firebug. It seems like quite a bit of changes would be required to work around the eval() issue to make FireBug Lite work in AIR. Personally I wouldn't mind fiddling around a bit more with this if creating an option to for example disable the functionality of the Console could provide a solution. A Console is already available in Introspector, so it's not a big issue if its not in FireBug. The 'tracing' of styles is what I like most about FireBug because Introspector can only show the computed styles. Plus FireBug is for more user friendly :). But I'm guessing that probably wouldn't be enough to eleminate the eval()'s? :( Instead of trying to remove the eval() dependency I suppose a better approach would be trying to use a workaround to make the eval() work. It seems that are a couple of ways to do that. In the "Interacting with different sandboxes" section of the following article it says that "[...] you could expose, for example, the eval() function from a non-application sandbox back into the application sandbox, as any code subsequently evaluated within the exposed eval() function then will be executed within the context of the non-application sandbox": http://www.adobe.com/devnet/air/articles/introduction_to_air_security.html Another possible workaround would be loading Firebug Lite in a non-application sandbox: http://help.adobe.com/en_US/AIR/1.5/devappshtml/WS5b3ccc516d4fbf351e63e3d118666ade46-7f08.html#WS5b3ccc516d4fbf351e63e3d118666ade46-7f07 But anyway, I'm glad that you're taking the time to investigate these issues. This is a long wanted feature in Firebug Lite and I don't have the proper knowledge to implement this alone (at least not without investing first a lot of time learning how AIR applications works). If you really want to get your hands dirty, I invite you to join our Firebug Working Group so you can have commit access to our SVN and start experimenting these changes in a separate branch. I'm pretty sure we and a lot of AIR developers will be very thankful for your work! :) regards, Pedro Simonetti.   Regards, Marijn van Zon. On 07-Jun-11 17:31, Pedro Simonetti Garcia wrote: Hi there, 2011/6/7 Marijn van Zon <mar...@suninet.org> Hi, The same problems occur for me when trying to use Firebug Lite in Adobe AIR. I've tried to debug a bit but haven't been able to find the cause. Though when starting Firebug Lite in persistent mode it does open up the Firebug Lite window. The Inspect button however does not function and the tabs are not shown. When inspecting the HTML using Adobe's Introspector (a Firebug-like library for Adobe AIR, but compared to Firebug Lite it misses some useful features like being able to 'trace' css styles on an element) the html seems properly loaded (the table up to the fbConsoleTab and fbHTMLTab anchors appear complete). Thanks for the feedback. I never worked with Adobe AIR so I'll definitely need some help. I suggest not using the persistent mode for now. It is harder to debug and its initialization is more complex than the non-persistent one. I suspect Firebug Lite is not initializing at all, so let's first start investigating if something is going wrong during the initialization.   I don't mind diving a bit deeper into this to figure out why it doesn't function, however I'm having a hard time figuring out where to start looking in the code. Do you have a few pointers where it would be useful for me to start looking? For example where for a persistant window is the Inspect button initialized? The create function in ChromeBase seems to do this, but that function is never called, so if that is the correct function, where is it supposed to be called as I can't seem to track that down. My suggestions are: 1) Checkout the Firebug Lite 1.4 branch: http://fbug.googlecode.com/svn/lite/branches/firebug1.4/ 2) Edit the ./content/firebug/lite/trace.js file, and replace the "sysout" function with something like this: this.sysout = function() {     return air.Introspector.Console.log.apply(air.Introspector.Console, arguments || []); }; 3) Load Adobe AIR Introspector 4) Load Firebug Lite in "Development Mode" (by loading the ./content/firebug-lite-dev.js file): http://getfirebug.com/firebuglite#DevelopmentMode 5) Look for errors in the Adobe AIR Introspector Console panel. You may also copy and paste the full log here so I can give you hints of what could possibly be happening. ~~~~~~~~~~~~~~~~ Some other hints: - If the trace.js log redirection to Adobe AIR Introspector Console works, you can call FBTrace.sysout() anywhere in the code to check if that line is being called. - The chrome's "create" function is called inside the "onDocumentLoad" function located at lib.js. - The normal (non-persistent) initialization order in Firebug Lite 1.4 goes something like this:     a) wait the document to load (lib.js)     b) call chrome.create() to create the iframe which will hold the UI     c) wait the iframe document to load (chrome.js)     d) call onChromeLoad() which will then call Firebug.initialize(), initializing the rest of the app Please feel free to ask me questions if you got stuck in the code. regards, Pedro Simonetti.   Regards, Marijn van Zon. On Mar 27, 6:09 am, Pedro Simonetti Garcia <pedrosimone...@gmail.com> wrote: > Actually AIR support is an old request:http://code.google.com/p/fbug/issues/detail?id=2766 > > The major problem here is that I have zero experience with Adode AIR > platform. So I can't solve this problem without the help of a AIR developer. > If you want to help us I suggest "starring" that issue report and from that > we continue to investigate what could possibly solve this problem. > > 2011/3/26 Rand <randh...@gmail.com> > > > As far as I can tell, Adobe AIR should deal with Firebug Lite > > perfectly fine. It uses the webkit engine, and when you get its > > useragent, it properly indicates that. I've used many other _javascript_ > > libraries such as jQuery and Ext, and they also seem to work. > > Ok. You also said you have successfully loaded Firebug Lite 1.2 too, so it > could be something simple to fix. > > > There are only two caveats: > > > 1.) I believe the location.href property is either a blank string or > > does not have a protocol preceding it. > > This could be a problem. Which exact URL are you using to load Firebug Lite? > Firebug Lite 1.3 needs to guess the location of its installation based on > the URL used to load itself. If a relative path is found then it will use > the location.href file to discover the root of the path. > > Try using a file:/// URL like the following article and let me know if it > works.http://codes.widged.com/node/33 > > > 2.) There is a security sandbox which prevents eval() from being > > called, plus a couple other things that are generally avoidable with > > good coding practices > > This could also be a problem. Firebug Lite relies on eval() to do certain > things such as evaluate command line expressions and complex DOM template > generation (aka Domplate module). But Firebug Lite 1.2 also relies on eval() > to do certain things, so I guess this could not be the source of the > problem. > > > Other than that, I think it should work. If the security sandbox > > violation occurred, it would be obvious, since it does everything it > > can to inform you of it. > > If you aren't seeing error messages (like sandbox security violation > messages) it means that probably the problem is happening during Firebug > Lite initialization. I suspect Firebug Lite isn't initializing at all. > > regards, > > Pedro Simonetti. > > > > > I am very certain I've implemented it properly because when I load the > > page it in Firefox, Firebug shows up just fine. > > > On Mar 25, 11:11 am, Pedro Simonetti Garcia <pedrosimone...@gmail.com> > > wrote: > > > You mean Firebug Lite, right? > > > > I never worked with AIR applications so I have no idea what can possibly > > be > > > wrong. If you manage to discover why exactly it isn't working I will be > > able > > > to fix the problem. > > > > Is there any big difference when loading JS files inside AIR applications > > I > > > should be aware of? Is there any kind of error message going on? > > > > If anyone else with AIR knowledge would like to join the discussion, > > please > > > do it. > > > > regards, > > > > Pedro Simonetti. > > > > 2011/3/24 Rand <randh...@gmail.com> > > > > > Hi, all, > > > > > I am running an Adobe AIR application, which I believe will benefit > > > > greatly with Firebug (AIR's default introspector lacks a great deal of > > > > features Firebug has). When I run Firebug 1.23 with Adobe AIR, it > > > > works alright, although still lacks what I consider critical features > > > > 1.3.2 has (specifically, the "Style" tab when you are inspecting a dom > > > > element). > > > > > When I try to use 1.3.2, and load a webpage AIR is loading on Firefox, > > > > it works great. The Firebug logo shows up on the lower-right hand > > > > corner and everything works. When I launch it via Adobe AIR, the > > > > Firebug logo simply doesn't display at all, and as far as I can tell, > > > > there are no JS errors or sandbox violations. > > > > > Has anyone had any luck running Firebug on Adobe AIR? Can someone help > > > > me out? > > > > > Thanks > > > > > -- > > > > You received this message because you are subscribed to the Google > > Groups > > > > "Firebug" group. > > > > To post to this group, send email to firebug@googlegroups.com. > > > > To unsubscribe from this group, send email to > > > > firebug+unsubscr...@googlegroups.com. > > > > For more options, visit this group at > > > >http://groups.google.com/group/firebug?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Firebug" group. > > To post to this group, send email to firebug@googlegroups.com. > > To unsubscribe from this group, send email to > > firebug+unsubscr...@googlegroups.com. > > For more options, visit this group at > >http://groups.google.com/group/firebug?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Firebug" group. To post to this group, send email to firebug@googlegroups.com. To unsubscribe from this group, send email to firebug+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/firebug?hl=en. -- You received this message because you are subscribed to the Google Groups "Firebug" group. To post to this group, send email to firebug@googlegroups.com. To unsubscribe from this group, send email to firebug+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/firebug?hl=en.