-
frg_Away
buc got it. Will take a look after sleep.
-
frg_Away
Anyone on Mint 20.2 or Ubuntu 20.04 and using beta 2.53.11b1? I am seeing crashes after the latest round of updates to kernel 5.4.100 in about:support but this is in a vbox vm and might caused by buggy guest additions. Fixed by disabling hardware acceleration for now.
-
tonymec|away
WG9s: « The connection was refused when attempting to contact www.wg9s.com. » I waited about an hour and tried again but no luck.
-
wyatt8740
so, i am still getting lots of unwanted options passed to 'as', specifically when assembling xpcom/reflect/xptcall/md/unix/xptcinvoke_asm_ppc_linux.S
-
wyatt8740
gnu as is getting passed ' -DSTATIC_EXPORTABLE_JS_API -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL'
-
wyatt8740
none of which are things I want in an assembler command line
-
wyatt8740
and I can't figure out how the xul flags are getting lumped into ASFLAGS
-
wyatt8740
(or SFLAGS)
-
wyatt8740
and I tried to make it use yasm like recommended - it didn't even seem to obey my 'AS' variable set in mozconfig
-
wyatt8740
now with yasm: yasm: FATAL: unrecognized object format `PIC'
-
wyatt8740
so i'm pretty sure there's actually something wrong with the build system when it comes to these ppc assemblies
-
wyatt8740
nasm is indeed x86 only
-
seninha
Hello, I have ChatZilla installed. I know that `seamonkey -browser` opens a new browser window and `seamonkey -mail` opens a new mail&news window. Is there an option to open a chatzilla window?
-
seninha
(I tried -chatzilla and -irc, both opens a new browser window)
-
njsg
seninha: does -chat work?
-
seninha
it does, thanks!
-
buc
frg: Do you mean that crashes only happen with 2.53.11b1, and they don't with <= 2.53.10 ? If yes, what is your HW_COMPOSITING in about:support ?
-
frg_Away
buc I was unable to reproduce initally with 2.53.10.2 but I identified the problem. It is
bug 1743551. Nothing we can do. This needs to be fixed by Ubuntu / Mint. They are shipping a faulty libX11. Disabling hardware acceleration is a workaround. 2.53.11 has some new event code from Fx 57 and beyond and I suspect this triggers it. Patch seems to be stuck in limbo since August:
launchpad.ne
-
frg_Away
t/ubuntu/+source/libx11/2:1.6.9-2ubuntu1.3
-
frg_Away
-
frg_Away
buc about:support is what actually crashes btw :) But only if it is the only tab in the browser. Opening as a second one works.
-
buc
frg: Fedora is OK, but formally CentOs'es have libX11 < 1.7.0 . "2.53.11 has some new event code from Fx 57 and beyond and I suspect this triggers it" -- any commits/bug numbers known for this?
-
frg_Away
buc CentOS 7 is fine. Ubuntu 20.04 was also fine till I updated yesterday. First tested on the old level and then crashed after update to latest X11.
-
frg_Away
buc The event queue stuff was added in
Bug 1390044. But first disabled. Need to check the bug which enabled it. Needed as a prerequsite for global events unless I/we want to rebase the world/rewrite the code.
-
buc
frg: "then crashed after update to latest X11" -- but it seems that an update of libX11 (>= 1.7.0) should fix the issue instead...
-
buc
...a regression.
-
frg_Away
buc yes or the fix in the ubuntu queue.
Bug 1399035 enabled it permanently. Need to check if setting this to false avoids the crash. Just only a hunch right now.
-
buc
It might be a problem, as I believe there are enough SM users using fairly old distributions. Forcing them to upgrade their OS is the same as "switch to Chrome" .
-
frg_Away
Nope does not help.
-
frg_Away
Even disabling hardware acceleation is 50/50 only.
-
frg_Away
buc I can't help it. It might actually be a problem in Virtualbox only. Asked in the support group if someone can test it on real hardware. My openSUSE ios not affected and centOS 7 is fine too.
-
buc
frg: Well, at least with HW acceleration whether about:support crashes reliably?
-
frg_Away
buc yes with it enabled goes down every time. Just tested Rocky 8 and it works there too out of the box.
-
frg_Away
Well Rocky 8 with latest guest additions and 3D enabled is fine. I suspect fedora will be the same. So for now I think Ubuntu 20 maybe 18 too based problem only.
-
buc
frg: How do you toggle HW acceleration? MOZ_ACCELERATED=1 or "layers.acceleration.force-enabled: pref? Or it is kinda system-wide acceleration?
-
frg_Away
buc Need to check the code in preferences. Even then it crashes now and then in the affected vms when you use about:support.
-
frg_Away
Sets layers.acceleration.disabled
-
frg_Away
-
frg_Away
Just tested the i686 version under 16.04 and ok there.
-
buc
But under Linux hs acceleration seems to be disabled by default "by platform" anyway.
-
buc
I mean HW_COMPOSITING and "Compositing: OpenGL vs. Basic" in about:support (top and bottom of the Graphics section).
-
buc
"HW_COMPOSITING" -- "blocked by default: Acceleration blocked by platform", but can enable it manually (either by the pref or the environ).
-
frg_Away
buc yes. All I can say is that it is flaky. Now about:support just worked again as second tab with Bills build. They need to ship the fix. Nothing we can do.
-
frg_Away
-
frg_Away
Have not gotten any confirmation if real hardware is affected so far.
-
buc
frg: If you still have a reliable reproducible case, could you pls check whether toggling "gfx.xrender.enable" to true affect the issue?
-
buc
"gfx.xrender.enabled"
-
frg_Away
buc crashes when set to false (default) and also when true
-
buc
Thnx
-
frg_Away
totally flaky Open it in a second tab works. Press reload ... bang
-
buc
BTW libX11 was fixed in Fedora more than year ago:
bugzilla.redhat.com/show_bug.cgi?id=1758384
-
buc
Interesting that fixed in RHEL/CentOS-8, but not in RHEL/CentOS-7 . Seems only Fedora users complained at all (not CentOS).
-
buc
Well, lets hope that old distros are unlikely to be affected, and new distros already updated libX11. "Closed Cantfix" :)
-
frg_Away
buc CentOS 7 seems to work fine so older distros seem not to be affected. Probably very timing dependent too.
-
frg_Away
buc updated TOP-9999999-fixgithubpolyfill-25312.patch with your latest fix in github 2.53
-
buc
The test
wpt.live/intersection-observer/isIntersecting-change-events.html was fixed by the
bug 1391154 (5 OK), our fixes for github revert it to a previous state "2 OK 1 FAIL" (as in 2.53.9.1). Hope it is acceptable, since formally we are more in line with the specs than WPT and Chrome. :)
-
frg_Away
buc I can live with it. Started to fix tests in the last releases basically to see if js engine changes break things. Lots of broken stuff left outside js because of bad rebases and missing stuff. But I don't care about wpt tests. Need to draw a line.
-
WG9s_
buc: as far as wpt tests go I can count the number of times the wpt tests have been updated to a new version without issues (because they evidently really don't test things) on the fingers of zero hands!
-
buc
WG9s_: just wanted to find at least some test that would show the changes made to the code. :)