Interference with other addons

[Dries]

Hi,
I've been following the discussions and development of ubiquity from a
distance... Personally I come from an industrial design background
(currently working as an HCI researcher), so all the code stuff goes
beyond my comprehension at times. However, I'm very interested in the
functionality and the way the interaction is done and designed.
I upgraded from one of the first releases to the current developer
release of ubiquity today and was really surprised about the way
ubuiquity is integrated, as a potential 'end user' I'm loving it so
far. However one thing I found as a potential 'bug' is that when I
activate ubiquity my google reader notifier addon is somehow disabled.
So perhaps this is something that's also happening with other
addons...

Besides all that I'll keep following the progress of ubiquity, and
wherever I can add something I will :-)

[Jono]

Hello Dries!
Thanks for your feedback.  I'm glad you like Ubiquity so far.  Thanks for reporting this bug; I'll file it and somebody will try to replicate it.
--Jono

[Jono]

P.S. Dries, can you tell us any more details about how Ubiquity interferes with the Google reader notifier?  Like, when you activate Ubiquity, does the notifier stop working until you restart your browser, or does it just stop working temporarily?

Also, are you on Mac, Windows, or Linux?  It makes a difference because the system used to display notifications is different on all three platforms, and I have a hunch the bug has something to do with that.

Thanks again.
--Jono

[Dries]

Jono,

Basically what happens is that the google reader notifier button on
the status bar dissapears when ubiquity is active. Meaning the addon
(greader notifier) can't be accessed. I've tried disabling and re-
enabling both addons in a whole number of combinations (also combining
restarting firefox etc) but the notifier addon stays 'invisible'.
There's also no placeholder or 'invisible' button/area, it just seems
like it's not there even though it's activated :-)
I'm on mac (10.5.4) - if you need any other data just let me know.

Dries

On Aug 19, 7:53 pm, Jono <jdica...@mozilla.com> wrote:
> P.S. Dries, can you tell us any more details about how Ubiquity interferes
> with the Google reader notifier?  Like, when you activate Ubiquity, does the
> notifier stop working until you restart your browser, or does it just stop
> working temporarily?
>
> Also, are you on Mac, Windows, or Linux?  It makes a difference because the
> system used to display notifications is different on all three platforms,
> and I have a hunch the bug has something to do with that.
>
> Thanks again.
> --Jono
>

> On Tue, Aug 19, 2008 at 10:50 AM, Jono <jdica...@mozilla.com> wrote:
> > Hello Dries!
> > Thanks for your feedback.  I'm glad you like Ubiquity so far.  Thanks for
> > reporting this bug; I'll file it and somebody will try to replicate it.
> > --Jono
>

[Abi]

Hey Dries,

With a little bit of poking around, I figured out why this occurs.
Ubiquity loads jQuery into browser.xul. jQuery defines a $ function
which conflicts with the $ function that the Google reader extension
also defines. So, the google reader extension ends up not showing the
icon in the statusbar (actually, its just invisible, I can click on it
and it'll open up google reader). But at the moment, I'm still
thinking of a solution to this bug.

-Abi

[Dries]

I've 'discovered' one more thing, depending on the location that is
set for the button to appear you can either still click it or not. I
had it set at "right of page-report-button", when I start fiddling
about with the location I can manage to click it in some situations
(like "right of statusbar-display").
But I guess this is all linked to the conflicting $ function...

[Atul Varma]

Ah, interesting.  A friend of mine had advised me to always use jQuery via the jQuery() function instead of the $() function because lots of content code uses $() for other purposes ... so one alternative may be to do something along the lines of:

  old_$ = $
  import jQuery
  $ = old_$

this solution assumes that jQuery itself doesn't use the global $() function though... I think that modifying Ubiquity's code to use jQuery() instead of $() isn't hard though and will reduce the problems of these kinds of conflicts in the future anyways.

Yet another alternative may be to load jQuery in a Components.utils.Sandbox.

- Atul

[Aza]

jQuery doesn't use the global $() function because of exactly this problem. Instead, whenever they want to use $, they'll just pass jQuery into a closure with a variable name of $.

-- aza | ɐzɐ --

[Atul Varma]

Cool.  Does anyone mind, then, if we change Ubiquity's codebase to only use jQuery() and never $()?

[Aza]

Let it be so.

-- aza | ɐzɐ --

[Blair McBride]

FYI, jQuery has a "no-conflict" mode where it doesn't set the $
variable. I think we should enable this. Its a one-liner fix, as soon
as jQuery is loaded: jQuery.noConflict();

See http://docs.jquery.com/Using_jQuery_with_Other_Libraries

- Blair

[Blair McBride]

An idea I've had bouncing around in my head for awhile is that it may
be safest to namespace everything in Chrome into a "Ubiquity" object.
There's already a Ubiquity object, but its used as a constructor (the
instance it put into gUbiquity).

Variable names like "Utils" are extremely generic, and there's bound
to be some problem in the future with at least that example.

In developing extensions in the past, I've been dismayed at seeing all
the internal functions of other extensions just made to be global. I
think this is one of the areas that other extensions make a huge mess
out of. It would also be good for other extensions that extend
Ubiquity in the future.

- Blair

On Aug 21, 10:14 am, Blair McBride <unfocu...@gmail.com> wrote:
> FYI, jQuery has a "no-conflict" mode where it doesn't set the $
> variable. I think we should enable this. Its a one-liner fix, as soon
> as jQuery is loaded:  jQuery.noConflict();
>

> Seehttp://docs.jquery.com/Using_jQuery_with_Other_Libraries