7d8eb7da6a8048124383395b5a6ebc24b63ad2a9: Bug 1474155: Part 3 - Move WebChannel message listeners to a separate JSM. r?mconley draft
Kris Maglione <maglione.k@gmail.com> - Sat, 07 Jul 2018 20:15:45 -0700 - rev 816229
Push 115782 by maglione.k@gmail.com at Tue, 10 Jul 2018 19:20:44 +0000
Bug 1474155: Part 3 - Move WebChannel message listeners to a separate JSM. r?mconley MozReview-Commit-ID: AHCTFDBnChn
9b0dffd9c3b675cd8b810a45b0c13d9c71f7952e: Bug 1474155: Part 2 - Move AutoCompletePopup to a separate JSM. r=mconley draft
Kris Maglione <maglione.k@gmail.com> - Tue, 10 Jul 2018 11:57:47 -0700 - rev 816228
Push 115782 by maglione.k@gmail.com at Tue, 10 Jul 2018 19:20:44 +0000
Bug 1474155: Part 2 - Move AutoCompletePopup to a separate JSM. r=mconley MozReview-Commit-ID: HH2kiS12aEV
979f6bf273f9f380c80219d24d7aa334d0d0e8a7: Bug 1474155: Part 1 - Move PopupBlocking to a separate JSM. r=mconley draft
Kris Maglione <maglione.k@gmail.com> - Tue, 10 Jul 2018 11:57:55 -0700 - rev 816227
Push 115782 by maglione.k@gmail.com at Tue, 10 Jul 2018 19:20:44 +0000
Bug 1474155: Part 1 - Move PopupBlocking to a separate JSM. r=mconley MozReview-Commit-ID: FbVGSsmt8C3
6b9b4c6e830a3e2bee93f800a53a694502a6a4f2: Bug 1473727 - Avoid recreating virtual environment every time by using a unique environment for each Python version; r?dustin draft
Dave Hunt <dhunt@mozilla.com> - Mon, 09 Jul 2018 14:57:38 +0100 - rev 816226
Push 115781 by bmo:dave.hunt@gmail.com at Tue, 10 Jul 2018 19:15:21 +0000
Bug 1473727 - Avoid recreating virtual environment every time by using a unique environment for each Python version; r?dustin This patch uses the PIPENV_PYTHON environment variable to append a suffix to the created virtual environment path according to the version specified. It also uses the PIPENV_DEFAULT_PYTHON_VERSION environment variable to avoid recreating the virtual environment every time. With these changes we are able to switch back and forth between Python versions without the expense of recreating environments, however there is a risk of these environments becoming stale. In this scenario it may be necessary to clobber the virtual environment root within the obj dir. MozReview-Commit-ID: C4vuwNh04CP
9624b3d7472df507b4a63a17fda3f924ef7ee817: Bug 1265824 - Guard client storage stuff behind a pref r?mattwoodrow draft
Doug Thayer <dothayer@mozilla.com> - Fri, 22 Jun 2018 11:10:41 -0700 - rev 816225
Push 115780 by bmo:dothayer@mozilla.com at Tue, 10 Jul 2018 19:13:22 +0000
Bug 1265824 - Guard client storage stuff behind a pref r?mattwoodrow MozReview-Commit-ID: DjKhtMDJ91C
4625baf10bc41a75fad8b4e3eef24142a9fa7064: Bug 1265824 - Wait on texture handles with IPC r?mattwoodrow draft
Doug Thayer <dothayer@mozilla.com> - Sat, 05 May 2018 15:46:26 -0700 - rev 816224
Push 115780 by bmo:dothayer@mozilla.com at Tue, 10 Jul 2018 19:13:22 +0000
Bug 1265824 - Wait on texture handles with IPC r?mattwoodrow There's a lot going on here, but it all fits under the idea of being able to communicate about texture locking statuses without spinning on IsReadLocked. This is a bit of a trade - we could just always allocate/grab a texture from the pool, which would put a smaller cap on the amount of time we can possibly spend when a texture is locked. However, this eats up more CPU and memory than waiting on the textures to unlock, and could take longer, especially if there were a large number of textures which we just need to wait for for a short amount of time. In any case, we very rarely hit the case where we actually need to wait on the sync IPC to the compositor - most of the time the textures are already unlocked. There is also an async IPC call in here, which we make before flushing async paints. This just causes the compositor to check whether the GPU is done with its textures or not and unlock them if it is. This helps us avoid the case where we take a long time painting asynchronously, turn IPC back on at the end of that, and then have to wait for the compositor to to get into TiledLayerBufferComposite::UseTiles before getting a response. Specifically this eliminates several talos regressions which use ASAP mode. Lastly, there seem to be no other cases of static Monitors being used. This seems like it falls under similar use cases as StaticMutexes, so I added it in. I can move it into its own file if we think it might be generally useful in the future. MozReview-Commit-ID: IYQLwUqMxg2
aea279f8255b321e4f37082c5c1f992ef3818fb3: Bug 1265824 - Guard client storage stuff behind a pref r?mattwoodrow draft
Doug Thayer <dothayer@mozilla.com> - Fri, 22 Jun 2018 11:10:41 -0700 - rev 816223
Push 115779 by bmo:dothayer@mozilla.com at Tue, 10 Jul 2018 18:54:43 +0000
Bug 1265824 - Guard client storage stuff behind a pref r?mattwoodrow MozReview-Commit-ID: DjKhtMDJ91C
7015cab49b6854c272a283876a40c94c1d7ab916: Bug 1265824 - Wait on texture handles with IPC r?mattwoodrow draft
Doug Thayer <dothayer@mozilla.com> - Sat, 05 May 2018 15:46:26 -0700 - rev 816222
Push 115779 by bmo:dothayer@mozilla.com at Tue, 10 Jul 2018 18:54:43 +0000
Bug 1265824 - Wait on texture handles with IPC r?mattwoodrow There's a lot going on here, but it all fits under the idea of being able to communicate about texture locking statuses without spinning on IsReadLocked. This is a bit of a trade - we could just always allocate/grab a texture from the pool, which would put a smaller cap on the amount of time we can possibly spend when a texture is locked. However, this eats up more CPU and memory than waiting on the textures to unlock, and could take longer, especially if there were a large number of textures which we just need to wait for for a short amount of time. In any case, we very rarely hit the case where we actually need to wait on the sync IPC to the compositor - most of the time the textures are already unlocked. There is also an async IPC call in here, which we make before flushing async paints. This just causes the compositor to check whether the GPU is done with its textures or not and unlock them if it is. This helps us avoid the case where we take a long time painting asynchronously, turn IPC back on at the end of that, and then have to wait for the compositor to to get into TiledLayerBufferComposite::UseTiles before getting a response. Specifically this eliminates several talos regressions which use ASAP mode. Lastly, there seem to be no other cases of static Monitors being used. This seems like it falls under similar use cases as StaticMutexes, so I added it in. I can move it into its own file if we think it might be generally useful in the future. MozReview-Commit-ID: IYQLwUqMxg2
8d27637a7296be10eef44de9ff252a62e9dc9f2d: Bug 1473974 - Fix opening all tabs panel with cycle recent tabs r?dao draft
Mark Striemer <mstriemer@mozilla.com> - Tue, 10 Jul 2018 13:48:57 -0500 - rev 816221
Push 115778 by bmo:mstriemer@mozilla.com at Tue, 10 Jul 2018 18:49:28 +0000
Bug 1473974 - Fix opening all tabs panel with cycle recent tabs r?dao MozReview-Commit-ID: EGYJo8AAF2K
1b3143e4ec831f400df95c1fef8ee87d6f3368d2: Bug 1418236 - Correct EventTarget for CSP violation events, r=ckerschb
Andrea Marchesini <amarchesini@mozilla.com> - Tue, 10 Jul 2018 17:40:21 +0200 - rev 816220
Push 115778 by bmo:mstriemer@mozilla.com at Tue, 10 Jul 2018 18:49:28 +0000
Bug 1418236 - Correct EventTarget for CSP violation events, r=ckerschb
8bcdfbe1d0dcf4ce58095da36fd8371fa68f7c3d: Bug 1473585 - Remove restoreLastSession function. r=dao
Manish Kumar <1991manish.kumar@gmail.com> - Sat, 07 Jul 2018 20:29:56 +0200 - rev 816219
Push 115778 by bmo:mstriemer@mozilla.com at Tue, 10 Jul 2018 18:49:28 +0000
Bug 1473585 - Remove restoreLastSession function. r=dao
bd281782dc93474944f6a9375312e7e3a31cd061: Bug 1474258 - Remove the "listheader" binding and move the remaining styles to "richlistbox.css". r=bgrins
Paolo Amadini <paolo.mozmail@amadzone.org> - Mon, 09 Jul 2018 12:45:41 +0100 - rev 816218
Push 115778 by bmo:mstriemer@mozilla.com at Tue, 10 Jul 2018 18:49:28 +0000
Bug 1474258 - Remove the "listheader" binding and move the remaining styles to "richlistbox.css". r=bgrins The content of this element is always overridden and the "xul:button" display mode is unnecessary, so the binding can be removed. The styles that control color are moved to "richlistbox.css" in preparation for the removal of the "listbox" element. MozReview-Commit-ID: 5pGVE6n34EL
0b45728b721042df9def2c5291e46b59cc6d248a: Bug 1472750 - Convert simple "listbox" instances to "richlistbox". r=bgrins
Paolo Amadini <paolo.mozmail@amadzone.org> - Mon, 09 Jul 2018 10:38:42 +0100 - rev 816217
Push 115778 by bmo:mstriemer@mozilla.com at Tue, 10 Jul 2018 18:49:28 +0000
Bug 1472750 - Convert simple "listbox" instances to "richlistbox". r=bgrins These simple lists are converted to normal layout by setting a fixed height that isn't a multiple of the row height, which is already the case for most other lists in the user interface. MozReview-Commit-ID: 1tV4MIoRp0d
a34a6f54da753e87e778e477f2760753ebf519b6: Bug 1463320 - Remove the "wizard-base" binding and import the "wizard.css" file as a document stylesheet. r=bgrins
Paolo Amadini <paolo.mozmail@amadzone.org> - Tue, 10 Jul 2018 14:39:35 +0100 - rev 816216
Push 115778 by bmo:mstriemer@mozilla.com at Tue, 10 Jul 2018 18:49:28 +0000
Bug 1463320 - Remove the "wizard-base" binding and import the "wizard.css" file as a document stylesheet. r=bgrins MozReview-Commit-ID: JRw6jnAhql2
d9682b4ae9898976ea45ffc238e60022e5e7ba9c: Bug 1472749 - fix reader mode on nytimes website (sync from github 7d03bec52d0a0c4b22d044e06af84abb15a9f02b), r=jaws
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Tue, 10 Jul 2018 14:24:43 +0100 - rev 816215
Push 115778 by bmo:mstriemer@mozilla.com at Tue, 10 Jul 2018 18:49:28 +0000
Bug 1472749 - fix reader mode on nytimes website (sync from github 7d03bec52d0a0c4b22d044e06af84abb15a9f02b), r=jaws
a08f23c05a4771efd66d14bf79c1edeaa227a47b: Bug1473030 - Show accessible object's name and role information with info-bar highlight. r=yzen draft
Micah Tigley <mtigley@mozilla.com> - Wed, 04 Jul 2018 09:52:40 -0400 - rev 816214
Push 115777 by bmo:mtigley@mozilla.com at Tue, 10 Jul 2018 18:35:06 +0000
Bug1473030 - Show accessible object's name and role information with info-bar highlight. r=yzen MozReview-Commit-ID: A7yeUbY5RxR
161e186bc16a99095f2510e47553fbc15fdcff27: Bug 1265824 - Guard client storage stuff behind a pref r?mattwoodrow draft
Doug Thayer <dothayer@mozilla.com> - Fri, 22 Jun 2018 11:10:41 -0700 - rev 816213
Push 115776 by bmo:dothayer@mozilla.com at Tue, 10 Jul 2018 18:33:51 +0000
Bug 1265824 - Guard client storage stuff behind a pref r?mattwoodrow MozReview-Commit-ID: DjKhtMDJ91C
787c3b0b9e52ebc250cfee72e1a29547c0de2731: Bug 1265824 - Wait on texture handles with IPC r?mattwoodrow draft
Doug Thayer <dothayer@mozilla.com> - Sat, 05 May 2018 15:46:26 -0700 - rev 816212
Push 115776 by bmo:dothayer@mozilla.com at Tue, 10 Jul 2018 18:33:51 +0000
Bug 1265824 - Wait on texture handles with IPC r?mattwoodrow There's a lot going on here, but it all fits under the idea of being able to communicate about texture locking statuses without spinning on IsReadLocked. This is a bit of a trade - we could just always allocate/grab a texture from the pool, which would put a smaller cap on the amount of time we can possibly spend when a texture is locked. However, this eats up more CPU and memory than waiting on the textures to unlock, and could take longer, especially if there were a large number of textures which we just need to wait for for a short amount of time. In any case, we very rarely hit the case where we actually need to wait on the sync IPC to the compositor - most of the time the textures are already unlocked. There is also an async IPC call in here, which we make before flushing async paints. This just causes the compositor to check whether the GPU is done with its textures or not and unlock them if it is. This helps us avoid the case where we take a long time painting asynchronously, turn IPC back on at the end of that, and then have to wait for the compositor to to get into TiledLayerBufferComposite::UseTiles before getting a response. Specifically this eliminates several talos regressions which use ASAP mode. Lastly, there seem to be no other cases of static Monitors being used. This seems like it falls under similar use cases as StaticMutexes, so I added it in. I can move it into its own file if we think it might be generally useful in the future. MozReview-Commit-ID: IYQLwUqMxg2
cbe7962f7da9138172774b54cddae654f8c1944e: Bug 1265824 - Add StaticMonitor r?froydnj draft
Doug Thayer <dothayer@mozilla.com> - Fri, 29 Jun 2018 15:27:22 -0700 - rev 816211
Push 115776 by bmo:dothayer@mozilla.com at Tue, 10 Jul 2018 18:33:51 +0000
Bug 1265824 - Add StaticMonitor r?froydnj For the IPC work monitoring when textures become unlocked, we need a Monitor equivalent of StaticMutex - this implements that. MozReview-Commit-ID: IceQNeqVQ8f
f5cbdceb802df4f80d36d7b0c31f3e2959fa1a18: Bug 1265824 - handle the texture uploading and readLock related things for direct mapping texture source r?mattwoodrow draft
Doug Thayer <dothayer@mozilla.com> - Wed, 02 May 2018 18:31:31 -0700 - rev 816210
Push 115776 by bmo:dothayer@mozilla.com at Tue, 10 Jul 2018 18:33:51 +0000
Bug 1265824 - handle the texture uploading and readLock related things for direct mapping texture source r?mattwoodrow MozReview-Commit-ID: BC065h1Ac6k
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 tip