Prototype.js (1.6.0.3) breaks Firebug (1.2.1)

[Curtis]

I am having an issue with Firebug when I include Prototype.js in my
Firefox extension. If I include Prototype using <script/> in the main
XUL then Firebug's view/inspect HTML doesn't function correctly.
Viewing the source displays a blank pane and inspecting the source
displays the DOM elements (as if the DOM tab was selected) instead of
the inspected source.

Has anyone seen this issue? I've read several places that Prototype
does some not-so-nice things in terms of extending core Javascript
objects (which has gotten better with their newer versions) but I
couldn't find any examples of people having issues with Prototype and
Firebug.

Firefox 3.0.3
Firebug 1.2.1
Prototype.js 1.6.0.3

[John J Barton]

Any library, like Prototype, that changes the Javascript type system
will cause you great pain if used in an extension. The entire
browser's javascript gets modified when you do that.

John

[Curtis]

Understood, but what's the solution? Don't use Prototype? Ask
Prototype to change what it's doing? Is there anything Firebug can do
to fix it?

That last question I ask because there is an issue with Zotero where
it doesn't play nicely with extensions that extend Javascript's
Array.prototype. From what I understand if Array.prototype is extended
(as it is with Prototype) and for..in loops are used, unexpected
things will happen (http://proto-scripty.wikidot.com/faq#forin).
Zotero has an open ticket to change it's use of for..in loops to for
each loops so I was wondering if Firebug might have the same issue.

--C

[Michael G Collins]

>
>
> Understood, but what's the solution? Don't use Prototype? Ask
> Prototype to change what it's doing? Is there anything Firebug can do
> to fix it?
>

Don't use it would be my solution. You could try asking the authors of Prototype but I'm sure they hear that a lot and since it is somewhat fundamental to their library I doubt they will change it for you.

I would consider why you are using Prototype in your extension, are you sure you really need it?  While I consider some of it's functions extremely useful for web development, esp. of the cross-browser kind, you get some nice javascript extras in moz-land that can do a lot of what Prototype does, only faster and without breaking other scripts.

http://developer.mozilla.org/en/New_in_JavaScript_1.6#Array_extras

And if you don't have to worry about supporting FF 1.5 in your extension, you can use generators and iterators too:
http://developer.mozilla.org/en/New_in_JavaScript_1.7

mc

[John J Barton]

Its not really about Firebug. Any change to the Javascript type system
affects all extensions. As a Firefox extension you get the power,
glory, and responsibility to be good ;-).

I wonder if you could use xpcom in some way to make a container for
prototype-like systems. But in any case this is something outside of
Firebug's realm.

jjb

[Curtis]

-- I would consider why you are using Prototype in your extension, are
you sure you really need it? --

I'm using another library that uses it (for it's asynchronous stuff)
so I would have to either modify that library not to depend on it or,
find another library that serves the same function without requiring
it. (The library I'm using is a JS SOAP library as FF3 dropped SOAP
support.)

I would still be interested in knowing whether or not there is
something that Firebug could change (a la Zotero http://forums.zotero.org/discussion/601/,
https://www.zotero.org/trac/ticket/597) re: supporting Array.prototype
extensions.

--C

[John J Barton]

Even if we changed Firebug, you'd still have to change every other
Firefox extension and verify that all of Firefox's own JS code was not
damaged. That's probably more work than changing the SOAP library.

On Oct 9, 2:19 pm, Curtis <cusm...@gmail.com> wrote:
> -- I would consider why you are using Prototype in your extension, are
> you sure you really need it? --
>
> I'm using another library that uses it (for it's asynchronous stuff)
> so I would have to either modify that library not to depend on it or,
> find another library that serves the same function without requiring
> it. (The library I'm using is a JS SOAP library as FF3 dropped SOAP
> support.)
>
> I would still be interested in knowing whether or not there is

> something that Firebug could change (a la Zoterohttp://forums.zotero.org/discussion/601/,https://www.zotero.org/trac/ticket/597) re: supporting Array.prototype

[Curtis]

-- That's probably more work than changing the SOAP library. --

That's probably true. I'm going to investigate using a different SOAP
library or removing the Prototype dependency in the one I'm using.

Thanks for the help and quick replies.

On Oct 10, 12:34 pm, John J Barton <johnjbar...@johnjbarton.com>
wrote:

> Even if we changed Firebug, you'd still have to change every other
> Firefox extension and verify that all of Firefox's own JS code was not
> damaged. That's probably more work than changing the SOAP library.
>
> On Oct 9, 2:19 pm, Curtis <cusm...@gmail.com> wrote:
>
> > -- I would consider why you are using Prototype in your extension, are
> > you sure you really need it? --
>
> > I'm using another library that uses it (for it's asynchronous stuff)
> > so I would have to either modify that library not to depend on it or,
> > find another library that serves the same function without requiring
> > it. (The library I'm using is a JS SOAP library as FF3 dropped SOAP
> > support.)
>
> > I would still be interested in knowing whether or not there is

> > something that Firebug could change (a la Zoterohttp://forums.zotero.org/discussion/601/,https://www.zotero.org/trac/...) re: supporting Array.prototype

[Lapis]

If one uses for..in loops for what they really are, there is no
problem.

Among other sources of javascript knowledge on the web, event the
proto-scripty-link you gave explains the nature of a for...in loop. It
simply doesn't do what many people seem to think it does. For these
people, of course the results of for...in loops are "unexpected" when
extension has been done.

On Oct 9, 8:27 pm, Curtis <cusm...@gmail.com> wrote:
> [...]

> That last question I ask because there is an issue with Zotero where
> it doesn't play nicely with extensions that extend Javascript's
> Array.prototype. From what I understand if Array.prototype is extended
> (as it is with Prototype) and for..in loops are used, unexpected
> things will happen (http://proto-scripty.wikidot.com/faq#forin).

> [...]

> --C
>

[John J Barton]

There are two different kinds of problems with for..in loops.

A minor one is the "objects are not arrays" issue outlined in
referenced page, (http://proto-scripty.wikidot.com/faq#forin). As far
as I know every array iteration in firebug uses numerical indexing.

A more subtle problem has to do with objects in a prototype chain.
Whenever Firebug has a object as a lookup table, it tests
"obj.hasOwnProperty(name)" to do the look up. This helps insure that
the value you put in the table under 'name' is the one that comes back
out. See for example, http://javascript.crockford.com/code.html.

However none of this changes the basic problem facing Curtis: no
change to Firebug will really allow prototype to be used in Firefox.

John.

[Mike Shaver]

On Tue, Oct 14, 2008 at 11:05 AM, John J Barton
<johnj...@johnjbarton.com> wrote:
> A more subtle problem has to do with objects in a prototype chain.
> Whenever Firebug has a object as a lookup table, it tests
> "obj.hasOwnProperty(name)" to do the look up. This helps insure that
> the value you put in the table under 'name' is the one that comes back
> out. See for example, http://javascript.crockford.com/code.html.

You can create a dictionary that doesn't delegate to the usual
Object.prototype stuff using this old mechanism:

var dict = { __proto__: null };

That should keep you from seeing toString or hasOwnProperty or other
Object.prototype paraphernalia.

Mike

[Andrew Dupont]

On Oct 14, 10:05 am, John J Barton <johnjbar...@johnjbarton.com>
wrote:

> However none of this changes the basic problem facing Curtis: no
> change to Firebug will really allow prototype to be used in Firefox.
>
> John.

John, I must object to your line of reasoning in this thread. I'm the
first to concede that using Prototype in environments it wasn't meant
for (like a XUL context) can have odd side effects, but I think it's a
bit premature to label this an issue of Prototype's incursion into
native objects when the OP has given no steps to reproduce. If
everything you say is true — if Firebug does index-only looping and
makes "hasOwnProperty" checks — then I don't see how it could be
related to for..in loops. I wonder if something more insidious is
going on.

This doesn't mean it's your duty to investigate, of course. Curtis,
can you try to remove the non-Ajax-related stuff from the copy of
Prototype that this SOAP library depends on? Specifically, you should
be able to remove everything relating to arrays, plus everything that
occurs after the Ajax section of the file. If those parts are removed,
it'd help diagnose whether for..in on arrays is the true problem.

Cheers,
Andrew

[Curtis]

On Oct 15, 1:28 am, Andrew Dupont <goo...@andrewdupont.net> wrote:
>
> This doesn't mean it's your duty to investigate, of course. Curtis,
> can you try to remove the non-Ajax-related stuff from the copy of
> Prototype that this SOAP library depends on? Specifically, you should
> be able to remove everything relating to arrays, plus everything that
> occurs after the Ajax section of the file. If those parts are removed,
> it'd help diagnose whether for..in on arrays is the true problem.
>

While I haven't tried to remove the non-Ajax-related stuff from
Prototype I have found a change to Prototype that seems to fix the
issue.

Looking at the block at line 1554-1569 of Prototype.js (v1.6.0) there
are three lines -- 1555, 1556, 1568 -- that reference "this.Element".
When "this.Element" is changed to "this.element" (casing change)
Firebug appears to work correctly. I don't fully understand this
change though; is it really a valid Prototype bug (a question for the
Prototype folks maybe) or is this just an anomoly.