Note
Most visitors to this page seem to be searching to find out why Firebug with the break all errors option detects an exception on
obj.type. If that's why you're here, see the end of the article for edits that fix this problem.
I have seen the occasional attempt to build full windowing environments inside of a browser, and been only semi-impressed. After all, we do have mature remote desktop solutions like VNC. Why deal with the nightmare of browser inconsistencies when you can just set up a virtual machine of your choice, program to whatever hardened widget API you like, and let users control its screen through a terminal??
That makes sense to me, and it will only make more sense as virtualization expands. For more on my thoughts, see the article "Virtualization and the Integrated Circuit"
Putting this bias aside, I was somewhat inspired today by the Extjs Web Desktop Demonstration. Reading about the history of Extjs, I saw that it was conceived as an extension to the Yahoo User Interface Library. In fact, it could run on top of it and use its event model somehow. To test this claim, I got the idea to integrate the Yui Drag and Drop Groups Demo into the Extjs Web Desktop:
Despite my general ignorance from being on day one of meeting both of these frameworks, it sort of worked first try. I simply took the global variables out of the drag and drop demo page (
slots, players, Event, DDM) and made them members of the created window object. I then substituted the HTML of the drag and drop space:<div id="workarea">..blahblah...</div>
for the HTML that was in the default for blank windows in the Web Desktop sample:
<p>something useful would be in here</p>
The drag and drop worked as expected. But I use Firebug with the "Break on all Errors" option. And after gluing these two things together, clicking in the Extjs grid window causes a temporary halt in YUI's connection-debug.js on line 240. It's a little snip of code in
_hasSubmitListener enclosed within a try/catch block, like so:/* line 237 */
try
{
var obj = YAHOO.util.Event.getTarget(e);
if(obj.type.toLowerCase() == 'submit') {
YAHOO.util.Connect._submitElementValue = encodeURIComponent(obj.name) + "=" + encodeURIComponent(obj.value);
}
}
catch(e) {}
What's happening is that
obj is div.x-grid3-cell-inner, which is an entity used by Extjs inside its grid. Yui somehow gets ahold of the click (how?), and finds the .type is undefined. This leads to an exception when toLowerCase() is called. Looking at the snippet I was puzzled... is the exception handling intentionally glossing over cases where the type isn't defined? If that is the case, it would be much better to use a direct comparison with "undefined":if (obj.type != undefined)
if (obj.type.toLowerCase() == 'submit') ...
If this situation isn't supposed to happen, then the dereference of obj.type should be outside the try/catch block so that people who aren't using Firebug with "Break on all Errors" will know they have a problem.
I posted about this to the YUI forum. Thomas Sha works in the Yahoo platforms department, and agreed that my change would be a good way to deal with it, at least until YUI 2.4.0 is released. So I made the following changes to yui / build / connection / connection-debug.js and yui / build / connection / connection.js :
/* line 237 */
try
{*/
var obj = YAHOO.util.Event.getTarget(e);
if((obj.type != undefined) && (obj.type.toLowerCase() == 'submit')) {
YAHOO.util.Connect._submitElementValue = encodeURIComponent(obj.name) + "=" + encodeURIComponent(obj.value);
}
/*}
catch(e){}*/
In yui / build / connection-min.js, you should just replace the string:
try{var S=YAHOO.util.Event.getTarget(q);if(S.type.toLowerCase()=="submit"){YAHOO.util.Connect._submitElementValue=encodeURIComponent(S.name)+"="+encodeURIComponent(S.value);}}catch(q){}
with:
/*try{*/var S=YAHOO.util.Event.getTarget(q);if((S.type!=undefined)&&(S.type.toLowerCase()=="submit")){YAHOO.util.Connect._submitElementValue=encodeURIComponent(S.name)+"="+encodeURIComponent(S.value);}/*}catch(q){}*/
That seemed to take care of it, and the system no longer generates spurious breaks in Firebug. I had a working demo. Though there were issues with the scroll bars bleeding through the windows in Firefox on Mac, but that's due to a Firefox bug:
I'm sympathetic to the nastiness of the quirk but I feel like this is what such frameworks must have workarounds for--as they exist precisely to help us not worry about all the bugs in commonly deployed browsers. I managed to work around it using theming--which might give Firefox OS/X users some peace of mind.)
