1069706 - Page loading throbber does not animate in self-compiled Firefox and Thunderbird ("Action circle does not spin")

Status: RESOLVED INVALID

(Firefox :: Theme, defect)

Description

[nucrap]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0
Build ID: 20140916004355

Steps to reproduce:

I load a website.

I am using a self compiled firefox on funtoo (a fork of gentoo).
USE flags set: dbus gstreamer jit minimal.


Actual results:

Everything is alright apart from the action cirlce: It does not spin.


Expected results:

It should spin clock-wise.

Comment 1

[nucrap]

Appears it doesn't work in thunderbird 31.1.1 neither...

Comment 2

[:Gijs (he/him)]

What actual build flags did you use? Opening about:buildconfig in the browser should be able to tell us. I bet that whatever bit of the browser responsible for the spinning was disabled.

It would also be interesting to see the result of doing:

hg clone https://hg.mozilla.org/releases/mozilla-release/
cd mozilla-release
hg up -r FIREFOX_32_0_3_RELEASE
./mach build
./mach run

and if that build has the same problem.

Comment 3

[nucrap]

Attachment: about:buildconfig.htm

Comment 4

[nucrap]

I have attached about:buildconfig as you requested.

Unfortunately your build instructions did not work:

$ ./mach build
mach and the build system store shared state in a common directory on the
filesystem. The following directory will be created:

  /home/nuc/.mozbuild

If you would like to use a different directory, hit CTRL+c and set the
MOZBUILD_STATE_PATH environment variable to the directory you would like to
use and re-run mach. For this change to take effect forever, you'll likely
want to export this environment variable from your shell's init scripts.

20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
Creating default state directory: /home/nuc/.mozbuild
Please re-run mach.


Then:


$ ./mach run
It looks like your program isn't built. You can run |mach build| to build it.
config.status not available. Run configure.


So I tried ./mach build again:


./mach build
 0:00.12 /usr/bin/gmake -f client.mk -s
 0:00.21 client.mk:214: obj-x86_64-unknown-linux-gnu/.mozconfig.mk: Datei oder Verzeichnis nicht gefunden
 0:00.24 Traceback (most recent call last):
 0:00.24   File "/home/nuc/mozilla-release/config/pythonpath.py", line 56, in <module>
 0:00.24     main(sys.argv[1:])
 0:00.24   File "/home/nuc/mozilla-release/config/pythonpath.py", line 48, in main
 0:00.24     execfile(script, frozenglobals)
 0:00.24 NameError: global name 'execfile' is not defined
 0:00.24 client.mk:346: die Regel für Ziel „obj-x86_64-unknown-linux-gnu/CLOBBER“ scheiterte
 0:00.24 gmake: *** [obj-x86_64-unknown-linux-gnu/CLOBBER] Fehler 1
 0:00.29 0 compiler warnings present.
Error running mach:

    ['build']

The error occurred in code that was called by the mach command. This is either
a bug in the called code itself or in the way that mach is calling it.

You should consider filing a bug for this issue.

If filing a bug, please include the full output of mach, including this error
message.

The details of the failure are as follows:

IOError: [Errno 13] Permission denied: u'/home/nuc/mozilla-release/obj-x86_64-unknown-linux-gnu/.mozbuild/warnings.json'

  File "/home/nuc/mozilla-release/python/mozbuild/mozbuild/mach_commands.py", line 374, in build
    monitor.finish(record_usage=status==0)
  File "/home/nuc/mozilla-release/python/mozbuild/mozbuild/controller/building.py", line 251, in finish
    self.warnings_database.save_to_file(self._warnings_path)
  File "/home/nuc/mozilla-release/python/mozbuild/mozbuild/compilation/warnings.py", line 275, in save_to_file
    with open(filename, 'wb') as fh:

Comment 5

[:Gijs (he/him)]

(In reply to nucrap from comment #4)
> IOError: [Errno 13] Permission denied:
> u'/home/nuc/mozilla-release/obj-x86_64-unknown-linux-gnu/.mozbuild/warnings.
> json'

Did you build as another user or root before? It sounds like the build system can't update files in your object directory (obj-...-linux-gnu).

It probably makes sense to just rm -rf the obj-x86_... directory ("clobber" - or just move it out of the way, I guess, depending on your disk space situation), and then run ./mach build again.

As for your buildconfig, it says:

 --with-system-png

which explains what's going on here. It seems like your machine's libpng doesn't know about animated png (which happens a lot).

Please reopen if, after a successful "stock" build, you're still having issues. If you have more issues getting the build to work, you'll get help more quickly on IRC ( #introduction channel on irc.mozilla.org). :-)

Comment 6

[nucrap]

Thanks, how can I enable support for those animated png's in libpng? Since when are there animated png?? Why not gif?^^

I guess it's a downstream gentoo/funtoo issue then.

Comment 7

[Michael]

(In reply to nucrap from comment #6)
> Thanks, how can I enable support for those animated png's in libpng? Since
> when are there animated png?? Why not gif?^^
> 
> I guess it's a downstream gentoo/funtoo issue then.

Usually I'd say you need USE="apng" for libpng, but that's not the case. I have the same issue, and my libpng supports animated pngs.

Comment 8

[nucrap]

Yes that's right, mine also does.. the culprit must lay somewhere else.

Comment 9

[Michael]

(In reply to nucrap from comment #8)
> Yes that's right, mine also does.. the culprit must lay somewhere else.

https://bug841734.bugzilla.mozilla.org/attachment.cgi?id=748550

here is a fixed icon, if you're interested.

Comment 10

[:Gijs (he/him)]

(In reply to Michael from comment #7)
> (In reply to nucrap from comment #6)
> > Thanks, how can I enable support for those animated png's in libpng? Since
> > when are there animated png?? Why not gif?^^
> > 
> > I guess it's a downstream gentoo/funtoo issue then.
> 
> Usually I'd say you need USE="apng" for libpng, but that's not the case. I
> have the same issue, and my libpng supports animated pngs.

Are you sure those aren't "mng" rather than "apng"... ? They are different specs. :-(

I think it would make sense to exclude a downstream issue first before reopening, but if it really isn't a downstream issue, this should probably be reopened and reinvestigated.

Do your builds without the --with-system-png work?

Comment 11

[Michael]

(In reply to :Gijs Kruitbosch from comment #10)
> Are you sure those aren't "mng" rather than "apng"... ? They are different
> specs. :-(
> 
> I think it would make sense to exclude a downstream issue first before
> reopening, but if it really isn't a downstream issue, this should probably
> be reopened and reinvestigated.
> 
> Do your builds without the --with-system-png work?


Yes, I'm sure it's apng. 
Installed versions:  1.6.13(01:36:09 25.08.2014)(apng -neon -static-libs ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="32 64 -x32")
And the fixed png file from https://bug841734.bugzilla.mozilla.org/attachment.cgi?id=748550 works.

I haven't tried bundled libpng, since there's no use flag for that in gentoo any more it seems... I would test it if no one else did.