Comment on attachment 8367119
replace g_slice_set_config with G_SLICE env var
Review of attachment 8367119:
-
Considering g_slice_set_config is only deprecated at the moment, I'd rather use
it and fallback to environment variables i
(In reply to Karl Tomlinson (back Jan 28 :karlt) from comment #44)
> On irc, glandium indicated that he would prefer to dlopen libglib (before
> anything depends on libgobject) and use the deprecated g_slice_set_config
> internal debugging api, than follow Matthias' suggestion to use
> GSLICE=alway
(In reply to noitidart from comment #69)
> Quick update, another thing this broke is the Windows 7 + jump menu:
> http://i.imgur.com/OiyEzUI.png
This makes no sense, those are not using -remote:
https://dxr.mozilla.org/mozilla-
central/source/browser/modules/WindowsJumpLists.jsm#91
--
You recei
It's in 36.0.1, but it's guaranteed to still be there in 37.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to emacs24 in Ubuntu.
https://bugs.launchpad.net/bugs/1425972
Title:
Firefox no longer supports -remote parameter
Status in exo:
(In reply to Jean-Yves Perrier [:teoli] from comment #75)
> So, if I'm following correctly: -remote was removed in Fx 36, readded in the
> chemspill 36.0.1 and won't be removed in 37 at least?
>
> Is this correct (We also need to update Fx 36 for devs).
Err, I missed a not in my sentence. It is *
(In reply to noitidart from comment #80)
> (In reply to Pavlos Touboulidis from comment #79)
> > (In reply to noitidart from comment #78)
> > > I opened my 2nd profile with this:
> > > firefox.exe -P Dev -no-remote
> >
> > Try "firefox.exe -P Dev -new-instance"
>
> Thanks Pavlos I tried that.
>
(In reply to noitidart from comment #85)
> (In reply to Mike Hommey [:glandium] from comment #84)
> > (In reply to noitidart from comment #83)
> > > (In reply to Mike Hommey [:glandium] from comment #82)
> > > > Comment on attachment 8573128
> > > > Backout the part that removed -remote
> > > >
>
Comment on attachment 8573128
Backout the part that removed -remote
That being said, I can see a point in being more conservative for the
upcoming ESR.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to emacs24 in Ubuntu.
https://bugs.launc
(In reply to noitidart from comment #83)
> (In reply to Mike Hommey [:glandium] from comment #82)
> > Comment on attachment 8573128
> > Backout the part that removed -remote
> >
> > Approval Request Comment: See comment 64
> >
> > Considering how late we are in the beta cycle, it's more reasonabl
Comment on attachment 8573128
Backout the part that removed -remote
Approval Request Comment: See comment 64
Considering how late we are in the beta cycle, it's more reasonable to
get this on 37. 38 will get the alternative approach.
--
You received this bug notification because you are a membe
If every distro uses a different key, then Google can distinguish which
distro users are using. Wouldn't that qualify as a privacy breach? IIRC,
we explicitely don't send the google cookie for safebrowsing. If we
don't do that for geoloc, that would seem like a bug. OTOH, they can
probably correlat
(In reply to Chris Coulson from comment #17)
> The next Firefox update on Ubuntu will have this fixed
How are you fixing this?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1401402
Ti
(In reply to jhorak from comment #79)
> Thanks for feedback.
> The u"str" or NS_LL is char16_t*. I'm not sure if I can safely cast it to
> PRUnichar), can I?
Note you can't use u"" because that's only supported in c++11 mode, and
we still support not building in that mode.
--
You received this b
Comment on attachment 713377
Store Master Password by using libsecret to Gnome Keyring patch v1
Review of attachment 713377:
-
::: security/manager/ssl/src/nsNSSCallbacks.cpp
@@ +800,5 @@
> + rv = profileDir->GetNativeLeafName(profi
It depends if you are talking about runtime requirements or build-time
requirements.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1051559
Title:
Build Firefox with GStreamer support
(In reply to Matt Woodrow (:mattwoodrow) from comment #35)
> https://hg.mozilla.org/integration/mozilla-inbound/rev/3b5fb4abaa3f
Matt, can you get this landed on beta?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
ht
I concur with Karl. In fact, those crashes might be related to bug
920200.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1160569
Title:
[regression] GLib-CRITICAL **: g_slice_set_con
(In reply to comment #59)
> Who would I have to blackmail to get more recent Nouveau drivers into
> experimental?
You can try debia...@lists.debian.org directly, or file a wishlist bug
against xserver-xorg-video-nouveau.
--
You received this bug notification because you are a member of Desktop
P
Using cairo 1.10.0 and pixmap 0.21.2, everything is displayed gracefully
on 4.0b8 built against system cairo, on intel display. (iceweasel from
http://mozilla.debian.net/packages/, and cairo and pixmap from current
debian experimental, for those who care).
Nouveau drivers are likely to be the culp
(In reply to Alexander Korsunsky from comment #114)
> This HAS been implemented as an addon:
> https://github.com/infinity0/mozilla-gnome-keyring
>
> The problem is that it has to be a binary add-on (...)
This isn't true. jsctypes can be used to call whatever APIs the binary
addon uses.
--
You
(In reply to Alexander Korsunsky from comment #114)
> This HAS been implemented as an addon:
> https://github.com/infinity0/mozilla-gnome-keyring
>
> The problem is that it has to be a binary add-on (...)
This isn't true. jsctypes can be used to call whatever APIs the binary
addon uses.
--
You
(In reply to Karl Tomlinson (:karlt) from comment #27)
> It seems unfortunate that different libraries and apps have a need to
> implement their own allocators.
It seems unfortunate that disabling a library's internal allocator is an
"internal debugging API"
--
You received this bug notification
(In reply to Chris Coulson from comment #0)
> On Linux, the glib slice allocator is disabled in |XREMain::XRE_main| by
> calling |g_slice_set_config| (see bug 431221). However, this no longer works
> since glib 2.35 because libgobject (which libxul depends on) now has a
> static initializer which i
gah these things are confusing.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1160569
Title:
[regression] GLib-CRITICAL **: g_slice_set_config: assertion
`sys_page_size == 0' faile
Ubuntu also does Firefox builds on armhf.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1398898
Title:
[armhf] segfaults when trying to save a file
Status in The Mozilla Firefox Bro
And, in fact, Fedora does too.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1398898
Title:
[armhf] segfaults when trying to save a file
Status in The Mozilla Firefox Browser:
Fix
(In reply to Jacob Bramley [:jbramley] from comment #35)
> Doesn't this affect Android too? They use armhf these days, I believe.
Android builds use softfp afaik.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https:/
For checkSyntax, nothing needs to be done, really. Essentially, the
#ifdef is wrong, the code is not tied to the YARR JIT, it's tied to
YARR. So removing the #ifdef works.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubu
> Yes, except that YarrSyntaxChecker.cpp is in CPPSRCS only in
ENABLE_YARR_JIT case..
Both your patch and my older patch add YarrSyntaxChecker.cpp to CPPSRCS
in the non-ENABLE_YARR_JIT case
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to
These symbols are supposed to be in one OR the other, not in both.
The relevant snippet in js/src/Makefile.in is:
ifeq (,$(MOZ_GLUE_PROGRAM_LDFLAGS))
# When building standalone, we need to include mfbt sources, and to declare
# "exported" mfbt symbols on its behalf when we use its headers.
includ
Created attachment 603183
Use YARR interpreter instead of PCRE on platforms where YARR JIT is not
supported
I refreshed the patch against current mozilla-inbound. Landry, can you
check I didn't break anything?
--
You received this bug notification because you are a member of Desktop
Packages, w
(In reply to Marco Bonardo [:mak] from comment #67)
> backed out as suspected for a bunch of jit tests failures in linux debug
> builds
> see
> https://tbpl.mozilla.org/php/getParsedLog.php?id=9878244&tree=Mozilla-Inbound
> https://tbpl.mozilla.org/php/getParsedLog.php?id=9878570&tree=Mozilla-Inbou
Well, if it's breaking linux debug builds, it means it's *not* only
shuffling ifdefs around. So you should start by checking that.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
https://bugs.launchpad.net/bugs/9085
Created attachment 576542
Allow .js preference files to set locked prefs with lockPref()
Sorry for the noise, just testing "hg bzexport". I'm still interested to
know who could review this, though.
--
You received this bug notification because you are a member of Desktop
Packages, which is subsc
Created attachment 576542
Allow .js preference files to set locked prefs with lockPref()
Sorry for the noise, just testing "hg bzexport". I'm still interested to
know who could review this, though.
--
You received this bug notification because you are a member of Desktop
Packages, which is subsc
Created attachment 588391
Use YARR interpreter instead of PCRE on platforms where YARR JIT is not
supported
This is the bug I have for beta in Debian. Unfortunately, it doesn't apply to
aurora and m-c.
For me, this seriously raises the question as to whether we (mozilla) should be
adding js-onl
(In reply to Mike Hommey [:glandium] from comment #12)
> Created attachment 588391
> Use YARR interpreter instead of PCRE on platforms where YARR JIT is not
> supported
>
> This is the bug
Err. the patch, not the bug.
--
You received this bug notification because you are a member of Desktop
Pac
(In reply to Landry Breuil from comment #14)
> Just to clarify.. is your patch in debian a build fix for fx 10.0beta on ppc
> & sparc, or only sparc ?
"on platforms where YARR JIT is not supported"
--
You received this bug notification because you are a member of Desktop
Packages, which is subsc
That's why ENABLE_ASSEMBLER needs to be off.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
https://bugs.launchpad.net/bugs/908508
Title:
Firefox/Thunderbird 10 FTBFS on powerpc in js/src/yarr/pcre
Status in Th
Hint: a lot of the !ENABLE_YARR_JIT uses really mean USE_PCRE.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
https://bugs.launchpad.net/bugs/908508
Title:
Firefox/Thunderbird 10 FTBFS on powerpc in js/src/yarr/
Yes, but for sparc, it's more subtle: ENABLE_ASSEMBLER needs to be set
for the normal non YARR JIT. Man, what a mess.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
https://bugs.launchpad.net/bugs/908508
Title:
Created attachment 572068
Allow .js preference files to set locked prefs with lockPref()
Refreshed after the PRBool/bool change.
Now, as bsmedberg won't review it, and dwitte is essentially not around
anymore, who can review this?
--
You received this bug notification because you are a member o
Created attachment 572068
Allow .js preference files to set locked prefs with lockPref()
Refreshed after the PRBool/bool change.
Now, as bsmedberg won't review it, and dwitte is essentially not around
anymore, who can review this?
--
You received this bug notification because you are a member o
(In reply to Chris Coulson from comment #14)
> Created attachment 602368
> Treat distribution/searchplugins as a known location and don't use the full
> path for the search engine ID's
>
> We've been carrying a distro patch for a long time to do the normalize() in
> _loadEnginesFromDir(), and I'd
(In reply to Mike Hommey [:glandium] from comment #17)
> Risk to taking this patch (and alternatives if risky):
(forgot to fill here) very low risk, and has been tested widely for a
while now (since it was released in 11). It would be nice if it was
applied on ESR, though.
--
You received this
Comment on attachment 581198
Try creating a named cursor before a bitmap cursor (v2)
[Approval Request Comment]
User impact if declined: Regression in aspect of various mouse cursors not
following the system theme on Linux systems in Firefox with
ui.use_activity_cursor set to true, and in Thunde
A safe way to implement cacheFlush that would be to have a dummy implementation
that does nothing (cacheFlush is completely unimportant when there is no JIT),
with the following preprocessor goop (or something similar):
#ifndef ENABLE_ASSEMBLER
#error cacheFlush unimplemented for this platform
#e
The best place is probably js-config.h.in, so that external apps
building against the headers don't end up with the same problem.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
https://bugs.launchpad.net/bugs/90850
(In reply to Landry Breuil from comment #85)
> (In reply to David Mandelin from comment #82)
> > Landry, following up on a hint from billm, I got your patch to work on Linux
> > with this addition:
> >
> > diff -r e7bbcbb6c24a js/src/jscntxt.h
> > --- a/js/src/jscntxt.h Tue Mar 13 17:42:33 20
(In reply to Landry Breuil from comment #88)
> Righto.. but ENABLE_YARR_JIT is not known when you're creating js-config.h,
> since it's in Makefile.in. and ENABLE_YARR_JIT is needed to know if we need
> to define ENABLE_ASSEMBLER. So ENABLE_YARR_JIT definition would have to go
> to configure too ?
(In reply to David Mandelin from comment #91)
> JSC sets those flags in what we imported as assembler/wtf/Platform.h, which
> seems reasonable. In fact, I see they set ENABLE_ASSEMBLER in there
> depending on various conditions, which is maybe why the patch works on most
> platforms already.
Platf
(In reply to Landry Breuil from comment #115)
> So let's try to get this reviewed and hope this time it sticks. Only change
> from att 619876 is indentation fixed in Makefile.in (use tabs) and
> (defined(WTF_CPU_PPC) && !defined(JS_CPU_PPC_OSX)) for using the dummy
> cacheFlush.
You should use som
(In reply to Landry Breuil from comment #117)
> So that'd mean replacing :
>
> #error "The cacheFlush support is missing on this platform."
>
> by
>
> static void cacheFlush(void*, size_t)
> {
> #warning "Using dummy generic & empty cacheFlush for this platform."
> }
>
> Do you think that'll wo
What might work, is to remove the error and put nothing to replace it.
Adding a JIT for a new platform will make the function required, and
compilation will fail because it is completely missing.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscrib
https://hg.mozilla.org/integration/mozilla-inbound/rev/f5a3a7b9c6b0
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
https://bugs.launchpad.net/bugs/908508
Title:
Firefox/Thunderbird 10 FTBFS on powerpc in js/src/
(In reply to Mike Kaply [:mkaply] from comment #28)
> I really don't want it being called lockPref. That will confuse it with the
> autoconfig "lockPref" function.
What is confusing? It's the same syntax. The only difference aiui, is
the execution environment, which means autoconf can do more java
Created attachment 8931547
Bug 440908 - Allow preference files to set locked prefs.
Review commit: https://reviewboard.mozilla.org/r/202672/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/202672/
--
You received this bug notification because you are a member of Desktop
Pa
(In reply to Mike Kaply [:mkaply] from comment #39)
> Oddly, this document:
>
> https://developer.mozilla.org/en-US/docs/Mozilla/Preferences/
> A_brief_guide_to_Mozilla_preferences
>
> Says we already support lockPref in JS files?
It says: "All preferences files may call pref(), user_pref() and
Created attachment 8613433
Allow .js preference files to set locked prefs with lockPref()
Refreshed after bug 1098343. Benjamin, would you like to review this,
this time, considering comment 26?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscrib
The preferences code is being heavily refactored, and this needs to wait
a bit for things to settle first. That being said, I do think the ideal
timing for this would be to get it into 60. Nick, what do you think?
--
You received this bug notification because you are a member of Desktop
Packages,
The syntax is a triviality of the patch. The core problem here is that
there's no one to review the patch so that it possibly lands.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
https://bugs.launchpad.net/bugs/62
>From a quick glance at the history of the patch in Debian, in the past 5
years, I had to do actual but trivial code changes twice, and adapt to
context changes twice (one of them having been the change from PRBool to
bool)
--
You received this bug notification because you are a member of Desktop
Comment on attachment 8613433
Allow .js preference files to set locked prefs with lockPref()
>From b8015e0754742650a4877de9ebe7d6db2671970d Mon Sep 17 00:00:00 2001
>From: Mike Hommey
>Date: Sat, 21 Jun 2008 02:48:46 +0200
>Subject: [PATCH] Allow .js preference files to set locked prefs with
> lo
(In reply to Benjamin Smedberg [:bsmedberg] from comment #36)
> Comment on attachment 8613433
> Allow .js preference files to set locked prefs with lockPref()
>
> Because this came up on the mailing list, I'll try to be explicit about the
> decision here. I don't think we should allow extensions
Comment on attachment 8956310
Bug 440908 - Add support for `sticky` and `locked` attributes to default prefs.
https://reviewboard.mozilla.org/r/225184/#review231212
::: modules/libpref/Preferences.cpp:3982
(Diff revision 1)
> -Preferences::GetCString(kChannelPref, updateChannelPrefValue,
> -
Comment on attachment 8956309
Bug 440908 - Remove gIsAnyPrefLocked.
https://reviewboard.mozilla.org/r/225182/#review231210
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
https://bugs.launchpad.net/bugs/623844
Tit
The ability to lock prefs at the .js level is not *only* for enterprise
customization. Specifically, we have many "prefs" that are meant to
allow e.g. per channel (release, beta, nightly) tweaks but are not meant
for users to change. There are multiple such footguns that would be
avoided by having
Comment on attachment 8956311
Bug 440908 - Convert sticky prefs in default pref files to the new syntax.
https://reviewboard.mozilla.org/r/225186/#review231216
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
https:
Created attachment 8613433
Allow .js preference files to set locked prefs with lockPref()
Refreshed after bug 1098343. Benjamin, would you like to review this,
this time, considering comment 26?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscrib
Created attachment 8931547
Bug 440908 - Allow preference files to set locked prefs.
Review commit: https://reviewboard.mozilla.org/r/202672/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/202672/
--
You received this bug notification because you are a member of Desktop
Pa
The preferences code is being heavily refactored, and this needs to wait
a bit for things to settle first. That being said, I do think the ideal
timing for this would be to get it into 60. Nick, what do you think?
--
You received this bug notification because you are a member of Desktop
Packages,
Comment on attachment 8956310
Bug 440908 - Add support for `sticky` and `locked` attributes to default prefs.
https://reviewboard.mozilla.org/r/225184/#review231212
::: modules/libpref/Preferences.cpp:3982
(Diff revision 1)
> -Preferences::GetCString(kChannelPref, updateChannelPrefValue,
> -
(In reply to Mike Kaply [:mkaply] from comment #28)
> I really don't want it being called lockPref. That will confuse it with the
> autoconfig "lockPref" function.
What is confusing? It's the same syntax. The only difference aiui, is
the execution environment, which means autoconf can do more java
The ability to lock prefs at the .js level is not *only* for enterprise
customization. Specifically, we have many "prefs" that are meant to
allow e.g. per channel (release, beta, nightly) tweaks but are not meant
for users to change. There are multiple such footguns that would be
avoided by having
The syntax is a triviality of the patch. The core problem here is that
there's no one to review the patch so that it possibly lands.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/541951
(In reply to Mike Kaply [:mkaply] from comment #39)
> Oddly, this document:
>
> https://developer.mozilla.org/en-US/docs/Mozilla/Preferences/
> A_brief_guide_to_Mozilla_preferences
>
> Says we already support lockPref in JS files?
It says: "All preferences files may call pref(), user_pref() and
Comment on attachment 8956309
Bug 440908 - Remove gIsAnyPrefLocked.
https://reviewboard.mozilla.org/r/225182/#review231210
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/541951
Title:
Comment on attachment 8613433
Allow .js preference files to set locked prefs with lockPref()
>From b8015e0754742650a4877de9ebe7d6db2671970d Mon Sep 17 00:00:00 2001
>From: Mike Hommey
>Date: Sat, 21 Jun 2008 02:48:46 +0200
>Subject: [PATCH] Allow .js preference files to set locked prefs with
> lo
Comment on attachment 8956311
Bug 440908 - Convert sticky prefs in default pref files to the new syntax.
https://reviewboard.mozilla.org/r/225186/#review231216
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bu
(In reply to Benjamin Smedberg [:bsmedberg] from comment #36)
> Comment on attachment 8613433
> Allow .js preference files to set locked prefs with lockPref()
>
> Because this came up on the mailing list, I'll try to be explicit about the
> decision here. I don't think we should allow extensions
>From a quick glance at the history of the patch in Debian, in the past 5
years, I had to do actual but trivial code changes twice, and adapt to
context changes twice (one of them having been the change from PRBool to
bool)
--
You received this bug notification because you are a member of Desktop
I'm confused at to why a MOZ_BUILDID "override" is necessary for you,
and why the build date is a problem in the first place.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1830096
Titl
It's very possible this is the same as bug 1601707. If it is, we don't
need to exclude clang 6.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1850529
Title:
Crash after update to 71.
(In reply to Nathan Froyd [:froydnj] from comment #19)
> (In reply to Mike Hommey [:glandium] (high latency) from comment #18)
> > It's very possible this is the same as bug 1601707. If it is, we don't need
> > to exclude clang 6.
>
> OTOH, I don't want to be rediscovering that people are using a
FWIW, Gtk+3 >= 3.10 has gdk_x11_window_get_desktop() and
gdk_x11_window_move_to_desktop() functions... which, if you ask me, is
shortsighted, since it's limited to X11, and won't work in Wayland.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscrib
It was removed in 39.0. I updated https://developer.mozilla.org/en-
US/docs/Mozilla/Command_Line_Options#-remote_remote_command to some
extent.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to emacs24 in Ubuntu.
https://bugs.launchpad.net/
Created attachment 8628085
Replace g_slice_set_config() with G_SLICE environment variable
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1160569
Title:
GLib-CRITICAL **: g_slice_set_c
(In reply to Karl Tomlinson (ni?:karlt back June 30) from comment #112)
> I had intentionally chosen not to override an existing G_SLICE environment
> variable so that this could be overridden or debug-blocks could be used if
> desired. That's not a show-stopper, but avoiding overriding would avoi
Created attachment 8626818
0001-Bug-833117-Replace-g_slice_set_config-with-G_SLICE-e.patch
Using g_slice_set_config() fails with newer glib because the slice allocator
now has a static constructor that runs when glib is loaded, consequently
emitting a noisy error message which confuses people into
Backed out for gtest bustage:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c0f955560a47
23:59:34 INFO - GThread-ERROR **: GThread system may only be initialized
once.
23:59:34 INFO - aborting...
23:59:34 INFO - Redirecting call to abort() to mozalloc_abort
23:59:35 WARNING
... and it so happens that we're calling g_thread_init(NULL) from
different places, and likely crash for that reason with older glib...
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/116
(In reply to Mike Hommey [:glandium] from comment #117)
> Backed out for gtest bustage:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/c0f955560a47
>
> 23:59:34 INFO - GThread-ERROR **: GThread system may only be initialized
> once.
And this error was removed in glib 2.23.x 5 years
Created attachment 8630422
Replace g_slice_set_config() with G_SLICE environment variable
Turns out there aren't many places where g_thread_init is actually
called. There's some webrtc code that we don't build, and other than
that, other uses are exclusive... but need to be factored in, so this
be
(In reply to Karl Tomlinson (ni?:karlt) from comment #122)
> Comment on attachment 8630422
> Replace g_slice_set_config() with G_SLICE environment variable
>
> The g_type_init() call has been dropped.
> I don't know of a static constructor using GSlice in GLib 2.32.
Yeah, I was mistaken, I though
Created attachment 8631479
Replace g_slice_set_config() with G_SLICE environment variable
Not enough changes to require another review from Nathan. This should
address your concerns.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefo
(In reply to Karl Tomlinson (:karlt) from comment #73)
> Helper apps should be fine in --enable-gio builds because
> g_desktop_app_info_launch_uris also calls g_spawn_async without
> G_SPAWN_LEAVE_DESCRIPTORS_OPEN.
Actually, Non-GNOME systems won't be covered with --enable-gio, because
the gio ser
Also note that mozgnome also may depend on libnotify. (mozilla builds
don't but distros' do)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/159258
Title:
Helper applications launched
Something else: mailcap support uses nsIProcess to start commands. These
wouldn't be covered either.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/159258
Title:
Helper applications l
98 matches
Mail list logo
