ac9d12e5587fe2486a2a8c95ef911768841195e2: Bug 1408790 - The non-selected elements with ids should be lightened to the same color as the non-selected classes r=gl
Liam <canada8715@gmail.com> - Sun, 15 Oct 2017 17:45:12 -0600 - rev 390705
Push 32839 by nbeleuzu@mozilla.com at Wed, 08 Nov 2017 10:51:56 +0000
Bug 1408790 - The non-selected elements with ids should be lightened to the same color as the non-selected classes r=gl MozReview-Commit-ID: AjcnYsxxqAs
35a375648ee0224743657c67edfebf0cbe81b719: Bug 1415115 - forcing test window focus on dialog close. r=surkov
Yura Zenevich <yura.zenevich@gmail.com> - Tue, 07 Nov 2017 11:30:06 -0500 - rev 390704
Push 32839 by nbeleuzu@mozilla.com at Wed, 08 Nov 2017 10:51:56 +0000
Bug 1415115 - forcing test window focus on dialog close. r=surkov MozReview-Commit-ID: B71ChCA8Uzm
dd6063357ae629ffb82e2087ac58431c07548a82: Bug 1414150 - Remove the "idle_queue.*" prefs. r=farre.
Nicholas Nethercote <nnethercote@mozilla.com> - Wed, 08 Nov 2017 07:54:16 +1100 - rev 390703
Push 32839 by nbeleuzu@mozilla.com at Wed, 08 Nov 2017 10:51:56 +0000
Bug 1414150 - Remove the "idle_queue.*" prefs. r=farre. There's no good reason why these can't be code constants. Especially given that, due to a bug, changes to the "idle_queue.{min,long}_period" constants were not being passed onto the C++ code! Here's why: those two prefs were specified as integers in all.js. But we used AddFloatVarCache() to set up the reading of those prefs. libpref fakes floats by storing them as strings and then converting them to floats when they are read. Which means that AddFloatVarCache() used to fail to get the value from all.js -- because there's a type mismatch, int vs. string -- and instead use the fallback default. That value is the same as the one in all.js, which is lucky. But if someone changed the value in about:config to 100 (an integer), a similar failure would have occured and the value used by the C++ code wouldn't be updated! Also note that idle_queue.max_timer_thread_bound did not have a value in all.js. What a mess!
242b1157a36a8fbe769179a630c8457562d9568f: Bug 1414150 - Remove the "consoleservice.{logging,enabled}" prefs. r=jchen.
Nicholas Nethercote <nnethercote@mozilla.com> - Wed, 08 Nov 2017 07:54:13 +1100 - rev 390702
Push 32839 by nbeleuzu@mozilla.com at Wed, 08 Nov 2017 10:51:56 +0000
Bug 1414150 - Remove the "consoleservice.{logging,enabled}" prefs. r=jchen. It seems fine to specify these as code constants.
99a32740c0588f68bc391a3ae24fe478782134ac: Bug 1414150 - Remove the "memory.low_*" prefs. r=erahm,dmajor.
Nicholas Nethercote <nnethercote@mozilla.com> - Wed, 08 Nov 2017 07:49:46 +1100 - rev 390701
Push 32839 by nbeleuzu@mozilla.com at Wed, 08 Nov 2017 10:51:56 +0000
Bug 1414150 - Remove the "memory.low_*" prefs. r=erahm,dmajor. There's no good reason why these should't just be constants. The patch also appends "MiB" to some of the C++ values to make their meaning clearer. This patch fixes one outright bug, and one inconsistency. The bug is due to a prefname mismatch: - ContentPrefs.cpp and AvailableMemoryTracker.cpp use "memory.low_virtual_mem_threshold_mb". - all.js uses "memory.low_virtual_memory_threshold_mb". Which means that "memory.low_virtual_memory_threshold_mb" showed up in about:config, but if you changed it nothing would happen because the callback listened for changes to to "memory.low_virtual_mem_threshold_mb"! Now for the inconsistency. The above means we actually use a value of 256 for the virtual memory threshold, even though all.js says 128. But we *do* use a value of 128 for the commit space threshold, because that's what all.js says and that prefname is used correctly everywhere. The patch changes the commit space threshold to 256 for consistency with the virtual memory threshold. What a mess!
b84d87e9fa100abe4f3aa073d2e169d3392d9b4c: Bug 1414150 - Remove the "memory.free_dirty_pages" pref. r=glandium.
Nicholas Nethercote <nnethercote@mozilla.com> - Tue, 07 Nov 2017 19:34:18 +1100 - rev 390700
Push 32839 by nbeleuzu@mozilla.com at Wed, 08 Nov 2017 10:51:56 +0000
Bug 1414150 - Remove the "memory.free_dirty_pages" pref. r=glandium. This was originally added for b2g, where the pref had a different value. Bug 1398033 enabled it everywhere.
13ec107f211922aec40d4993eef12690c54a0c36: Bug 1415103 - Remove dead code in crash reporting. r=gsvelto
Cervantes Yu <cyu@mozilla.com> - Wed, 08 Nov 2017 11:49:37 +0800 - rev 390699
Push 32839 by nbeleuzu@mozilla.com at Wed, 08 Nov 2017 10:51:56 +0000
Bug 1415103 - Remove dead code in crash reporting. r=gsvelto This removes dead code using headlessClient and lastRunCrashID in crash reporting. headlessClient is unconditional now. nsIXULRuntime.lastRunCrashID is not used anymore so remove code for implementing it. MozReview-Commit-ID: AU4bUeIx3O0
c0e806b7a992dc9e8f608df3e6380bce574eb791: Bug 1409904 - Convert error! logging to warn! to avoid spurious stderr spamming from audioipc. r=kamidphish
Matthew Gregan <kinetik@flim.org> - Wed, 08 Nov 2017 16:20:48 +1300 - rev 390698
Push 32839 by nbeleuzu@mozilla.com at Wed, 08 Nov 2017 10:51:56 +0000
Bug 1409904 - Convert error! logging to warn! to avoid spurious stderr spamming from audioipc. r=kamidphish
574db20bdf3e8b013b3575fc154621213a6aa8a6: Bug 1414397 - Make sure we properly invalidate the entire frame subtree when detecting a caret frame change. r=miko
Matt Woodrow <mwoodrow@mozilla.com> - Wed, 08 Nov 2017 15:33:34 +1300 - rev 390697
Push 32839 by nbeleuzu@mozilla.com at Wed, 08 Nov 2017 10:51:56 +0000
Bug 1414397 - Make sure we properly invalidate the entire frame subtree when detecting a caret frame change. r=miko
7c87b438511359c8792273d261d3bed546c9b530: Bug 1412110 - Make sure we build a wrap list for the caret frame, since it will have multiple display items. r=miko
Matt Woodrow <mwoodrow@mozilla.com> - Wed, 08 Nov 2017 15:32:27 +1300 - rev 390696
Push 32839 by nbeleuzu@mozilla.com at Wed, 08 Nov 2017 10:51:56 +0000
Bug 1412110 - Make sure we build a wrap list for the caret frame, since it will have multiple display items. r=miko
8bd69298b447dc9c5cb11a77f0d14afdb8f9a990: Bug 1413833 - Don't use WeakFrame for the modified frame list since get slow with large numbers of frames. r=miko
Matt Woodrow <mwoodrow@mozilla.com> - Wed, 08 Nov 2017 15:25:44 +1300 - rev 390695
Push 32839 by nbeleuzu@mozilla.com at Wed, 08 Nov 2017 10:51:56 +0000
Bug 1413833 - Don't use WeakFrame for the modified frame list since get slow with large numbers of frames. r=miko
e05d3e232865dbb2533966879f50db54daa7340e: Bug 1413833 - Cap the number of modified frames that we track to avoid the overhead getting too large. r=miko
Matt Woodrow <mwoodrow@mozilla.com> - Wed, 08 Nov 2017 15:23:34 +1300 - rev 390694
Push 32839 by nbeleuzu@mozilla.com at Wed, 08 Nov 2017 10:51:56 +0000
Bug 1413833 - Cap the number of modified frames that we track to avoid the overhead getting too large. r=miko
891b6831d29bdfc80fc14434185bfd7c975e45dd: Bug 1414188 - Remove ValueObserver. r=glandium.
Nicholas Nethercote <nnethercote@mozilla.com> - Thu, 02 Nov 2017 20:38:34 +1100 - rev 390693
Push 32839 by nbeleuzu@mozilla.com at Wed, 08 Nov 2017 10:51:56 +0000
Bug 1414188 - Remove ValueObserver. r=glandium. libpref has callbacks. You can register a callback function against a particular pref (or pref prefix), and it'll be called when any matching pref changes. This is implemented in two layers. The lower layer is the list of CallbackNode objects, pointed to by gFirstCallback. The upper layer involves gObserverTable, which is a hash table of ValueObserver objects. It is used for callbacks registered via Preferences::RegisterCallback() and Preferences::Add*VarCache(), but not for observers registered with Preferences::Add{Weak,Strong}Observer(). If multiple callbacks with identical prefnames, callback functions and MatchKinds occur, they are commoned up into a single ValueObserver, which is then wrapped by a single CallbackNode. (The callbacks within a single ValueObserver can have different void* aClosure args; ValueObserver keeps those in an nsTArray.) Note also that gObserverTable is very inelegant, with duplication of data between the keys and the values due it being a nsRefPtrHashtable<ValueObserverHashKey, ValueObserver> and ValueObserver being a subclass of ValueObserverHashKey(!) This extra layer might make sense if there were a lot of commoning up happening, but there's not. Across all process kinds there is an average of between 1.2 and 1.7 closures per ValueObserver. The vast majority have 1 closure, and there are a handful that have multiple; the highest number I've seen is 71. (Note that this two-layer design probably seemed more natural back when libpref was spread across multiple files.) This patch removes the ValueObserver layer. The only tricky part is that there is a notion of a MatchKind -- ExactMatch or PrefixMatch -- which exists in the ValueObserverLayer but not in the CallbackNode layer. So the patch moves the MatchKind into the CallbackNode layer, which is straightforward. On Linux64 this reduces memory usage by about 40 KiB in the parent process and about 30 KiB in each content processes. The performance implications are minor. - The list of CallbackNodes is a bit longer, so when a pref is changed we must check more nodes. But we avoid possibly doing prefname matching twice. - Callback registration is much faster, just a simple list prepend, without any hash table insertion required. - Callback unregistration is probably not much different. There is a longer list to traverse, but no hash table removal. - Pref lookup is by far the hottest libpref operation, and it's unchanged. For perf to be genuinely affected would require (a) a *lot* more almost-duplicate callbacks that would have been commoned up, and (b) frequent changing of the pref those callbacks are observing. This seems highly unlikely. MozReview-Commit-ID: 6xo4xmytOf3
90a7bc300af375c80574266857e3ce46c30c6697: Bug 1415086 - Fixing a out-of-scope issue for a string in Worklet code, r=qdot
Andrea Marchesini <amarchesini@mozilla.com> - Wed, 08 Nov 2017 00:58:11 +0100 - rev 390692
Push 32839 by nbeleuzu@mozilla.com at Wed, 08 Nov 2017 10:51:56 +0000
Bug 1415086 - Fixing a out-of-scope issue for a string in Worklet code, r=qdot
23f86a1ac424051004163f370b80d7b7bc5a35dd: Backout a3785ec9a48c / bug 1410276 on request from pbone - Add a canary field to nsStringBuffer. r=backout
Sebastian Hengst <archaeopteryx@coole-files.de> - Wed, 08 Nov 2017 01:45:38 +0200 - rev 390691
Push 32839 by nbeleuzu@mozilla.com at Wed, 08 Nov 2017 10:51:56 +0000
Backout a3785ec9a48c / bug 1410276 on request from pbone - Add a canary field to nsStringBuffer. r=backout
e843de356b7e5f3cb01f114bc101f4a71092550b: Bug 1414096 - Remove support for nsISupportsString values in nsPrefBranch::{get,set}ComplexValue(). r=florian.
Nicholas Nethercote <nnethercote@mozilla.com> - Tue, 31 Oct 2017 16:34:35 +1100 - rev 390690
Push 32839 by nbeleuzu@mozilla.com at Wed, 08 Nov 2017 10:51:56 +0000
Bug 1414096 - Remove support for nsISupportsString values in nsPrefBranch::{get,set}ComplexValue(). r=florian. Bug 1345294 introduced nsPrefBranch::{get,set}StringPref(), which allowed the getting of utf8 strings from prefs, which previously required using nsISupportsString with {get,set}ComplexValue. That bug also converted most uses. This patch finishes the job. - It removes the nsISupportsString support. - It converts existing code that relied on the nsISupportsString. - It removes the lint that was set up to detect such uses of nsISupportsString.
e195ac70ab165bd6806d0bffc3db25fcdd708c51: Bug 1411631 - Use ContiguousEnumSerializerInclusive for GetOpenFileName IPC. r=jimm
David Parks <dparks@mozilla.com> - Wed, 01 Nov 2017 01:59:31 -0700 - rev 390689
Push 32839 by nbeleuzu@mozilla.com at Wed, 08 Nov 2017 10:51:56 +0000
Bug 1411631 - Use ContiguousEnumSerializerInclusive for GetOpenFileName IPC. r=jimm Use the new helper for serializing enums in IPDL.
3949da89d1c91ae3ffebe96fc3bdbb53762b58de: Merge mozilla-central to mozilla-inbound. r=merge a=merge CLOSED TREE
Margareta Eliza Balazs <ebalazs@mozilla.com> - Wed, 08 Nov 2017 00:09:29 +0200 - rev 390688
Push 32839 by nbeleuzu@mozilla.com at Wed, 08 Nov 2017 10:51:56 +0000
Merge mozilla-central to mozilla-inbound. r=merge a=merge CLOSED TREE
8e486e90b599027ed5d1edfc309639c17123a8c7: Bug 1414292 followup. Indexed properties are enumerable on Window per spec, and thus we fix the CLOSED TREE.
Boris Zbarsky <bzbarsky@mit.edu> - Tue, 07 Nov 2017 16:55:29 -0500 - rev 390687
Push 32839 by nbeleuzu@mozilla.com at Wed, 08 Nov 2017 10:51:56 +0000
Bug 1414292 followup. Indexed properties are enumerable on Window per spec, and thus we fix the CLOSED TREE. MozReview-Commit-ID: 6Q76VqwSiEx
f9aafdff7559fb7da5c829d00c874623bf8db2d6: Bug 1414994 - Set CONFIG_LINUX_PERF in media/ffvpx/config_android32.h to 0 to fix Android builds on MacOS r=jya
Randall Barker <rbarker@mozilla.com> - Tue, 07 Nov 2017 11:32:52 -0800 - rev 390686
Push 32839 by nbeleuzu@mozilla.com at Wed, 08 Nov 2017 10:51:56 +0000
Bug 1414994 - Set CONFIG_LINUX_PERF in media/ffvpx/config_android32.h to 0 to fix Android builds on MacOS r=jya MozReview-Commit-ID: 2wkqm8C2uJ6
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip