If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Failing to connect to pulseaudio (libcanberra.so) results in menu hangs in Firefox

RESOLVED WONTFIX

Status

()

Core
Widget: Gtk
--
major
RESOLVED WONTFIX
7 years ago
7 years ago

People

(Reporter: jpike, Unassigned)

Tracking

Trunk
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.3) Gecko/20100426 Gentoo Firefox/3.6.3
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.3) Gecko/20100426 Gentoo Firefox/3.6.3

Hi,

Whenever I try to open a firefox menu my system freezes for 5+ seconds. Right click menus.. toolbar menus. Javascript alert boxes seem to do the same.

This is not extension related, when I run using "-safe-mode", or after deleting $HOME/.mozilla this problem still exists. I have tested firefox using multiple window managers (KDE4, awesome and fvwm2) also and the problem is the same. 

If I open firefox in a terminal I get this error in the console:

socket(): Address family not supported by protocol

So I straced firefox to check the socket arguments:

socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = -1 EAFNOSUPPORT (Address family not supported by protocol)

I have ipv6 disabled on my system. I disabled ipv6 dns lookups using about:config.

I have to wonder why firefox needs to open an ipv6 connection just to display a menu. If you trawl google you can find a lot of people complaining about this.

Reproducible: Always

Steps to Reproduce:
1. Load firefox
2. Right click
3. Wait 5 seconds for the right click menu to install
4. Damn that was annoying the first ten times and now I can't take it anymore.
5. Install Google Chrome
6. Dislike Google Chrome due to poor extension writing capabilities.
7. Grow disillusioned with all browsers.
Actual Results:  
Annoying pause where firefox totally freezes.

Expected Results:  
Firefox to open the right click menu in a reasonable frame of time. Say 0.2 seconds?
(Reporter)

Comment 1

7 years ago
When I said "my system freezes" I meant "firefox freezes".
Try safe mode. http://support.mozilla.com/en-US/kb/Safe+mode
(Reporter)

Comment 3

7 years ago
I already said in my comment that I am using safe-mode.
Is this only the first time after starting the browser or every time?
(Reporter)

Comment 5

7 years ago
It happens 100% of the time.

Comment 6

7 years ago
running FireFox on OpenSUSE 11.3/x86_64

with Firefox 3.6.6 >= ver >= 4.0b3, either native (@mozilla) or from repos (@opensuse), clicks on any/all pulldown menus have a delayed response/action of ~5 secs.

No errors, no suspicious logs, no console entries.  Just the delay.

reproducible with any/all of:
-- all extensions off
-- all plugins disabled
--vanilla profile
--new user
--safemode
-- dom.ipc.* plugin container opts --> false.

Dropping back to ver 3.5.11 from repos (@opensuse) cures the problem -- menu response is virtually instantaneous, as expected.

have not yet checked version in range > 3.5.11, < 3.6.6

Comment 7

7 years ago
also, this is wm==KDE (kdebase4-4.5.0-175.2.x86_64), in all cases, so far.

Comment 8

7 years ago
verified the issue exists for Gnome as well, in all cases ref'd above.

Comment 9

7 years ago
similar symptoms reported @
 "3seconds delay before opening any drop down menu from main toolbar"
  http://support.mozilla.com/en-US/questions/732071

Comment 10

7 years ago
more here,
 https://bugzilla.mozilla.org/show_bug.cgi?id=508127

(sooner or later there will be enough 'sightings' to accept this bug)

Comment 11

7 years ago
also here,

 http://www.pubbs.net/201003/mandriva/40641-cooker-firefox-slow-menu.html 

and,

 https://bbs.archlinux.org/viewtopic.php?pid=789515

Updated

7 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 508127

Comment 13

7 years ago
how is this a dupe?  508127 reports for 3.5.2.

this report specific states that <= 3.5.11 is OK ...

Updated

7 years ago
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---

Updated

7 years ago
Component: Menus → Widget: Gtk
Product: Firefox → Core
QA Contact: menus → gtk

Comment 14

7 years ago
per <AaronMT> @ irc, rm'ing libcanberra*

rpm -e libcanberra0-0.24-1.8.x86_64 libcanberra-gtk-0.24-1.8.x86_64 libcanberra-devel-0.24-1.8.x86_64 libcanberra-gtk0-0.24-1.8.x86_64
 error: Failed dependencies:
         libcanberra.so.0()(64bit) is needed by (installed) gnome-utils-2.30.0-1.14.x86_64
         libcanberra.so.0()(64bit) is needed by (installed) gnome-power-manager-2.30.1-3.5.x86_64
         libcanberra.so.0()(64bit) is needed by (installed) metacity-2.30.1-2.9.x86_64
         libcanberra.so.0()(64bit) is needed by (installed) evolution-2.30.1.2-3.9.x86_64
         libcanberra.so.0()(64bit) is needed by (installed) gnome-packagekit-2.30.2-3.4.x86_64
         libcanberra.so.0()(64bit) is needed by (installed) gdm-2.30.2-5.8.x86_64
         libcanberra.so.0()(64bit) is needed by (installed) gnome-panel-2.30.0-5.1.1.x86_64
         libcanberra.so.0()(64bit) is needed by (installed) transmission-gtk-2.03-0.pm.4.1.x86_64
         libcanberra-gtk is needed by (installed) gnome-control-center-2.30.1-1.13.x86_64
         libcanberra-gtk.so.0()(64bit) is needed by (installed) gnome-media-2.30.0-1.16.x86_64
         libcanberra-gtk.so.0()(64bit) is needed by (installed) libbrasero-burn0-2.30.1-2.10.x86_64
         libcanberra-gtk.so.0()(64bit) is needed by (installed) cheese-2.30.1-1.10.x86_64
         libcanberra-gtk.so.0()(64bit) is needed by (installed) gnome-utils-2.30.0-1.14.x86_64
         libcanberra-gtk.so.0()(64bit) is needed by (installed) gnome-power-manager-2.30.1-3.5.x86_64
         libcanberra-gtk.so.0()(64bit) is needed by (installed) libcheese-gtk18-2.30.1-1.10.x86_64
         libcanberra-gtk.so.0()(64bit) is needed by (installed) gnome-settings-daemon-2.30.1-2.6.x86_64
         libcanberra-gtk.so.0()(64bit) is needed by (installed) metacity-2.30.1-2.9.x86_64
         libcanberra-gtk.so.0()(64bit) is needed by (installed) evolution-2.30.1.2-3.9.x86_64
         libcanberra-gtk.so.0()(64bit) is needed by (installed) gnome-packagekit-2.30.2-3.4.x86_64
         libcanberra-gtk.so.0()(64bit) is needed by (installed) gdm-2.30.2-5.8.x86_64
         libcanberra-gtk.so.0()(64bit) is needed by (installed) gnome-panel-2.30.0-5.1.1.x86_64
         libcanberra-gtk.so.0()(64bit) is needed by (installed) transmission-gtk-2.03-0.pm.4.1.x86_64

zypper rm --force libcanberra0 libcanberra-gtk libcanberra-devel libcanberra-gtk0

breaks a bunch of Gnome-related pkgs, but *fixes* the menu-delay issue in Firefox 3.6.8

Comment 15

7 years ago
after an immediately subsequent reinstall

  zypper in libcanberra0 libcanberra-gtk libcanberra-gtk0 

Firefox 3.6.8+ once again exhibit the 5+ second delay, as reported

Updated

7 years ago
Summary: firefox freezes for 5 seconds when opening menus → Failing to connect to pulseaudio (libcanberra.so) results in menu hangs in Firefox

Updated

7 years ago
Version: unspecified → Trunk

Updated

7 years ago
Status: REOPENED → NEW
dev001, please mention here if a) you have pulseaudio and b) the version of it

Comment 17

7 years ago
(In reply to comment #16)
> dev001, please mention here if a) you have pulseaudio and b) the version of it

Pulseaudio is not installed -- never has been.

two pulse-related libs are installed,

rpm -qa | grep -i pulse
 libpulse0-0.9.21-9.2.x86_64
 libpulse-mainloop-glib0-0.9.21-9.2.x86_64

and req'd by other system 'parts',

        libpulse-simple.so.0()(64bit) is needed by (installed) sox-14.3.1-1.11.x86_64
        libpulse-simple.so.0()(64bit) is needed by (installed) espeak-1.43.03-1.10.x86_64
        libpulse-simple.so.0()(64bit) is needed by (installed) libfluidsynth1-1.1.1-1.pm.2.2.x86_64
        libpulse-simple.so.0(PULSE_0)(64bit) is needed by (installed) sox-14.3.1-1.11.x86_64
        libpulse-simple.so.0(PULSE_0)(64bit) is needed by (installed) espeak-1.43.03-1.10.x86_64
        libpulse-simple.so.0(PULSE_0)(64bit) is needed by (installed) libfluidsynth1-1.1.1-1.pm.2.2.x86_64
        libpulse.so.0()(64bit) is needed by (installed) gnome-media-2.30.0-1.16.x86_64
        libpulse.so.0()(64bit) is needed by (installed) sox-14.3.1-1.11.x86_64
        libpulse.so.0()(64bit) is needed by (installed) gnome-settings-daemon-2.30.1-2.6.x86_64
        libpulse.so.0()(64bit) is needed by (installed) libphonon4-4.4.2-47.1.x86_64
        libpulse.so.0()(64bit) is needed by (installed) espeak-1.43.03-1.10.x86_64
        libpulse.so.0()(64bit) is needed by (installed) gstreamer-0_10-plugins-good-0.10.24-999.pm.999.1.x86_64
        libpulse.so.0()(64bit) is needed by (installed) MPlayer-1.0rc4_r31930-1.pm.3.1.x86_64
        libpulse.so.0()(64bit) is needed by (installed) libcanberra0-0.24-1.8.x86_64
        libpulse.so.0(PULSE_0)(64bit) is needed by (installed) gnome-media-2.30.0-1.16.x86_64
        libpulse.so.0(PULSE_0)(64bit) is needed by (installed) sox-14.3.1-1.11.x86_64
        libpulse.so.0(PULSE_0)(64bit) is needed by (installed) gnome-settings-daemon-2.30.1-2.6.x86_64
        libpulse.so.0(PULSE_0)(64bit) is needed by (installed) libphonon4-4.4.2-47.1.x86_64
        libpulse.so.0(PULSE_0)(64bit) is needed by (installed) espeak-1.43.03-1.10.x86_64
        libpulse.so.0(PULSE_0)(64bit) is needed by (installed) gstreamer-0_10-plugins-good-0.10.24-999.pm.999.1.x86_64
        libpulse.so.0(PULSE_0)(64bit) is needed by (installed) MPlayer-1.0rc4_r31930-1.pm.3.1.x86_64
        libpulse.so.0(PULSE_0)(64bit) is needed by (installed) libcanberra0-0.24-1.8.x86_64
        libpulse0 >= 0.9.11 is needed by (installed) libcanberra0-0.24-1.8.x86_64
        libpulse-mainloop-glib.so.0()(64bit) is needed by (installed) gnome-media-2.30.0-1.16.x86_64
        libpulse-mainloop-glib.so.0()(64bit) is needed by (installed) gnome-settings-daemon-2.30.1-2.6.x86_64
        libpulse-mainloop-glib.so.0()(64bit) is needed by (installed) libphonon4-4.4.2-47.1.x86_64
        libpulse-mainloop-glib.so.0(PULSE_0)(64bit) is needed by (installed) gnome-media-2.30.0-1.16.x86_64
        libpulse-mainloop-glib.so.0(PULSE_0)(64bit) is needed by (installed) gnome-settings-daemon-2.30.1-2.6.x86_64
        libpulse-mainloop-glib.so.0(PULSE_0)(64bit) is needed by (installed) libphonon4-4.4.2-47.1.x86_64

Comment 18

7 years ago
Created attachment 466689 [details]
strace @ FF pid 'across' menu click, delay, and popup events

strace @ FF pid 'across' menu click, delay, and popup events

Comment 19

7 years ago
just to be clear,  the symptoms seem to suggest not:

"Failing to connect to pulseaudio (libcanberra.so) results in menu hangs in Firefox"

but rather that if libcanberra*.so is NOT installed, then menus hang in FF.

unless it's clear/presumed that code checks for presence of libcanberra*so, and if present attempts to link/connect, and _then_ fails to do so.

is that definitely the case?

Comment 20

7 years ago
agh,

--- that if libcanberra*.so is NOT installed, then menus hang in FF
+++ that if libcanberra*.so IS installed, then menus hang in FF

Comment 21

7 years ago
comparing "strace -e trace=network" @ menu click event,

case:
 (1) no canberra,   no pulseaudio     ---> NO menu delay
 (2) with canberra, no pulseaudio     ---> 5+ second menu delay
 (3) with canberra, with pulseaudio   ---> NO menu delay

(1) rpm -e --nodeps `rpm -qa | grep -i canberra`
rpm -qa | grep -i canberra
	(empty)
launch Firefox
strace -p`ps ax | grep firefox | grep Sl | awk '{print $1}'` -e trace=network
	Process 9886 attached - interrupt to quit
	(empty)
	Process 9886 detached

(2) zypper in libcanberra-gtk libcanberra-devel libcanberra-gtk0 libcanberra0
	libcanberra-devel-0.24-1.8.x86_64
	libcanberra0-0.24-1.8.x86_64
	libcanberra-gtk-0.24-1.8.x86_64
	libcanberra-gtk0-0.24-1.8.x86_64
launch Firefox
strace -p`ps ax | grep firefox | grep Sl | awk '{print $1}'` -e trace=network
	Process 10013 attached - interrupt to quit
	socket(PF_FILE, SOCK_STREAM, 0)         = 89
	connect(89, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, 20) = 0
	getpeername(89, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, [20]) = 0
	getsockname(89, {sa_family=AF_FILE, NULL}, [2]) = 0
	socket(PF_FILE, SOCK_STREAM, 0)         = 89
	setsockopt(89, SOL_SOCKET, SO_PRIORITY, [6], 4) = 0
	connect(89, {sa_family=AF_FILE, path="/home/dev001/.pulse/15744ab110d5b90357a500f84ad4bb65-runtime/native"}, 110) = -1 ENOENT (No such file or directory)
	socket(PF_FILE, SOCK_STREAM, 0)         = 89
	setsockopt(89, SOL_SOCKET, SO_PRIORITY, [6], 4) = 0
	connect(89, {sa_family=AF_FILE, path="/home/dev001/.pulse/native"}, 110) = -1 ENOENT (No such file or directory)
	socket(PF_FILE, SOCK_STREAM, 0)         = 89
	setsockopt(89, SOL_SOCKET, SO_PRIORITY, [6], 4) = 0
	connect(89, {sa_family=AF_FILE, path="/var/run/pulse/native"}, 110) = -1 ENOENT (No such file or directory)
	socket(PF_NETLINK, SOCK_RAW, 0)         = 89
	bind(89, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
	getsockname(89, {sa_family=AF_NETLINK, pid=10013, groups=00000000}, [12]) = 0
	sendto(89, "\24\0\0\0\26\0\1\3\246\fkL\0\0\0\0\0\0\0\0", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20
	recvmsg(89, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"8\0\0\0\24\0\2\0\246\fkL\35'\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 352
	recvmsg(89, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"@\0\0\0\24\0\2\0\246\fkL\35'\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 64
	recvmsg(89, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0\246\fkL\35'\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20
	socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 89
	setsockopt(89, SOL_SOCKET, SO_PRIORITY, [6], 4) = 0
	setsockopt(89, SOL_TCP, TCP_NODELAY, [1], 4) = 0
	setsockopt(89, SOL_IP, IP_TOS, [16], 4) = 0
	connect(89, {sa_family=AF_INET, sin_port=htons(4713), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
	--- SIGCHLD (Child exited) @ 0 (0) ---
	sendto(88, "W", 1, MSG_NOSIGNAL, NULL, 0) = -1 ENOTSOCK (Socket operation on non-socket)
	Process 10013 detached


(3) zypper in pulseaudio
	Resolving package dependencies...
	
	The following NEW package is going to be installed:
	  pulseaudio
	
	The following package is recommended, but will not be installed:
	  alsa-plugins-pulse
	
	1 new package to install.
	Overall download size: 550.0 KiB. After the operation, additional 2.2 MiB will be used.
	Continue? [y/n/?] (y): y
	...

rpm -qa | egrep -i "canberra|pulseaudio"
	libcanberra-devel-0.24-1.8.x86_64
	libcanberra0-0.24-1.8.x86_64
	libcanberra-gtk-0.24-1.8.x86_64
	pulseaudio-0.9.21-9.2.x86_64
	libcanberra-gtk0-0.24-1.8.x86_64

launch Firefox
strace -p`ps ax | grep firefox | grep Sl | awk '{print $1}'` -e trace=network
	Process 10374 attached - interrupt to quit
	(empty)
	Process 10374 detached

Comment 22

7 years ago
is pulseaudio a presumed-to-be-required system dependency, or optional?

if optional, then the apparent unspecified dependency by firefox needs to be fixed, or removed

if required, then that dep should be specified either in upstream code, or @ distro pkging, which will require some communications
pulseaudio is not required by Firefox. It might be required on some distributions. It's not hard required in openSUSE for example.
libcanberra is loaded if available and used for some sort of notifications.

The thing is that I still cannot reproduce it. I have a system w/o pulseaudio running but with libcanberra available but still no delay in menu actions.

Comment 24

7 years ago
(In reply to comment #23)
> pulseaudio is not required by Firefox. It might be required on some
> distributions. It's not hard required in openSUSE for example.
> libcanberra is loaded if available and used for some sort of notifications.

_something_ is looking for files in ~/.pulse,

path="/home/dev001/.pulse/15744ab110d5b90357a500f84ad4bb65-runtime/native"},
110) = -1 ENOENT (No such file or directory)

if it's not firefox, which I'm stracing, then what possibly?

> The thing is that I still cannot reproduce it. I have a system w/o pulseaudio
> running but with libcanberra available but still no delay in menu actions.

odd. it's fully reproducible on all the machines around here. clearly, something common among my boxes.
(In reply to comment #24)
> _something_ is looking for files in ~/.pulse,
> 
> path="/home/dev001/.pulse/15744ab110d5b90357a500f84ad4bb65-runtime/native"},
> 110) = -1 ENOENT (No such file or directory)
> 
> if it's not firefox, which I'm stracing, then what possibly?

It's absolutely possible that it is libcanberra because it's linked against libpulse. In openSUSE and probably other distributions many sound apps are compiled against pulse but should fall back gracefully to asound (or whatever) if pulse is not available.
 
> > The thing is that I still cannot reproduce it. I have a system w/o pulseaudio
> > running but with libcanberra available but still no delay in menu actions.
> 
> odd. it's fully reproducible on all the machines around here. clearly,
> something common among my boxes.

Agreed.
As it seems to be an effect caused by audio systems (canberra, pulse) it would be better to investigate somewhere else (distribution bugtracking?).

Comment 26

7 years ago
> It's absolutely possible that it is libcanberra because it's linked against
> libpulse. In openSUSE and probably other distributions many sound apps are
> compiled against pulse but should fall back gracefully to asound (or whatever)
> if pulse is not available.

If it is, what am i missing then,

 ldd /usr/lib64/libcanberr* | grep -i pulse
  (empty)

?

> Agreed.
> As it seems to be an effect caused by audio systems (canberra, pulse) it would
> be better to investigate somewhere else (distribution bugtracking?).

The point is, both distro & native Mozilla bins exhibit this behavior --  apparently on several different distros.  Splitting the issue apart doesn't make a lot of sense to me.  But, I have a working solution, now -- so I'll leave that decision to others here.
(In reply to comment #26)
> > It's absolutely possible that it is libcanberra because it's linked against
> > libpulse. In openSUSE and probably other distributions many sound apps are
> > compiled against pulse but should fall back gracefully to asound (or whatever)
> > if pulse is not available.
> 
> If it is, what am i missing then,
> 
>  ldd /usr/lib64/libcanberr* | grep -i pulse
>   (empty)

/usr/lib64/libcanberra-0.24/libcanberra-pulse.so

> > Agreed.
> > As it seems to be an effect caused by audio systems (canberra, pulse) it would
> > be better to investigate somewhere else (distribution bugtracking?).
> 
> The point is, both distro & native Mozilla bins exhibit this behavior -- 
> apparently on several different distros.  Splitting the issue apart doesn't
> make a lot of sense to me.  But, I have a working solution, now -- so I'll
> leave that decision to others here.

The point is that Mozilla has not much to do with libcanberra and pulseaudio.
If libcanberra/pulse misbehaves it's hard to get it fixed in Mozilla's bugzilla.

Comment 28

7 years ago
opened a parallel bug:

https://bugs.freedesktop.org/show_bug.cgi?id=29650

Comment 29

7 years ago
a possibly (?) relevant comment @ #opensuse-gnome,

<wolfiR> dev001: the delay happens with every menu action?
<dev001> wolfiR: yes.  @ toolbar, at bookmarks, @context menu, @ submenu ...
<wolfiR> dev001: I see the difference with FF 3.5 <-> 3.6 that there is
EVENT_MENU_POPUP in 3.6 which wasn't in 3.5
<wolfiR> dev001: that might explain the difference between both version
[09:00] <wolfiR> dev001: still doesn't explain why it happens at all

cref: http://mxr.mozilla.org/mozilla1.9.2/source/widget/src/gtk2/nsSound.cpp#441

Comment 30

7 years ago
(In reply to comment #28)
> opened a parallel bug:
> https://bugs.freedesktop.org/show_bug.cgi?id=29650

told, now, it's an opensuse, not a libcanberra, bug.
hence, https://bugzilla.novell.com/show_bug.cgi?id=632530

Updated

7 years ago
Status: NEW → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → INVALID
(Reporter)

Comment 31

7 years ago
But I am running gentoo, not opensuse.
(Reporter)

Comment 32

7 years ago
And google also shows up arch linux users experiencing the problem. Definitely not OpenSUSE specific.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Please dont reopen this bug, it is not a Firefox issue.

Comment 34

7 years ago
it manifests clearly & reproducibly in Firefox.  period.

if that doesn't rise to the level of at least interest @firefox, that's a completely different discussion.
The underlying problem is in the Linux networking stack. Should all Linux networking bugs be filed in bugzilla.mozilla.org because they could affect Firefox?

Please file bugs similar to https://bugzilla.novell.com/show_bug.cgi?id=632530 in any affected distros.
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → WONTFIX

Comment 36

7 years ago
> The underlying problem is in the Linux networking stack. Should all Linux
> networking bugs be filed in bugzilla.mozilla.org because they could affect
> Firefox?

One would HOPE that someone here would be interested in bugs that appear in Firefox -- across multiple versions, distros, conditions, etc.  Even if they eventually turn out to be some other issue.

Given that out of 30+ contributions to this 'issue', showing clear manifestation in firefox, only 2 comments (well, 3, counting your contribution) were made from someone @mozilla, one of which was to incorrectly call it a dupe, I find the not-so-rhetorical insinuation that anyone -- other than you -- has suggested "all ..." bugs should be filed here a bit ... disingenuous.

In like vein, Should NO uncertain-in-origin bugs be filed in b.m.o because they might only 'affect' Firefox?  That's certainly the message conveyed.
(In reply to comment #36)
> One would HOPE that someone here would be interested in bugs that appear in
> Firefox -- across multiple versions, distros, conditions, etc.  Even if they
> eventually turn out to be some other issue.

That's right, and we are interested.

Filing this bug here when you thought it might be a Firefox bug was the right thing to do. Now that we have discovered it is not a Firefox bug, closing it is the right thing to do. The system worked.
And thanks for both opening the bug and helping figure out what the problem is.
Perhaps to belabor the point:

(In reply to comment #36)
> In like vein, Should NO uncertain-in-origin bugs be filed in b.m.o because they
> might only 'affect' Firefox?  That's certainly the message conveyed.

You're totally right, it's fine to file uncertain-in-origin bugs here. But Aaron was also right in comment #33.

Comment 40

7 years ago
..
You need to log in before you can comment on or make changes to this bug.