f7ec887c2ef0bb46c0ca107f3d6ea7705477a953: Bug 1440040 - Don't round up to next block unless necessary. r?padenot draft
Andreas Pehrson <pehrsons@mozilla.com> - Wed, 28 Feb 2018 22:37:02 +0100 - rev 761297
Push 100932 by bmo:apehrson@mozilla.com at Wed, 28 Feb 2018 22:06:38 +0000
Bug 1440040 - Don't round up to next block unless necessary. r?padenot With block size 128, rounding `128` to end of next block gives `256`, which is not what we want when running MSG iterations. That could mean over-iterating and buffering unnecessary amounts of silence. MozReview-Commit-ID: vW14l2ygRy
330d440f1f762d60f36af0b400fed66bdf71f51a: Bug 1441378 - Replace baseMenuOverlay.xul with inlining and preprocessing. r?gijs draft
Brendan Dahl <brendan.dahl@gmail.com> - Mon, 26 Feb 2018 16:49:34 -0800 - rev 761296
Push 100931 by bmo:bdahl@mozilla.com at Wed, 28 Feb 2018 22:04:39 +0000
Bug 1441378 - Replace baseMenuOverlay.xul with inlining and preprocessing. r?gijs The overlay defined two elements (helpMenu, menu_ToolsPopup) for all platforms and three others (windowMenu, baseMenuCommandSet, baseMenuKeyset) that were MacOS only. The two all platform elements and windowMenu were only used once and inlined into browser-menubar.inc. The rest of the MacOS only elements were conditionally inlined into browser-sets.inc. MozReview-Commit-ID: D2uyCrnepuH
3c61b6ec14a6efd8dc226b06aa03514fcb031408: Bug 1437438 - Add a performance counter to track scheduler activity - r?farre r?froydnj draft
Tarek Ziadé <tarek@mozilla.com> - Mon, 12 Feb 2018 09:22:16 +0100 - rev 761295
Push 100930 by tziade@mozilla.com at Wed, 28 Feb 2018 22:01:54 +0000
Bug 1437438 - Add a performance counter to track scheduler activity - r?farre r?froydnj Adds a PeformanceCounter class that is used in DocGroup and WorkerPrivate to track runnables execution and dispatch counts. MozReview-Commit-ID: 51DLj6ORD2O
a6abfcd8af5c6f19d57fe52fbaf071d496d9049a: Bug 1437382 - Part 11 - Shorten save delay when private tabs are closed. r?esawin draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 17 Feb 2018 16:42:13 +0100 - rev 761294
Push 100929 by mozilla@buttercookie.de at Wed, 28 Feb 2018 22:01:37 +0000
Bug 1437382 - Part 11 - Shorten save delay when private tabs are closed. r?esawin In most cases (e.g. new tabs added, page navigation, scrolling, etc.), we can live with the fact the the private tab data held by GeckoApp might be up to ~10 seconds out of date if we don't manage to send an update within the time limit given by the UI during backgrounding. Where the closing of private tabs is concerned, this is different, as not remembering that the user already closed some tabs just before switching away from Firefox could lead to potentially embarrassing situations when the user returns and unexpectedly finds those tabs still open. Therefore we now use the infrastructure added in the previous parts to speed up the saving process when private tabs are closed. MozReview-Commit-ID: KpfXinOl5Ki
ce36990aed01026cfea48381ff93094a1573d4e8: Bug 1437382 - Part 10 - Use a reduced save delay when saving private tabs. r?esawin draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 17 Feb 2018 16:31:20 +0100 - rev 761293
Push 100929 by mozilla@buttercookie.de at Wed, 28 Feb 2018 22:01:37 +0000
Bug 1437382 - Part 10 - Use a reduced save delay when saving private tabs. r?esawin ... and also shorten any already running save timer if necessary. This is because the private tab data kept by GeckoApp, that will be restored if we are OOM-killed, cannot be updated anymore after Firefox goes into the back- ground, even if we aren't immediately killed by the OS. Because during backgrounding the UI only waits a limited amount of time for the latest private tab data in order to avoid causing an ANR if Gecko is busy, we need to compensate by sending private tab data updates faster to GeckoApp than the usual write throttling interval of every 10 s would allow. To allow multiple successive tab events to be batched together in one update, e.g. if the user closes *all* private tabs, we still introduce a small save delay of a few hundred ms. MozReview-Commit-ID: J15RNfAlfy2
13ce5e430bd77130f3385994edeba91a959f5662: Bug 1437382 - Part 9 - Track number of outstanding "private tabs only" saveState calls. r?esawin draft
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 12 Feb 2018 22:15:35 +0100 - rev 761292
Push 100929 by mozilla@buttercookie.de at Wed, 28 Feb 2018 22:01:37 +0000
Bug 1437382 - Part 9 - Track number of outstanding "private tabs only" saveState calls. r?esawin Private tabs are saved in memory only by sending them to GeckoApp, so to speed up processing (compare part 3), we want to avoid writing out the full session store file for normal tabs as well if all outstanding saveState(Delayed) calls concerned private tabs only. To that effect, we slightly change the semantics of our pendingWrites counter and now increment it each time saveStateDelayed is called, even if the save timer is already running. This is because if e.g. a private tab update started the timer and then another saveStateDelayed call happens for a non-private tab, we need to change our plans and write the normal session store file after all as well. Tracking every saveStateDelayed call allows us to do this. Because writeFile only cares about the fact whether additional pending writes were queued while it was executing asynchronously or not, but not about the absolute amount of pending writes (if no additional writes were queued, the count is simply reset to 0), incrementing the pending writes count even when the timer is already running causes no ill effects. MozReview-Commit-ID: AjhIp8bpyf
80841a51f5bc95a82debfe0dce5941ea75f3e65e: Bug 1437382 - Part 8 - Extract functions for creating and cancelling the delayed write timer. r?esawin draft
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 12 Feb 2018 20:19:15 +0100 - rev 761291
Push 100929 by mozilla@buttercookie.de at Wed, 28 Feb 2018 22:01:37 +0000
Bug 1437382 - Part 8 - Extract functions for creating and cancelling the delayed write timer. r?esawin MozReview-Commit-ID: BjZ2XYSi9rR
84a78e6e6569fc4996251934a71549bc9b38edc4: Bug 1437382 - Part 7 - Change session store time callback behaviour. r?esawin draft
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 12 Feb 2018 20:11:46 +0100 - rev 761290
Push 100929 by mozilla@buttercookie.de at Wed, 28 Feb 2018 22:01:37 +0000
Bug 1437382 - Part 7 - Change session store time callback behaviour. r?esawin When we get a timer callback for delayed saving, we already only proceed if we've still got a write pending. Conversely if for whatever reasons _saveState() is called from outside of a timer callback, any still pending save timer is cancelled again. With that in mind, when executing the delayed write timer callback there's no reason to call the public version of saveState(), whose only extra task is to increment the pending write count again. Instead, we can just directly call the internal _saveState() version. MozReview-Commit-ID: 11EucNm5KFB
cad3279bc236bc08e1c3d93f4185c73f2469bf14: Bug 1437382 - Part 6 - Switch to using PrivateBrowsing helper method in session store. r?esawin draft
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 12 Feb 2018 20:37:07 +0100 - rev 761289
Push 100929 by mozilla@buttercookie.de at Wed, 28 Feb 2018 22:01:37 +0000
Bug 1437382 - Part 6 - Switch to using PrivateBrowsing helper method in session store. r?esawin As far as I can tell, that line dates back to approximately the time Private- BrowsingUtils were introduced in the first place. MozReview-Commit-ID: BLn13X7DVJt
e146edabe9d179114059b52d6b7cc5ca5cae2c63: Bug 1437382 - Part 5 - Test that flushing pending session store data sends the expected messages to Java. r?jchen draft
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 20 Feb 2018 20:18:36 +0100 - rev 761288
Push 100929 by mozilla@buttercookie.de at Wed, 28 Feb 2018 22:01:37 +0000
Bug 1437382 - Part 5 - Test that flushing pending session store data sends the expected messages to Java. r?jchen We attempt to get the session store into a known state as far as is possible from Java and then test various situations to check that the expected "PrivateBrowsing:Data" message is received in each case. MozReview-Commit-ID: 8RkCQjAPXTT
6f34eaa0b2ed73d85a808be41586d9017e06c0e1: Bug 1441622 - Expose the OpenType Font Variations data to the fonts redux store. r=pbro draft
Gabriel Luong <gabriel.luong@gmail.com> - Wed, 28 Feb 2018 16:55:19 -0500 - rev 761287
Push 100928 by bmo:gl@mozilla.com at Wed, 28 Feb 2018 21:56:48 +0000
Bug 1441622 - Expose the OpenType Font Variations data to the fonts redux store. r=pbro MozReview-Commit-ID: 5vrFfJ7XrYq
798942924efd92d29011b04291e37f7d0f745a34: Bug 1440169 - Improve MediaEngineWebRTCMicrophoneSource logging. r?padenot draft
Andreas Pehrson <pehrsons@mozilla.com> - Wed, 28 Feb 2018 22:46:33 +0100 - rev 761286
Push 100927 by bmo:apehrson@mozilla.com at Wed, 28 Feb 2018 21:53:44 +0000
Bug 1440169 - Improve MediaEngineWebRTCMicrophoneSource logging. r?padenot MozReview-Commit-ID: 8WdzSc9FDPm
1e2c0767e0fbf3b9d5eafa0b19dc83ec0662410b: Bug 1440169 - Fix assertion that checks for appending silence in real callback when enabled. r?padenot draft
Andreas Pehrson <pehrsons@mozilla.com> - Wed, 28 Feb 2018 22:45:40 +0100 - rev 761285
Push 100927 by bmo:apehrson@mozilla.com at Wed, 28 Feb 2018 21:53:44 +0000
Bug 1440169 - Fix assertion that checks for appending silence in real callback when enabled. r?padenot MozReview-Commit-ID: 2W53PfUBK7V
2d7b2dff50b9f0321bdcfa05eace71c5ca180856: Bug 1440169 - Properly apply microphone capture settings. r?padenot draft
Andreas Pehrson <pehrsons@mozilla.com> - Wed, 28 Feb 2018 22:41:15 +0100 - rev 761284
Push 100927 by bmo:apehrson@mozilla.com at Wed, 28 Feb 2018 21:53:44 +0000
Bug 1440169 - Properly apply microphone capture settings. r?padenot MozReview-Commit-ID: FDVPwTIzDIX
e49769fe6abee9b373105be3c1fca2ae595f6854: Bug 1440169 - Don't round up to next block unless necessary. r?padenot draft
Andreas Pehrson <pehrsons@mozilla.com> - Wed, 28 Feb 2018 22:37:02 +0100 - rev 761283
Push 100927 by bmo:apehrson@mozilla.com at Wed, 28 Feb 2018 21:53:44 +0000
Bug 1440169 - Don't round up to next block unless necessary. r?padenot With block size 128, rounding `128` to end of next block gives `256`, which is not what we want when running MSG iterations. That could mean over-iterating and buffering unnecessary amounts of silence. MozReview-Commit-ID: 4Bja8ows5dJ
bea663d56ca2f21951447b395aebb9aec21cccea: Bug 1440437 - temporary fix/workaround for tp6 win production, r=jmaher draft
Rob Wood <rwood@mozilla.com> - Mon, 26 Feb 2018 10:59:27 -0500 - rev 761282
Push 100926 by rwood@mozilla.com at Wed, 28 Feb 2018 21:51:29 +0000
Bug 1440437 - temporary fix/workaround for tp6 win production, r=jmaher MozReview-Commit-ID: KoOlq3HKSBb
13702241dca9ebf766973e607d1f3dee600de69b: Bug 1441766 - Add a test for searching in the site data group. r=nhnt11
Johann Hofmann <jhofmann@mozilla.com> - Wed, 28 Feb 2018 15:48:15 +0100 - rev 761281
Push 100926 by rwood@mozilla.com at Wed, 28 Feb 2018 21:51:29 +0000
Bug 1441766 - Add a test for searching in the site data group. r=nhnt11 MozReview-Commit-ID: I0TrEXIaBzY
161a8e168596d92afa8c7f0c3bc46e185e2ee540: Bug 1441766 - Fix search keywords for site data and cookies in about:preferences. r=nhnt11
Johann Hofmann <jhofmann@mozilla.com> - Wed, 28 Feb 2018 10:04:21 +0100 - rev 761280
Push 100926 by rwood@mozilla.com at Wed, 28 Feb 2018 21:51:29 +0000
Bug 1441766 - Fix search keywords for site data and cookies in about:preferences. r=nhnt11 When moving cookies to the site data section we forgot about some searchkeywords which were left on the cookies exceptions dialog. We also forgot to remove the status column label when removing the status column. Further, the search tooltip is not displayed correctly on the three vertically aligned dialog buttons (it's always on the last button), because we did not put each of them in its own hbox (which is just way too easy to get wrong and needs a better mid term solution). MozReview-Commit-ID: L6ZaocWsjYU
a8f35224e73f485c6c9367a741cbc56faca065c4: Bug 1441198 - Part 3 - Add some space above the cookies preferences. r=nhnt11
Johann Hofmann <jhofmann@mozilla.com> - Wed, 28 Feb 2018 09:59:39 +0100 - rev 761279
Push 100926 by rwood@mozilla.com at Wed, 28 Feb 2018 21:51:29 +0000
Bug 1441198 - Part 3 - Add some space above the cookies preferences. r=nhnt11 MozReview-Commit-ID: 4d0aYIgZZ32
86dbf9b038d475000cf7fa62edba8714a60c43b9: Bug 1441198 - Part 2 - Fix side spacing and line breaking of items adjacent to the site data description in about:preferences. r=nhnt11
Johann Hofmann <jhofmann@mozilla.com> - Wed, 28 Feb 2018 09:58:47 +0100 - rev 761278
Push 100926 by rwood@mozilla.com at Wed, 28 Feb 2018 21:51:29 +0000
Bug 1441198 - Part 2 - Fix side spacing and line breaking of items adjacent to the site data description in about:preferences. r=nhnt11 When adding more characters to the description in the site data section, the display of the adjacent items breaks in two ways: - The "Learn More" link is pushed to the next line while it should stay on the same line as the description. I didn't really find a way to fix this while using a XUL label, so I switched to an html:span which has the correct layout. I don't see any drawbacks with using a span here. - The description text could in certain edge cases get too close to the "Clear Data" button. To fix that I added a new class which adds some padding. This isn't a problem in other parts of preferences except the history section (bug 1441138), where I also added this class. MozReview-Commit-ID: FO5tEx19ZUm
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip