Created attachment 411178 [details]
screenshot from firefox
As you may see, no menues, no context menu, not possible to see what one is typing. Also most graphics are not rendered in full resolution, as you can see in the screenshot.
There are also users from Alpine, having the same problem. See http://bugs.alpinelinux.org/issues/4248
I will make a second attachement with the output from the console.
It seems to be an x86 exclusive problem, amd64 and arm are not affected.
my useflags are
USE="dbus gstreamer jemalloc3 minimal system-cairo system-icu system-jpeg system-libvpx system-sqlite -bindist -custom-cflags -custom-optimization -debug -egl -gmp-autoupdate -gstreamer-0 (-hardened) -jit (-neon) (-pgo) -pulseaudio (-selinux) -startup-notification -test -wifi"
Created attachment 411180 [details]
Created attachment 411182 [details]
output from the console
as one can see, there are missing symbols.
how may I increase the verbosity to make this output more helpfull?
i believe this is fix with the in tree version. if not, then reopen.
I just tested recent firefox-46.0, the bug has not been fixed. And still no idea how to tackle this down?
(In reply to tt_1 from comment #4)
> I just tested recent firefox-46.0, the bug has not been fixed. And still no
> idea how to tackle this down?
So let me understand this correctly, firefox 38.7.0 from the tree builds, but this bug is still there?
to build properly, firefox-38.x-esr needs at least the patch for fixing upstream bug #1157864, which has been solved with firefox-42.
I am testing right now 38.8.0 for the missing menus and dialogs, but as 46.0 is still affected I cannot really imagine it has been solved in esr without being fixed in recent as well.
The tarball in the ebuilds of in tree firefox 38.x need an update. If they were using firefox-38.0-patches-05.tar.xz as in thunderbird 38.x it should work out of the box.
But it doesn't solve this bug, only build failures.
(In reply to tt_1 from comment #6)
> to build properly, firefox-38.x-esr needs at least the patch for fixing
> upstream bug #1157864, which has been solved with firefox-42.
> I am testing right now 38.8.0 for the missing menus and dialogs, but as 46.0
> is still affected I cannot really imagine it has been solved in esr without
> being fixed in recent as well.
Forefix-46.0 switched the default from cairo-gtk2 to cairo-gtk3 ; is it possible that these rendering issues may have to do with the different toolkit?
Try buildint firefox-46 with USE="force-gtk2" and see if you at least get the same results you had with firefox-45
I'll look into why firefox-38.8 isn't using the same patchset as thunderbird-38.8; it should be.
FYI, every major version of firefox is treated effectively as a fork of the codebase, so yes there can be issues fixed in older versions that are still present (or come back again) in newer ones. Similarly, though, it's possible that I just messed up patching. Thanks for your patience.
I forgot to post the emerge info of firefox. So it is indeed a gtk+-2:0 build, but I may check if using gtk+-3.0 changes anything.
www-client/firefox-46.0::gentoo was built with the following:
USE="dbus ffmpeg force-gtk2 hwaccel jemalloc3 jit system-harfbuzz system-icu system-jpeg (system-libevent) system-libvpx system-sqlite -bindist -custom-cflags -custom-optimization -debug -gmp-autoupdate (-hardened) (-neon) (-pgo) -pulseaudio (-selinux) -startup-notification (-system-cairo) -test -wifi" LINGUAS="de -af -ar -as -ast -be -bg -bn_BD -bn_IN -br -bs -ca -cs -cy -da -el -en_GB -en_ZA -eo -es_AR -es_CL -es_ES -es_MX -et -eu -fa -fi -fr -fy_NL -ga_IE -gd -gl -gu_IN -he -hi_IN -hr -hu -hy_AM -id -is -it -ja -kk -km -kn -ko -lt -lv -mai -mk -ml -mr -nb_NO -nl -nn_NO -or -pa_IN -pl -pt_BR -pt_PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv_SE -ta -te -th -tr -uk -vi -xh -zh_CN -zh_TW"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-rpath=/usr/lib/firefox"
Created attachment 434292 [details]
screenshot of website
As one may see, there is no text parsed but also all menus of the browsers UI don't have any text. But they work as expected! No crash, no segfault.
With a gtk+3 build, there is no UI at all.
Created attachment 434294 [details]
logfile from gdb
I have attached the logfile from gdb. There are a lot of warnings, including HTML parser warnings. Is it helpfull?
i'm not familiar with firefox internals and i'm working on deeper issues with musl in gentoo. you can post stuff here as you find out more, but i think this is something that upstream firefox is going to have to sort out. even alpine is mired in the same issue.
The upstream bug report suggests that we can work around this bug and
bug 559788 with something like
@@ -1120,8 +1120,7 @@ static const JSFunctionSpec number_stati
-#if (defined __GNUC__ && defined __i386__) || \
- (defined __SUNPRO_CC && defined __i386)
asm("fstcw %0" : "=m" (control) : );
control &= ~0x300; // Lower bits 8 and 9 (precision control).
possibly at the cost of wrong rounding of js code.
Created attachment 442006 [details, diff]
The problem seems to be musl's round() , if I got it right at the alpine bug ticket. There is also a patch from their mailing list, but it seems to be a bit odd and not fixing it all.
What's your opinion about it?
AFAIU, firefox' js code changes the mode of the x86 fpu from extended
double precision to double precision, breaking most of musl's libm
code. For this bug this causes 96 to be round() to 1 at some place.
alpine's patch replaces that particular round() call by an equivalent
non-libc function, which does not depend on the fpu's mode. There are
possibly other calls of libm functions not fixed by this patch.
I was trying the suggestion of the musl author to remove the fpu mode
change completely. Then libm should work fine but floating point
computations in js might have slightly different results than expected.
Anyway, it would be good to test the patches. I couldn't find a test
try out the examples from http://www.w3schools.com/js/js_numbers.asp .
I tried the alpine patch from #14 with firefox-45.3.0 from the tree without any success. Still no rendering of fonts and no menues/gui.
If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system.
Thank You for your support and understanding
The Mozilla Team