#1364589 [Core:DOM]-AppendDocumentLevelNativeAnonymousContentTo should include the custom content container [Uns][]
#1364814 [Core:Editor]-Use RAII class to set and restore editor flags [Uns][]
#1364161 [Core:Gecko Profiler]-GCMajor markers seem off [All][]
#1343482 [Core:Graphics]-gfx-labeling Label runnables in gfxCrashReporter. [Uns][[gfx-noted][QDL][BACKLOG][GFX]]
#1355441 [Core:HTML: Parser]-Don't allocate HTML5StackNodes all the time from heap [Uns][]
#924058 [Core:JavaScript Engine]-Array operations should use ToLength on user-supplied indices, not ToUint32 [Lin][]
#1362753 [Core:JavaScript Engine]-Array.prototype.slice and Array.prototype.splice should always take the fast path for non-Array native objects [Uns][]
#1364442 [Core:JavaScript Engine]-Profiler JSON is broken depending on the OS locale because float values (used for minor GC timing) can use the wrong decimal separator [All][]
#1361686 [Firefox:Theme]-Share bookmark toolbar button styling between platforms [Uns][[photon-visual][p4]]
#1363753 [Firefox:Toolbars and Customization]-Ensure that the width of panel views do not exceed that of the main view [Uns][[photon-structure]]
#1364878 [Toolkit:Add-ons Manager]-All extensions are force enabled and marked as disabled in about:addons & about:support in Mozilla Firefox Nightly 55.0a1 (2017-05-15) [Win][]
#1362384 [Toolkit:Downloads API]-Remove code to import data from "downloads.sqlite" [Uns][]
#1359978 [Toolkit:Form Manager]-[Form Autofill] Implement the credit-card storage [All][[form autofill:M3]]
#1322523 [Toolkit:Safe Browsing]-Add telemetry probe to see the distribution of prefix lengths in matches [Uns][#sbv4-m7]
#1333328 [Toolkit:Safe Browsing]-Refactor cache miss handling mechanism for V2 [Uns][#sbv4-m7]
#1362047 [Toolkit:WebExtensions: General]-Borderify webextension is broken [All][[content scripts], investigating]
Partial Landings/Diagnostic Patches:
#1363027 [Core:Disability Access APIs]-Crash in mozilla::a11y::Accessible::RemoveChild [Win][[clouseau]]
#1364911 [Firefox:Toolbars and Customization]-Wait for the history subview to be populated before opening it [Uns][]
#1361787 [Core:Printing: Output]-Printing hang with box-shadow on windows 10 [Win][]
#1359411 [Core:Selection]-something in JS application or TinyMCE hangs Firefox completely [All][regression]
#1363563 [Core:WebRTC: Networking]-Firefox crashes when using WebRTC and renegotiating with a new offer that has less RTP header extensions than the previous one. [Uns][regression]
#1362493 [Firefox:General]-e10s beta cohort distribution improvements [Uns][]
#1363262 [Toolkit:Startup and Profile System]-Crash in mozilla::detail::nsStringRepr::First (called from nsCommandLine::HandleFlagWithParam) [All][]
Nightly 55 fixes since 20170306 (Gecko 54) ~3520
Beta 54 fixes since 20170123 (Gecko 53) ~2563
For example, normally stylish is kept disabled because it tends to use a lot of memory and only enabled if I want to do work in real time, otherwise userContent.css is good enough. In these latest nightlies you can still access some stylish settings and memory usage is back up despite being disabled. Just to confirm, I also temporarily disabled CTR and all of its settings are still there being used. Is this intentional and do we now have to uninstall addons to completely disable them?
Looks like they'll just stick with jemalloc 3 then? That's an interesting decision. Though given all the problems with trying to upgrade it I can understand why.
marty60 wrote:Does bug 1364878 address the fact that when addons are disabled by choice they are not completely disabled anymore and are still using memory?
For example, normally stylish is kept disabled because it tends to use a lot of memory and only enabled if I want to do work in real time, otherwise userContent.css is good enough. In these latest nightlies you can still access some stylish settings and memory usage is back up despite being disabled. Just to confirm, I also temporarily disabled CTR and all of its settings are still there being used. Is this intentional and do we now have to uninstall addons to completely disable them?
I think users just need to wait for the bug fix to make it into the next Nightly and updates being enabled again.
Linux Desktop - AMD Athlon(tm) II X3 455 3.3GHz | 8.0GB RAM | GeForce GT 630 Windows Notebook - AMD A8 7410 2.2GHz | 6.0GB RAM | AMD Radeon R5
WaltS48 wrote:I think users just need to wait for the bug fix to make it into the next Nightly and updates being enabled again.
It looks like bug 1364878 will take care of it since it's probably all related otherwise I'd file a separate bug. I'd hate to think that's intentional but with Mozilla these days you never know.
Ahh... I was wondering why I had to manually update yesterday and auto-update isn't working today. Thanks!
Give a man a fish, and he eats for a day. Teach a man to fish, and he eats for a lifetime. I like poetry, long walks on the beach and poking dead things with a stick. Please do not PM me for personal support. Keep posts here in the Forums instead and we all learn.
Omega X wrote:Apparently, Mozilla gave up on Jemalloc4.
As someone who has been involved in both trying to patch mozjemalloc and patching the glue code tying it all together: thank god. This stalemate was torture. I hope we can move forward now and make mozjemalloc less of a mess.
sciguyryan wrote:Looks like they'll just stick with jemalloc 3 then?
mozjemalloc is a heavily patched version of jemalloc 0.9 or something like that. The main thing setting it apart is that it can decommit unused pages inside runs - this was never upstreamed to jemalloc proper, and it's one of the reasons we were never able to switch.
Omega X wrote:Apparently, Mozilla gave up on Jemalloc4.
As someone who has been involved in both trying to patch mozjemalloc and patching the glue code tying it all together: thank god. This stalemate was torture. I hope we can move forward now and make mozjemalloc less of a mess.
sciguyryan wrote:Looks like they'll just stick with jemalloc 3 then?
mozjemalloc is a heavily patched version of jemalloc 0.9 or something like that. The main thing setting it apart is that it can decommit unused pages inside runs - this was never upstreamed to jemalloc proper, and it's one of the reasons we were never able to switch.
It's good to hear the reasons behind this sort of thing, we tend to only catch part of the story.
I assume that if there were any features that Mozilla wanted from newer jemalloc versions that they could cherry pick them anyway, right?
mozillaZine is an independent Mozilla community and advocacy site. We're not affiliated or endorsed by the Mozilla Corporation but we love them just the same.