Bug 226476 - www/firefox: update to 60.0
Summary: www/firefox: update to 60.0
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-gecko mailing list
URL: https://wiki.mozilla.org/Releases/Fir...
Keywords: needs-qa, patch
Depends on: 223425 225627
Blocks: 227850
  Show dependency treegraph
 
Reported: 2018-03-09 15:04 UTC by Jan Beich
Modified: 2018-05-25 16:17 UTC (History)
8 users (show)

See Also:
bugzilla: maintainer-feedback? (gecko)


Attachments
beta2 (devedition) (845.45 KB, patch)
2018-03-09 15:04 UTC, Jan Beich
no flags Details | Diff
beta3 (433.92 KB, patch)
2018-03-13 01:04 UTC, Jan Beich
no flags Details | Diff
beta4 (434.22 KB, patch)
2018-03-16 11:27 UTC, Jan Beich
no flags Details | Diff
bsd.gecko.mk-sndio.diff (920 bytes, patch)
2018-03-16 17:25 UTC, Tobias Kortkamp
no flags Details | Diff
beta5 (61.24 KB, patch)
2018-03-20 01:01 UTC, Jan Beich
no flags Details | Diff
beta6 (crashes on i386) (144.28 KB, patch)
2018-03-23 00:08 UTC, Jan Beich
no flags Details | Diff
beta6 (rebased after r465446) (144.22 KB, patch)
2018-03-24 10:47 UTC, Jan Beich
no flags Details | Diff
beta7 (140.80 KB, patch)
2018-03-26 23:57 UTC, Jan Beich
no flags Details | Diff
beta8 (rebased against ports r465943) (169.36 KB, patch)
2018-03-30 03:22 UTC, Jan Beich
no flags Details | Diff
beta9 (rebased after ports r466270) (169.36 KB, patch)
2018-04-03 02:41 UTC, Jan Beich
no flags Details | Diff
beta10 (rebased after ports r466432) (169.53 KB, patch)
2018-04-05 00:57 UTC, Jan Beich
no flags Details | Diff
beta11 (rebased after ports r466648) (169.54 KB, patch)
2018-04-10 00:21 UTC, Jan Beich
no flags Details | Diff
beta12 (169.54 KB, patch)
2018-04-13 13:01 UTC, Jan Beich
no flags Details | Diff
beta13 (rebased after ports r467551) (187.48 KB, patch)
2018-04-17 01:37 UTC, Jan Beich
no flags Details | Diff
beta14 (187.50 KB, patch)
2018-04-20 15:19 UTC, Jan Beich
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer 2018-03-09 15:04:41 UTC
Created attachment 191341 [details]
beta2 (devedition)

Due to chronic lack of time[1] this may be the last release to support WebRTC. For 60 gyp->gn conversion was reverted (see files/patch-a-gyp-webrtc) but after WebRTC is updated[2] only --disable-webrtc will work.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1437670
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1376873
Comment 1 Carlos J. Puga Medina freebsd_committer 2018-03-09 21:44:15 UTC
In Chromium, it has been the other way around; now WebRTC is required by default to compile Chromium.

Unfortunately, WebRTC is not fully supported on FreeBSD.
Comment 2 Jan Beich freebsd_committer 2018-03-13 01:04:32 UTC
Created attachment 191460 [details]
beta3
Comment 3 Jan Beich freebsd_committer 2018-03-16 11:27:22 UTC
Created attachment 191546 [details]
beta4
Comment 4 Tobias Kortkamp freebsd_committer 2018-03-16 17:25:49 UTC
Created attachment 191556 [details]
bsd.gecko.mk-sndio.diff

Hi,

60.0b4 fails to patch with SNDIO=on because webrtc has moved a little
bit in the tree.

Patching webrtc doesn't seem to be necessary anymore so guarding it
for older Gecko versions (like we did with the cubeb tests a while ago)
should be enough to workaround this.

I built Waterfox and Firefox 60.0b4 with the attached patch and
everything seems to work ok as before.  Can you include it in the
update?
Comment 5 Tobias Kortkamp freebsd_committer 2018-03-17 07:43:25 UTC
Comment on attachment 191556 [details]
bsd.gecko.mk-sndio.diff

The patch is needed for a Pale Moon update as well when building with SNDIO=on
since they completely removed WebRTC code in 27.8.0.  Ok to land it now?
Comment 6 Jan Beich freebsd_committer 2018-03-18 23:07:38 UTC
Comment on attachment 191556 [details]
bsd.gecko.mk-sndio.diff

Looks OK.

"if...fi" block can have more than one command or none at all (e.g., "if true; false; then else fi") terminated by either newline or semicolon. By terminating a command on the same line as "fi" you're making it harder to append another command within the conditionals.
Comment 7 commit-hook freebsd_committer 2018-03-19 05:47:04 UTC
A commit references this bug:

Author: tobik
Date: Mon Mar 19 05:46:03 UTC 2018
New revision: 464981
URL: https://svnweb.freebsd.org/changeset/ports/464981

Log:
  Fix post-patch-SNDIO-on in preparation of updates to www/firefox 60.0
  and to www/palemoon 27.8.1

  Some patches no longer apply to them.  WebRTC has moved paths in
  Firefox 60.0 and no longer needs to be patched.  Pale Moon removed
  WebRTC completely in 27.8.0.

  PR:		226476
  Approved by:	gecko (jbeich)

Changes:
  head/Mk/bsd.gecko.mk
Comment 8 Jan Beich freebsd_committer 2018-03-20 01:01:42 UTC
Created attachment 191654 [details]
beta5

WebRTC is back on track with Landry's help. Unfortunately, I haven't found time to rebase libv4l patch.
Comment 9 Tobias Kortkamp freebsd_committer 2018-03-22 16:02:10 UTC
(In reply to Jan Beich from comment #8)
beta5 builds fine and also mostly runs ok, however when I try to print something
it takes forever for the print preview window to actually show up and the UI 
completely freezes up.

Hmm, this also happens with Firefox 59.0.1,1 with default options, so I guess
it's nothing new.
Comment 10 Tobias Kortkamp freebsd_committer 2018-03-22 16:31:36 UTC
(In reply to Tobias Kortkamp from comment #9)
It happened because I had the sysctl net.inet.tcp.blackhole=2 set.  Setting it
back to 0 fixes this.
Comment 12 Jan Beich freebsd_committer 2018-03-24 10:47:37 UTC
Created attachment 191780 [details]
beta6 (rebased after r465446)
Comment 14 Jan Beich freebsd_committer 2018-03-28 12:33:19 UTC
Can someone build the binary package(s) for beta7 or (tonight) for beta8? A user contacted me privately offering to help testing Firefox 60 but lacks powerful enough hardware to build the port. Bug 222225 comment 17 describes why I can't.
Comment 15 Greg V 2018-03-28 20:58:37 UTC
(In reply to Jan Beich from comment #14)
Package for stable or current?
Comment 16 D. Ebdrup 2018-03-29 08:03:20 UTC
Ah, my apologies. I somehow completely missed finding this bug when searching for it.

I'm on 11.1-RELEASE, so I imagine -STABLE should do it?
Comment 17 Jan Beich freebsd_committer 2018-03-29 08:19:25 UTC
Assuming amd64?
Comment 18 D. Ebdrup 2018-03-29 09:18:52 UTC
Should've probably just included uname -a from the start: FreeBSD nerd-thinkpad.local 11.1-RELEASE-p8 FreeBSD 11.1-RELEASE-p8 #0: Tue Mar 13 17:07:05 UTC 2018     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
Comment 22 D. Ebdrup 2018-04-06 12:16:55 UTC
So, there's no chance of having someone build it? Although I see that v4l is getting dropped for lack of time, so webcam support is gonna break anyhow, it seems.. Wish I had the talent or money to do something about that, but I don't.
Comment 23 Jan Beich freebsd_committer 2018-04-06 12:39:13 UTC
Not v4l but libv4l. Only useful if a webcam doesn't support v4l2 or one of WebRTC video formats[1]. Contributed by someone who had JPEG-only camera but, looking at the code, libv4l should no longer be necessary.

[1] https://searchfox.org/mozilla-central/rev/d0413b711da4/media/webrtc/trunk/webrtc/modules/video_capture/linux/video_capture_linux.cc#222-230
[2] https://chromium.googlesource.com/external/webrtc/+/6b6eb44cca%5E!/
Comment 24 Joseph Mingrone freebsd_committer 2018-04-08 11:44:08 UTC
b10 builds successfully here with the options below: http://pkg.awarnach.mathstat.dal.ca/data/11amd64-default/2018-04-08_08h09m26s/logs/firefox-60.0.b10,1.log

% poudriere options -j 11amd64 -sn www/firefox
[00:00:00] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf
===> The following configuration options are available for firefox-60.0.b10,1:
     CANBERRA=off: Sound theme alerts
     DBUS=off: D-Bus IPC system support
     DEBUG=off: Build with debugging support
     DTRACE=on: Build with DTrace probes
     FFMPEG=on: FFmpeg support (WMA, AIFF, AC3, APE...)
     GCONF=off: GConf configuration backend support
     INTEGER_SAMPLES=off: Integer audio sample format
     LIBPROXY=off: Proxy support via libproxy
     OPTIMIZED_CFLAGS=on: Use extra compiler optimizations
     PROFILE=off: Build with profiling support
     TEST=off: Build and/or run tests
====> Options available for the multi AUDIO: you have to choose at least one of them
     ALSA=off: ALSA audio architecture support
     JACK=off: JACK audio server support
     PULSEAUDIO=off: PulseAudio sound server support
     SNDIO=on: Sndio audio support

I will also test with default options and report back.
Comment 26 D. Ebdrup 2018-04-09 20:46:10 UTC
Since my webcam feed isn't showing up in Firefox 60 beta10 with default options, despite the fact that it works in Firefox 58 (from the official packages), I decided to try enabling debug options.
However, even with MAKE_UNSAFE_JOBS=yes, I get the error shown on [1] while running make package with the debug option enabled on a system with FreeBSD 11.1-STABLE r330643 according to uname -a.


[1] http://termbin.com/43yi
Comment 27 Jan Beich freebsd_committer 2018-04-09 22:13:26 UTC
I neither own a microphone or web camera nor smart enough to emulate those in order to help investigate WebRTC issues.

(In reply to D. Ebdrup from comment #26)
> my webcam feed isn't showing up

Maybe check IPC limits. For one, OpenBSD has smaller kern.shminfo.shmall default than kern.ipc.shmall on FreeBSD which breaks screen capture.

> it works in Firefox 58

DEBUG build or logging[1] won't help much unless you know what to look for. mozregression isn't usable on Tier3 platforms like FreeBSD (no upstream builds, flo@'s buildbot is down for months), so try bisecting source instead. Here's how to build Firefox outside of ports:

  $ pkg install python27 binutils
  $ hash git 2>/dev/null || pkg install mercurial
  $ hg clone https://hg.mozilla.org/mozilla-unified firefox ||
    git clone https://github.com/mozilla/gecko-dev firefox
  $ cd firefox
  $ hg update release || git checkout origin/release
  $ echo "export COMPILER_PATH=/usr/local/bin" >>.mozconfig
  $ echo "ac_add_options --disable-debug-symbols" >>.mozconfig
  $ ./mach bootstrap # select Firefox for Desktop
  $ ./mach build
  $ ./mach run https://mozilla.github.io/webrtc-landing/

[1] https://wiki.mozilla.org/Media/WebRTC/Logging

> ../../build/unix/gold/ld: error: /usr/ports/www/firefox/work/.build/toolkit/library/../../js/src/js-dtrace.o: unexpected reloc 8 in object file
> /usr/ports/www/firefox/work/.build/toolkit/library/../../js/src/js-dtrace.o:/usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/lib/libdtrace/common/drti.c:__SUNW_dof: 
> error: unexpected reloc 8 in object file
> c++: error: linker command failed with exit code 1 (use -v to see invocation)

Disable DTRACE option and try again.
Comment 29 D. Ebdrup 2018-04-10 12:12:44 UTC
(In reply to Jan Beich from comment #27)
>OpenBSD
But I'm using FreeBSD, so I don't see how that's relevant. Still, I've upped kern.ipc.shmall to 262k instead of the 131k it was at - so whatever limits there may be shouldn't be a problem.

>Logging
I'll try messing around with it anyhow - with pkg, it's remarkably easy to switch between the working and non-working version of Firefox, so I should be able to tell if it reports anything different, and possibly find out what that means. 

>Disable DTRACE option
The thing is, I only get the dtrace errors if the DEBUG option is turned on. The first package that I built, and that I'm using to test with, is built with default options and didn't get any errors. 


Long of the short of it is - Don't feel you have to delay the port on my account, though - if I need webrtc, I'll install the working version temporarily, no reason to have that delay a new version of the port going out.

If I find a real bug in FreeBSDs port, or better yet a fix, I'll file a separate report.
Comment 32 Li-Wen Hsu freebsd_committer 2018-04-17 08:53:15 UTC
beta13 works for me (12.0-CURRENT r332357).  I tested some demoes on https://webrtc.github.io/samples/ and look good to me.

Sadly, Google Handouts still doesn't work.
Comment 34 Jan Beich freebsd_committer 2018-04-24 18:28:59 UTC
Comment on attachment 192684 [details]
beta14

Time to move the patch to Phabricator. Bugzilla support for interdiffs is poor and it doesn't allow patches larger than 1 Mb.

Firefox 60 enables WebAuthn by default with Google Accounts support. Greg V implemented FreeBSD support, so I've integrated it into the patch.
https://www.mail-archive.com/dev-platform@lists.mozilla.org/msg24759.html
https://github.com/jcjones/u2f-hid-rs/pull/62

Patch: https://reviews.freebsd.org/D15186?download=true
Changes (since beta14): https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?startdate=2018-04-20&enddate=2018-04-24
Comment 35 commit-hook freebsd_committer 2018-05-01 00:52:14 UTC
A commit references this bug:

Author: jbeich
Date: Tue May  1 00:51:38 UTC 2018
New revision: 468751
URL: https://svnweb.freebsd.org/changeset/ports/468751

Log:
  www/firefox: update to 60.0

  - Add U2F support, required by Web Authentication [1]
  - Drop libv4l support to reduce maintenance

  Changes:	https://www.mozilla.org/firefox/60.0/releasenotes/
  PR:		226476
  Tested by:	tobik, jrm, D. Ebdrup, lwhsu
  Submitted by:	Greg V [1]
  Security:	5aefc41e-d304-4ec8-8c82-824f84f08244
  MFH:		2018Q2
  Differential Revision:	https://reviews.freebsd.org/D15186

Changes:
  head/Mk/Uses/gecko.mk
  head/Mk/bsd.gecko.mk
  head/www/firefox/Makefile
  head/www/firefox/distinfo
  head/www/firefox/files/patch-bug1021761
  head/www/firefox/files/patch-bug1433747
  head/www/firefox/files/patch-bug1438678
  head/www/firefox/files/patch-bug1444083
  head/www/firefox/files/patch-bug1444798
  head/www/firefox/files/patch-bug1447925
  head/www/firefox/files/patch-bug1452041
  head/www/firefox/files/patch-bug826985
  head/www/firefox/files/patch-u2f-hid-rs62
  head/www/firefox/files/patch-z-bug1436911
  head/www/firefox/files/patch-z-bug517422
  head/www/firefox/pkg-message
  head/www/firefox-i18n/Makefile
  head/www/firefox-i18n/Makefile.lang
  head/www/firefox-i18n/Makefile.option
  head/www/firefox-i18n/distinfo
Comment 36 Jan Beich freebsd_committer 2018-05-01 01:05:31 UTC
60 rollout has started, ahead of upstream because our QA is different. www/firefox-i18n is still at beta16 due to a hiccup on Mozilla infra[1] but it should work fine with rc1.

[1] https://treeherder.mozilla.org/#/jobs?repo=mozilla-release&revision=9ef500ce24aa
Comment 37 jakub_lach 2018-05-01 14:38:48 UTC
I've lost l18n in xterm/firefox after upgrade to firefox 60. I wonder what has happened in that timeframe?
Comment 38 jakub_lach 2018-05-01 15:07:21 UTC
(In reply to jakub_lach from comment #37)
 ^ that was recent xkbcomp update
Comment 39 commit-hook freebsd_committer 2018-05-03 20:42:06 UTC
A commit references this bug:

Author: jbeich
Date: Thu May  3 20:41:54 UTC 2018
New revision: 468985
URL: https://svnweb.freebsd.org/changeset/ports/468985

Log:
  www/firefox: switch to rc2

  Changes:	https://hg.mozilla.org/releases/mozilla-release/pushloghtml?startdate=2018-05-01&enddate=2018-05-04
  PR:		226476

Changes:
  head/www/firefox/Makefile
  head/www/firefox/distinfo
  head/www/firefox-i18n/Makefile
  head/www/firefox-i18n/distinfo
Comment 40 Graham Perrin 2018-05-05 13:33:22 UTC
60.0,1 looking good to me, thanks.
Comment 41 jakub_lach 2018-05-05 14:07:31 UTC
I know that's not much, but since Firefox 60 introduction to www/firefox, it was nothing but multiple coredumps daily, something I have not seen for a very long time.
Comment 42 jakub_lach 2018-05-05 14:10:52 UTC
May  5 16:05:18 Thinkpad kernel: pid 750 (firefox), uid 1001: exited on signal 11 (core dumped)
May  5 16:05:21 Thinkpad kernel: pid 752 (firefox), uid 1001: exited on signal 11 (core dumped)
May  5 16:05:24 Thinkpad kernel: pid 755 (firefox), uid 1001: exited on signal 11 (core dumped)
May  5 16:05:26 Thinkpad kernel: pid 754 (firefox), uid 1001: exited on signal 11 (core dumped)
May  5 16:05:30 Thinkpad kernel: pid 753 (firefox), uid 1001: exited on signal 11 (core dumped)
May  5 16:08:40 Thinkpad kernel: pid 765 (firefox), uid 1001: exited on signal 11 (core dumped)
May  5 16:08:42 Thinkpad kernel: pid 769 (firefox), uid 1001: exited on signal 11 (core dumped)
May  5 16:08:45 Thinkpad kernel: pid 767 (firefox), uid 1001: exited on signal 11 (core dumped)
May  5 16:08:46 Thinkpad kernel: pid 773 (firefox), uid 1001: exited on signal 11 (core dumped)

I would go to ESR, but unfortunately, my .mozilla profile is too far removed from it already.
Comment 43 Jan Beich freebsd_committer 2018-05-05 15:02:17 UTC
(In reply to jakub_lach from comment #41)
As in "not much" details to help troubleshooting? Get a backtrace, try the binary package, try in a jail or different machine, try a fresh profile, try to disable e10s, find another user with the same issue. I don't see crashes on FreeBSD 10.4 i386.

Mozilla doesn't test on FreeBSD at all and there's no automated crash reporting or telemetry to fall back on. Hoping the issue would disappear on its own by release announcement is often pointless. Otherwise, even Nightly on FreeBSD is stable enough for daily usage sans occasional bustage.
Comment 44 Jan Beich freebsd_committer 2018-05-05 15:27:35 UTC
(In reply to jakub_lach from comment #42)
> May  5 16:05:18 Thinkpad kernel: pid 750 (firefox), uid 1001: exited on signal 11 (core dumped)
> May  5 16:05:21 Thinkpad kernel: pid 752 (firefox), uid 1001: exited on signal 11 (core dumped)
> May  5 16:05:24 Thinkpad kernel: pid 755 (firefox), uid 1001: exited on signal 11 (core dumped)

Only content processes crash? Does it happen on every site or those that contain certain (e.g., audio/video) elements? If the latter make sure firefox dependencies are also up to date: ffmpeg, libvpx, harfbuzz, etc.
Comment 45 jakub_lach 2018-05-05 16:24:43 UTC
Yes, as in "not much" in terms of troubleshooting. The profile was remade from scratch a month or so ago. If I get something more substantial, I will get back to you. It's a 11-STABLE amd64, ports are up do date.
Comment 46 jakub_lach 2018-05-05 23:51:22 UTC
(In reply to jakub_lach from comment #45)

What do I now know, 

- premade binary package crashes too
- fresh profile also

What triggers it?

Can't point a finger, but multiple YouTube videos (50+) and closing a Firefox is a good bet (cannot exit cleanly, that was a fresh profile and a package from ports). Sometime it's only a single tab and it does not take whole Firefox down, but both kinds really.

Last time I needed bt from Firefox (a few years ago) I remember I needed to turn DEBUG on a lot of things (it was gstreamer iirc and it went away by itself).
Comment 47 Graham Perrin 2018-05-06 01:43:34 UTC
> 60.0,1 looking good to me, thanks.

More specifically: 

- 60.0,1
- e10s enabled
- HP EliteBook 8570p with 16 GB memory, 
  <https://wiki.freebsd.org/Laptops/HP_EliteBook_8570p>
- FreeBSD-CURRENT, 

$ uname -v
FreeBSD 12.0-CURRENT #0 r333193: Thu May  3 10:59:06 BST 2018     root@momh167-gjp4-hpelitebook8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC 

----

I pushed harder. e10s disabled (browser.tabs.remote.force-disable), to tell whether the app would crash. 

1,245 tabs across fifteen windows, restored with Session Boss: OK. Then I browsed to a few other tabs, and quit. 

The same number of tabs, restored with the History menu: OK. An after effect of using Session Boss: if restoration is performed without Session Boss, then it may be necessary to manually load tabs. Disabled Session Boss, enabled Tab Session Manager, saved the session, quit. 

The same number, restored with Tab Session Manager: OK. Some restored tabs become blank when activated, re: <https://github.com/sienori/Tab-Session-Manager/issues/238> (not an issue with Tab Session Manager) it's an after-effect of using Session Boss: re: Added Tip Tab <https://addons.mozilla.org/addon/tip-tab/>, disabled Tab Session Manager, re-enabled Session Boss, re-enabled e10s, quit. 

The same number, restored with Session Boss: in progress. I'll revisit later, use Tip Tab to load some (restored) YouTube tabs.
Comment 48 Graham Perrin 2018-05-06 07:55:21 UTC
> … disabled Tab Session Manager, 
> re-enabled Session Boss, 
> re-enabled e10s, quit. …

I forgot to re-enable e10s. 

> The same number, restored with Session Boss: …

– was OK. 

> … use Tip Tab to load some (restored) YouTube tabs.

Within the restored session I found (with Tip Tab) and loaded three YouTube videos. 

At some point during the session – maybe whilst the three videos played concurrently – there was, in response to a click on (or load of) a tab, _momentary_ appearance of a content process. The momentary multi-process surprised me, but I don't know whether it's a bug: 

- is it _ever_ appropriate to have 
  more than one process when 
  browser.tabs.remote.force-disable is true? 

I guess that Mozilla may invalidate any bug report that involves browser.tabs.remote.force-disable with Firefox Quantum. 

Jan, any thoughts? Would you like this spun off to a separate bug report in either the Mozilla or FreeBSD area?

TIA
Comment 49 commit-hook freebsd_committer 2018-05-07 20:33:53 UTC
A commit references this bug:

Author: jbeich
Date: Mon May  7 20:33:24 UTC 2018
New revision: 469334
URL: https://svnweb.freebsd.org/changeset/ports/469334

Log:
  MFH: r468751 r468754 r468985 r469332

  www/firefox: update to 60.0

  - Add U2F support, required by Web Authentication [1]
  - Drop libv4l support to reduce maintenance

  Changes:	https://www.mozilla.org/firefox/60.0/releasenotes/
  PR:		226476
  Tested by:	tobik, jrm, D. Ebdrup, lwhsu
  Submitted by:	Greg V [1]
  Security:	5aefc41e-d304-4ec8-8c82-824f84f08244
  Approved by:	ports-secteam blanket
  Differential Revision:	https://reviews.freebsd.org/D15186

Changes:
_U  branches/2018Q2/
  branches/2018Q2/Mk/Uses/gecko.mk
  branches/2018Q2/Mk/bsd.gecko.mk
  branches/2018Q2/www/firefox/Makefile
  branches/2018Q2/www/firefox/distinfo
  branches/2018Q2/www/firefox/files/patch-bug1021761
  branches/2018Q2/www/firefox/files/patch-bug1375074
  branches/2018Q2/www/firefox/files/patch-bug1433747
  branches/2018Q2/www/firefox/files/patch-bug1438678
  branches/2018Q2/www/firefox/files/patch-bug1442583
  branches/2018Q2/www/firefox/files/patch-bug1444083
  branches/2018Q2/www/firefox/files/patch-bug1444798
  branches/2018Q2/www/firefox/files/patch-bug1445907
  branches/2018Q2/www/firefox/files/patch-bug1447359
  branches/2018Q2/www/firefox/files/patch-bug1447925
  branches/2018Q2/www/firefox/files/patch-bug1451292
  branches/2018Q2/www/firefox/files/patch-bug1452041
  branches/2018Q2/www/firefox/files/patch-bug1456556
  branches/2018Q2/www/firefox/files/patch-bug826985
  branches/2018Q2/www/firefox/files/patch-u2f-hid-rs62
  branches/2018Q2/www/firefox/files/patch-z-bug1436911
  branches/2018Q2/www/firefox/files/patch-z-bug517422
  branches/2018Q2/www/firefox/pkg-message
  branches/2018Q2/www/firefox-i18n/Makefile
  branches/2018Q2/www/firefox-i18n/Makefile.lang
  branches/2018Q2/www/firefox-i18n/Makefile.option
  branches/2018Q2/www/firefox-i18n/distinfo
Comment 50 Jan Beich freebsd_committer 2018-05-09 06:36:07 UTC
rc2 became release: https://hg.mozilla.org/releases/mozilla-release/rev/3202d5534730

(In reply to jakub_lach from comment #46)
Can you try removing files/patch-bug1438678 and files/patch-z-bug1436911 ? Those improve how child processes are initialized and, normally, should've been part of 61.0.

Did you toggle any prefs in about:config? In particular, gfx.xrender.enabled=true or layers.acceleration.force-enabled=true may degrade stability.

Can you check about:support what audio backend is used? There's no perfect one, each has issues.

(In reply to Graham Perrin from comment #48)
> Would you like this spun off to a separate bug report in
> either the Mozilla or FreeBSD area?

Try bug 227850 then check on Linux and macOS. FreeBSD uses posix_spawn (like macOS) to create child processes. It wouldn't hurt to file a bug on Mozilla tracker but "_momentary_ appearance of a content process" may be a normal behavior given Firefox keeps the number of content processes limited (unlike Chromium).
Comment 51 commit-hook freebsd_committer 2018-05-09 20:32:59 UTC
A commit references this bug:

Author: jbeich
Date: Wed May  9 20:32:25 UTC 2018
New revision: 469467
URL: https://svnweb.freebsd.org/changeset/ports/469467

Log:
  security/vuxml: mark firefox < 60 as vulnerable

  PR:		226476

Changes:
  head/security/vuxml/vuln.xml
Comment 52 jakub_lach 2018-05-09 22:39:13 UTC
(In reply to Jan Beich from comment #50)

> Can you try removing files/patch-bug1438678 and files/patch-z-bug1436911 ? 

Recompiling without now. I have long streaks of stable use and long streaks of coredumps, still cannot isolate the cause precisely.

>Did you toggle any prefs in about:config? In particular, >gfx.xrender.enabled=true or layers.acceleration.force-enabled=true may degrade >stability.

No, I did most of my testing with my daily profile, but neither that nor fresh clean profile (which I've also crashed) has that set.

>Can you check about:support what audio backend is used? 

Alsa

Thanks for your attention :)
Comment 53 jakub_lach 2018-05-11 19:13:16 UTC
(In reply to jakub_lach from comment #52)


> Can you try removing files/patch-bug1438678 and files/patch-z-bug1436911 ? 

Crashed version compiled without these too, albeit just once. I'll try to provide bt once I've recompile with debug.
Comment 54 jakub_lach 2018-05-11 21:30:49 UTC
86_64-unknown-freebsd/debug/libgkrust.a(std-618faf8e489f63eb.std4-60b51645c042d75ec977e9128499131e.rs.rcgu.o):std4-60b51645c042d75ec977e9128499131e.rs:function std::sys::unix::process::process_inner::<impl std::sys::unix::process::process_common::Command>::do_exec: warning: undefined reference to 'environ'
c++: error: unable to execute command: Bus error (core dumped)
c++: error: linker command failed due to signal (use -v to see invocation)
gmake[5]: *** [/usr/obj/usr/ports/www/firefox/work/firefox-60.0/config/rules.mk:701: libxul.so] Error 254
gmake[5]: Leaving directory '/usr/obj/usr/ports/www/firefox/work/.build/toolkit/library'
gmake[4]: *** [/usr/obj/usr/ports/www/firefox/work/firefox-60.0/config/recurse.mk:73: toolkit/library/target] Error 2
gmake[4]: Leaving directory '/usr/obj/usr/ports/www/firefox/work/.build'
gmake[3]: *** [/usr/obj/usr/ports/www/firefox/work/firefox-60.0/config/recurse.mk:33: compile] Error 2
gmake[3]: Leaving directory '/usr/obj/usr/ports/www/firefox/work/.build'
gmake[2]: *** [/usr/obj/usr/ports/www/firefox/work/firefox-60.0/config/rules.mk:434: all] Error 2
gmake[2]: Leaving directory '/usr/obj/usr/ports/www/firefox/work/.build'
===> Compilation failed unexpectedly.

Unfortunately linker failed in DEBUG, 

FreeBSD 11.2-PRERELEASE #0 r333148 amd64, all options unchecked beside FFMPEG, DEBUG, OPTIMIZED, ALSA
Comment 55 Jan Beich freebsd_committer 2018-05-12 10:16:04 UTC
--enable-debug enables assertions, runtime checks and disables optimizations. None of which have been tested on FreeBSD. For gdb/lldb only debug symbols and frame pointer are required e.g.,

  $ env CFLAGS=-g make clean all STRIP= WITHOUT="DEBUG DTRACE OPTIMIZED_CFLAGS" -C /usr/ports/www/firefox

or

  $ make clean all WITH_DEBUG= WITHOUT="DEBUG DTRACE OPTIMIZED_CFLAGS" -C /usr/ports/www/firefox
Comment 56 Jan Beich freebsd_committer 2018-05-12 10:22:19 UTC
OPTIMIZED_CFLAGS passes -fomit-frame-pointer unless DEBUG, DTRACE or PROFILE are enabled.
Comment 57 jakub_lach 2018-05-12 12:30:29 UTC
(In reply to Jan Beich from comment #55)

> $ make clean all WITH_DEBUG= WITHOUT="DEBUG DTRACE OPTIMIZED_CFLAGS" -C /usr/ports/www/firefox

During linking unfortunately ld went pfault and ate 8GB of RAM and 4GB of swap, looked hopeless, so I've terminated it.
Comment 58 Jan Beich freebsd_committer 2018-05-12 15:11:48 UTC
(In reply to jakub_lach from comment #57)
Try building firefox with non-debug symbols and frame pointer. Get a backtrace then rebuild the affected functions with debug symbols. If backtrace looks corrupted or incomplete rebuild every library dependency with debug symbols, including libc/libthr/rtld.
Comment 59 commit-hook freebsd_committer 2018-05-16 22:17:50 UTC
A commit references this bug:

Author: jbeich
Date: Wed May 16 22:17:01 UTC 2018
New revision: 470155
URL: https://svnweb.freebsd.org/changeset/ports/470155

Log:
  www/firefox: update to 60.0.1

  Changes:	https://www.mozilla.org/firefox/60.0.1/releasenotes/
  PR:		226476

Changes:
  head/www/firefox/Makefile
  head/www/firefox/distinfo
  head/www/firefox-i18n/Makefile
  head/www/firefox-i18n/distinfo
Comment 60 commit-hook freebsd_committer 2018-05-16 22:19:57 UTC
A commit references this bug:

Author: jbeich
Date: Wed May 16 22:19:47 UTC 2018
New revision: 470156
URL: https://svnweb.freebsd.org/changeset/ports/470156

Log:
  MFH: r470155

  www/firefox: update to 60.0.1

  Changes:	https://www.mozilla.org/firefox/60.0.1/releasenotes/
  PR:		226476
  Approved by:	ports-secteam blanket

Changes:
_U  branches/2018Q2/
  branches/2018Q2/www/firefox/Makefile
  branches/2018Q2/www/firefox/distinfo
  branches/2018Q2/www/firefox-i18n/Makefile
  branches/2018Q2/www/firefox-i18n/distinfo
Comment 61 Jan Beich freebsd_committer 2018-05-25 16:17:22 UTC
(In reply to Li-Wen Hsu from comment #32)
> Sadly, Google Handouts still doesn't work.

Can you try again?

https://old.reddit.com/r/firefox/comments/8leqgb/firefox_is_now_supported_by_google_hangouts_and/