Javascript libraries like Lightbox and moofx break

[Tessa]

Binary package hint: firefox

The latest firefox package in dapper (1.5.dfsg+1.5.0.2-0ubuntu2) breaks common javascript libraries moo.fx (http://moofx.mad4milk.net/) and Lightbox 2.0 (http://www.huddletogether.com/projects/lightbox2/). The examples on both pages don't work correctly after the update on my AMD64 system, and the Javascript console shows nothing unusual.

I'm not sure how to debug this further, so please let me know any additional information that would be helpful.

[Dennis Kaarsemaker (dennis)]

Latest firefox is 1.5.0.3 - please test with this version.

[Tessa (unit3)]

I don't see 1.5.0.3 on the mirrors (http://archive.ubuntu.com/ubuntu/pool/main/f/firefox/), can you point me at the location of this package?

[Tessa (unit3)]

Alright, 1.5.dfsg+1.5.0.3-0ubuntu1 just hit my mirror, I just installed it, and I still see the problem, these javascript libraries are still all broken. Note that they work perfectly fine on 1.5.0.3 on Windows.

[Ian Jackson (ijackson)]

I've just tried this with 1.5.dfsg+1.5.0.3-0ubuntu1 on i386 and there doesn't seem to be any problem to me.

The tests I performed were:

1. I visited http://moofx.mad4milk.net/ and played with the accordion-like navigation on that page. This appears to work correctly (although it's not hugely speedy) as far as I can tell. For example, immediately after the page loads only the heading `moo.fx pack v1.2.4' contents underneath. If I click on `Introduction' then that closes, shuffling stuff up, and `Introduction' opens up to show text.

2.I visited http://www.huddletogether.com/projects/lightbox2/ and tried the first Image Set example. This makes the rest of the page go dim and shows me a slide-like display of the image in the middle of my browser window; the navigation (mouseover `Next', close, and `n') all seem to work just fine.

Can you try it with a fresh profile (move .mozilla aside) ? What is the misbehaviour that you see ? How do you know that the libraries aren't at fault ? Have you tried the upstream 1.5.0.3 at all ?

[Tessa (unit3)]

Alright, just tested with a fresh profile, no dice, still broken. Tested with the upstream i686 build, and it worked fine. So, the only thing I can figure is there's something broken in the amd64 build on dapper.

I'll attempt a package rebuild from source with different optimization options, and see if I can figure out a combination that fixes this issue.

For reference purposes, the misbehavior I see seems to be timing related... with moofx, the sliding animation sticks partway through, and you have to click a heading about 20 times to get it to fully complete. With lightbox2, it displays the box, but the animation while loading doesn't animate properly, and it sticks halfway through resizing the box to the size of the picture.

[rpdillon (launchpad-rpdillon)]

Been fighting this one for a while now. Running Dapper Kubuntu on amd64.

The main place this shows up for me is on Digg.com, when trying to show buried comments. I've been looking for weeks for the cause, and using Konqueror to surf Digg.

Before I used Kubuntu, I've used both SUSE 10.1 and Gentoo on amd64 and had no problems. Doesn't seem to be either Firefox or the libraries.

I think it is amd64 specific based on research I've done. I am using the most recent build in the repos (1.5.0.4) and the problem is still there (it has been there in the two previous versions as well).

I am a developer, but not really familiar with Firefox (mainly a Java and Python guy professionally)...if I could get someone to point me in the right direction, I'd be happy to take a look at the problem and see if I can track it down.
Rick

[Tessa (unit3)]

I'm not very familiar with the Firefox codebase either, but I can suggest that a good place to start might be the differences between the Ubuntu build and the official release, since we aren't seeing the problems with other builds or with the official builds.

[Serkan Hosca (serkan-hosca)]

I have the same problem here. Running ubuntu dapper amd64. It might be an amd64 specific problem because it doesnt work on gentoo amd64 either. x86 binary version of firefox on gentoo amd64 works.

When I stepped through the javascript of the digg show/hide comment with venkman javascript debugger, it expanded the comment and i got no errors.

[Lakin Wecker (lakin)]

I'm still seeing this on an up to date dapper with firefox on an amd64. It is an amd64 issue. If I download and install firefox 1.5.0.7 (32 bit version) from the firefox site, everything works fine.

For me, I see this with moo.fx, scriptaculous, dojo and a number. I'm willing to provide more information as needed.

What I see is that the effects like "Fade" or "moving elements" don't work unless you keep trying to click on them. It's as if their are some timeout functions that aren't working properly.

I'm confirming it, as it seems that most of the questions asked have been answered.

[Tessa (unit3)]

Has anyone checked Firefox 2.0 on AMD64/edgy for this bug? I no longer have access to the AMD64 install that I was experiencing this bug on.

[Tessa (unit3)]

I've checked now, and this problem no longer exists on AMD64 in Edgy with Firefox 2.0. Is FF2 going into dapper backports, since dapper needs to be supported for a long time? Or is someone going to attempt to fix 1.5 in dapper?

[David Farning (dfarning)]

I've put in request to backport 2.0 to dapper and edgy. I'm not sure what the issues are.

David

[Alexander Sack (asac)]

is this still an issue for you? Can you still reproduce with latest firefox?

In case, how can I see that its broken. Need a testcase. Thanks.

[rpdillon (launchpad-rpdillon)]

This hasn't been an issue in 2.0 on Edgy for me. I can't provide a testcase for Dapper because I've migrated all my machines to Edgy more or less the week it came out.

I can say that when the whole Firefox/Iceweasel furor came around, I was surprised to find that the 1.5 FF packages were broken, but Iceweasal worked fine. I think I concluded it was strictly a build issue, but because I could never actually get FF to build from source (it was surprisingly hard!), I never found out what exactly was causing it.

Binary builds from mozilla.org have always (and continue to) work - all versions, all platforms.

[Alexander Sack (asac)]

while i cannot deny that this might have been caused by some ubuntu/debian specifics in 1.5, iceweasel has never been released from 1.5. So the observation that firefox 2.0 in edgy fixes is not at adds with your observation that iceweasel has never had this issue.

For dapper, I am not sure ... need a detailed working testcase or some tester who can help to sort this out on irc: on freenode -> #ubuntu-mozillateam.

[John Vivirito (gnomefreak)]

Is this still a problem in dapper, and are the testcases above correct and reproducable?

[John Vivirito (gnomefreak)]

Im gonna see if i can reproduce this with testcases that are here but if there is a better one please drop it in bug report.

[John Vivirito (gnomefreak)]

Can anyone reproduce this on a i386 system?

[Tessa (unit3)]

Better question, can anyone reproduce this on a current, up-to-date dapper install? Is this still valid, or have recent Firefox security releases sorted this problem out?

[Tessa (unit3)]

Note that this bug is a non-issue on recent releases, such as gutsy / hardy. Since hardy is a new LTS, can we close this bug now as "fix released"?

[Erich Jansen (erichjansen-deactivatedaccount)]

Closing at request of submitter