4766eb7d938c42a17b31d2a7af48d5724582859d: Bug 1572484 - Add a mochitest for expanding content-originated logged object in browser console. r=Honza.
Nicolas Chevobbe <nchevobbe@mozilla.com> - Thu, 29 Aug 2019 15:33:31 +0000 - rev 490634
Push 36508 by csabou@mozilla.com at Thu, 29 Aug 2019 21:45:25 +0000
Bug 1572484 - Add a mochitest for expanding content-originated logged object in browser console. r=Honza. Differential Revision: https://phabricator.services.mozilla.com/D43266
9ba13ab83751e14ac5c7465abbd9eb6296ffc5e6: Bug 1577431 - Cleanup Browser Console when closing its window. r=ochameau.
Nicolas Chevobbe <nchevobbe@mozilla.com> - Thu, 29 Aug 2019 15:31:12 +0000 - rev 490633
Push 36508 by csabou@mozilla.com at Thu, 29 Aug 2019 21:45:25 +0000
Bug 1577431 - Cleanup Browser Console when closing its window. r=ochameau. We store the created DebuggerClient when opening the Browser Console so we can close it when closing the Browser Console window. The Browser Console window `unload` event listener is moved out of the BrowserConsole class to the BrowserConsoleManager, so we can close the DebuggerClient when the window is closed (plus it makes more sense to have it here since that's where we create the window). Finally, functions that were inlined in toggleBrowserConsole are moved as method of the BrowserConsoleManager for clarity. Differential Revision: https://phabricator.services.mozilla.com/D43930
4c2f7afa73da98e626db22ab8108d11b915d5760: Bug 1576072 - Add a new icon for granted permissions in the identity block + panel. r=nhnt11
Johann Hofmann <jhofmann@mozilla.com> - Thu, 29 Aug 2019 15:30:51 +0000 - rev 490632
Push 36508 by csabou@mozilla.com at Thu, 29 Aug 2019 21:45:25 +0000
Bug 1576072 - Add a new icon for granted permissions in the identity block + panel. r=nhnt11 Differential Revision: https://phabricator.services.mozilla.com/D43950
6b7bd6cb5ce0cb0776215116ad1f0cd4d2b0b44a: Bug 1576072 - Backed out changeset 93ae831e2fb9. r=timhuang
Johann Hofmann <jhofmann@mozilla.com> - Thu, 29 Aug 2019 15:30:39 +0000 - rev 490631
Push 36508 by csabou@mozilla.com at Thu, 29 Aug 2019 21:45:25 +0000
Bug 1576072 - Backed out changeset 93ae831e2fb9. r=timhuang Differential Revision: https://phabricator.services.mozilla.com/D43949
8761f39863afde4e9a27cb8afac788eb723ed919: Bug 1576072 - Backed out changeset 0a7463d82e5f. r=timhuang
Johann Hofmann <jhofmann@mozilla.com> - Thu, 29 Aug 2019 15:30:26 +0000 - rev 490630
Push 36508 by csabou@mozilla.com at Thu, 29 Aug 2019 21:45:25 +0000
Bug 1576072 - Backed out changeset 0a7463d82e5f. r=timhuang Differential Revision: https://phabricator.services.mozilla.com/D43948
03d9cfc6375de4a2708183ba8920670057e16fde: Bug 1507193 - Don't leave dangling js promises after seeking. r=jya
Andreas Pehrson <apehrson@mozilla.com> - Thu, 29 Aug 2019 14:30:06 +0000 - rev 490629
Push 36508 by csabou@mozilla.com at Thu, 29 Aug 2019 21:45:25 +0000
Bug 1507193 - Don't leave dangling js promises after seeking. r=jya Only SeekToNextFrame cares about promises, but prior to this patch the common method HTMLMediaElement::Seek() would always return a promise. When the caller was not SeekToNextFrame (e.g., SetCurrentTime, FastSeek), the promise would end up *not* being exposed. When later rejected, we would catch this and write an error to the js console. This patch lifts the handling of the promise out of Seek() and into SeekToNextFrame() so that we avoid creating promises that would not get exposed to js. Differential Revision: https://phabricator.services.mozilla.com/D42511
716ad5a4347ec6ee6cdcc7d16b95da5e4ad7e8d2: Bug 1577180 - Get a profile before accessing BrowserGlue in test_getPotentialBreachesByLoginGUID.js. r=jaws
Matthew Noorenberghe <mozilla@noorenberghe.ca> - Thu, 29 Aug 2019 15:20:53 +0000 - rev 490628
Push 36508 by csabou@mozilla.com at Thu, 29 Aug 2019 21:45:25 +0000
Bug 1577180 - Get a profile before accessing BrowserGlue in test_getPotentialBreachesByLoginGUID.js. r=jaws I'm not sure of the exact cause since that would require doing a local Windows beta build and the getService error doesn't indicate what failed inside the component. I mostly guessed that this was the problem by looking at other tests which do the same thing. Differential Revision: https://phabricator.services.mozilla.com/D43899
32bc8be194acef156fa4ef70ee9a7aa5c826e15b: Bug 1574819 - Bookmarks Menu Button popup doesn't auto-open on drag enter r=mak
Alexander Surkov <surkov.alexander@gmail.com> - Thu, 29 Aug 2019 13:15:51 +0000 - rev 490627
Push 36508 by csabou@mozilla.com at Thu, 29 Aug 2019 21:45:25 +0000
Bug 1574819 - Bookmarks Menu Button popup doesn't auto-open on drag enter r=mak Differential Revision: https://phabricator.services.mozilla.com/D43801
6b78b362900bc8e0a5f4289cae027f4d8a47f0b5: Bug 1534445 - Use same colors as webconsole warning messages in settings panel deprecation label. r=rcaliman .
Nicolas Chevobbe <nchevobbe@mozilla.com> - Thu, 29 Aug 2019 15:03:51 +0000 - rev 490626
Push 36508 by csabou@mozilla.com at Thu, 29 Aug 2019 21:45:25 +0000
Bug 1534445 - Use same colors as webconsole warning messages in settings panel deprecation label. r=rcaliman . In order to do this properly, we create new variable in variables.css that hold the same values as the console-warning-* variables we have in webconsole.css. We take this as an opportunity to replace the box shadow on the deprecation label by an outline. I think this was done so the border doesn't take additional height, and outline seems perfect for this job. Differential Revision: https://phabricator.services.mozilla.com/D43933
89a456a830022193716a0d3d04e30945930f81dc: Bug 1575263 - Allow clippy double option, remove redundant let binding r=jgraham
David Heiberg <dheiberg@mozilla.com> - Thu, 29 Aug 2019 14:50:28 +0000 - rev 490625
Push 36508 by csabou@mozilla.com at Thu, 29 Aug 2019 21:45:25 +0000
Bug 1575263 - Allow clippy double option, remove redundant let binding r=jgraham Differential Revision: https://phabricator.services.mozilla.com/D43976
399d210c5a19f919249949f5fb60ffbf66d0cc87: Bug 1544810 - test disabled on linux64 and macosx 10.14 r=gbrown
Andreea Pavel <apavel@mozilla.com> - Thu, 29 Aug 2019 14:15:03 +0000 - rev 490624
Push 36508 by csabou@mozilla.com at Thu, 29 Aug 2019 21:45:25 +0000
Bug 1544810 - test disabled on linux64 and macosx 10.14 r=gbrown Differential Revision: https://phabricator.services.mozilla.com/D43974
3ab80bbb5b170871af2d9e595fd17c5716f13334: Bug 1562929 - Use the default private search engine in the context menu. r=daleharvey
Mark Banner <standard8@mozilla.com> - Thu, 29 Aug 2019 14:43:43 +0000 - rev 490623
Push 36508 by csabou@mozilla.com at Thu, 29 Aug 2019 21:45:25 +0000
Bug 1562929 - Use the default private search engine in the context menu. r=daleharvey Differential Revision: https://phabricator.services.mozilla.com/D43771
2cb6309ecb2323d2519577bdb6cb5b0fa1225e36: Bug 1562926 - Use the default private search engine in the address bar. r=daleharvey
Mark Banner <standard8@mozilla.com> - Thu, 29 Aug 2019 14:43:43 +0000 - rev 490622
Push 36508 by csabou@mozilla.com at Thu, 29 Aug 2019 21:45:25 +0000
Bug 1562926 - Use the default private search engine in the address bar. r=daleharvey Differential Revision: https://phabricator.services.mozilla.com/D43244
d4fa68b6082945c60fb06af4eb3394eaeeb30e86: Bug 1562922 - Add more tests to ensure the private search engine is correctly loaded from settings. r=daleharvey
Mark Banner <standard8@mozilla.com> - Thu, 29 Aug 2019 10:04:34 +0000 - rev 490621
Push 36508 by csabou@mozilla.com at Thu, 29 Aug 2019 21:45:25 +0000
Bug 1562922 - Add more tests to ensure the private search engine is correctly loaded from settings. r=daleharvey Depends on D43091 Differential Revision: https://phabricator.services.mozilla.com/D43092
93e8ce4c2a59392b71b9263f48479e1138a71eb0: Bug 1562922 - If the default private search engine is different to normal mode, it should default to second in the sorted list. r=daleharvey
Mark Banner <standard8@mozilla.com> - Thu, 29 Aug 2019 09:45:19 +0000 - rev 490620
Push 36508 by csabou@mozilla.com at Thu, 29 Aug 2019 21:45:25 +0000
Bug 1562922 - If the default private search engine is different to normal mode, it should default to second in the sorted list. r=daleharvey Depends on D42957 Differential Revision: https://phabricator.services.mozilla.com/D43091
fd259cdfd3f12d146af5f3b756a55e8659761d78: Bug 1562922 - Handle removing the currently set default private search engine. r=daleharvey
Mark Banner <standard8@mozilla.com> - Thu, 29 Aug 2019 09:35:34 +0000 - rev 490619
Push 36508 by csabou@mozilla.com at Thu, 29 Aug 2019 21:45:25 +0000
Bug 1562922 - Handle removing the currently set default private search engine. r=daleharvey Depends on D42956 Differential Revision: https://phabricator.services.mozilla.com/D42957
8d8222618be18cf199fe8c31f213c26d8c4b2126: Bug 1562922 - Implement handling a separate private default engine via nsISearchService.defaultPrivateEngine. r=daleharvey
Mark Banner <standard8@mozilla.com> - Thu, 29 Aug 2019 09:34:35 +0000 - rev 490618
Push 36508 by csabou@mozilla.com at Thu, 29 Aug 2019 21:45:25 +0000
Bug 1562922 - Implement handling a separate private default engine via nsISearchService.defaultPrivateEngine. r=daleharvey Differential Revision: https://phabricator.services.mozilla.com/D42956
fb40acd1ac7fa2460762eb7af466645e3054be20: Bug 1574812 - Don't try...catch routeMessageToTarget, only the sendAsyncMessage. r=Mardak
Matthew Noorenberghe <mozilla@noorenberghe.ca> - Thu, 29 Aug 2019 05:03:30 +0000 - rev 490617
Push 36508 by csabou@mozilla.com at Thu, 29 Aug 2019 21:45:25 +0000
Bug 1574812 - Don't try...catch routeMessageToTarget, only the sendAsyncMessage. r=Mardak As far as I can tell the try...catch was originally added around various sendAsyncMessage calls but then when some logic got moved to a helper, the try...catch didn't move along with it. This try...catch made it very annoying to debug an issue with bug 1570372 because it swallowed errors that were getting thrown. It doesn't seem like a good idea to swallow all errors for large pieces of code. Differential Revision: https://phabricator.services.mozilla.com/D43863
02bfa4baa2edd2d1c9417018c4cbd85e99d15aa8: Bug 1577243 - Backed out changeset cae99e27ccdd, restoring document.timeline and rAF timestamp comparisons r=birtles
Tom Ritter <tom@mozilla.com> - Wed, 28 Aug 2019 23:44:14 +0000 - rev 490616
Push 36508 by csabou@mozilla.com at Thu, 29 Aug 2019 21:45:25 +0000
Bug 1577243 - Backed out changeset cae99e27ccdd, restoring document.timeline and rAF timestamp comparisons r=birtles Depends on D43788 Differential Revision: https://phabricator.services.mozilla.com/D43789
565a897065e0deb97864b7635bfb0185e88c4048: Bug 1577243 - Unconditionally clamp the requestAnimationFrame timestamp (and clamp/jitter it in RFP mode) r=birtles
Tom Ritter <tom@mozilla.com> - Wed, 28 Aug 2019 23:44:07 +0000 - rev 490615
Push 36508 by csabou@mozilla.com at Thu, 29 Aug 2019 21:45:25 +0000
Bug 1577243 - Unconditionally clamp the requestAnimationFrame timestamp (and clamp/jitter it in RFP mode) r=birtles In Bug 1387894 we created a mode for Firefox where it unconditionally clamps all timestamps to 20 microseconds. This happens if you disable privacy.reduceTimerPrecision (which is on by default) and is so we don't inadvertently leak super-high-resolution (nanosec) timestamps. As part of that patch, we started clamping animation timestamps - which are exempted from privacy.reduceTimerPrecision because it was too difficult to get them working at the time. (We should still fix that though.) This caused new test failures, and one of those was a comparison between document timelines and the timestamp in requestAnimationFrame. we were not clamping the timestamp in requestAnimationFrame under the logic that it fires in predictable intervals. However discussions about the WPT change we made to 'fix' the now-broken comparison https://github.com/web-platform-tests/wpt/pull/18172 and https://github.com/web-platform-tests/wpt/pull/18357 showed me that document.timeline is supposed to be slaved to the requestAnimationFrame timestamp (or vice versa.) The correct fix is therefore to unconditionally clamp the requestAnimationFrame timestamp AND the document.timeline timestamp. In doing so we also start clamping/jittering the requestAnimationFrame timestamp in Resist Fingerprinting mode, so that might cause some new/unexpected behaviors for that mode we should watch out for. Differential Revision: https://phabricator.services.mozilla.com/D43788
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip