984133e9614baa845a6dca7fc2cc6ca50cbb1687: Bug 1265824 - Pass the texture direct mapping info to all texture creating functions r=mattwoodrow
Doug Thayer <dothayer@mozilla.com> - Wed, 02 May 2018 18:20:25 -0700 - rev 427223
Push 34296 by rgurzau@mozilla.com at Thu, 19 Jul 2018 09:52:36 +0000
Bug 1265824 - Pass the texture direct mapping info to all texture creating functions r=mattwoodrow The client side can't get the GL context in CompositorOGL. So, it can't know the texture direct mapping capability directly. This patch adds the texture direct mapping info in TextureFactoryIdentifier. Then, the client side could get the info form the TextureFactoryIdentifier. MozReview-Commit-ID: KEazDVg0p9Y
efce316a4425c1e91f9b409806c6df3e6a7df99b: Bug 1265824 - Add a new texture source type "DirectMapTextureSource" r=mattwoodrow
Doug Thayer <dothayer@mozilla.com> - Wed, 02 May 2018 18:20:10 -0700 - rev 427222
Push 34296 by rgurzau@mozilla.com at Thu, 19 Jul 2018 09:52:36 +0000
Bug 1265824 - Add a new texture source type "DirectMapTextureSource" r=mattwoodrow The DirectMapTextureSource could let the compositor to read the buffer directly. That could get rid of some memory copy operations during texture uploading. MozReview-Commit-ID: CHhoR96P7VG
367abce3066851d02ad7433b194fc0bea810d8c1: Bug 1265824 - Remove the unsed member in GLTextureSource r=mattwoodrow
Doug Thayer <dothayer@mozilla.com> - Wed, 02 May 2018 18:19:54 -0700 - rev 427221
Push 34296 by rgurzau@mozilla.com at Thu, 19 Jul 2018 09:52:36 +0000
Bug 1265824 - Remove the unsed member in GLTextureSource r=mattwoodrow The "mExternallyOwned" is used for gralloc buffer. We don't use the gralloc buffer now. MozReview-Commit-ID: 7Gurpa3kdp0
c2ac7299fa0e64d7c02141ff16d81d8cb263c8f2: Backed out changeset 627f2adec73b (bug 1476647) for causing failures in devtools/client/storage/test/browser_storage_overflow.js
Margareta Eliza Balazs <ebalazs@mozilla.com> - Thu, 19 Jul 2018 09:05:35 +0300 - rev 427220
Push 34296 by rgurzau@mozilla.com at Thu, 19 Jul 2018 09:52:36 +0000
Backed out changeset 627f2adec73b (bug 1476647) for causing failures in devtools/client/storage/test/browser_storage_overflow.js
326bfb34675852cd2f86ebc7153a566099bda48f: Bug 1449972 - part3: Add shadowdom support to getCssPath, getXPath;r=bgrins
Julian Descottes <jdescottes@mozilla.com> - Tue, 17 Jul 2018 14:20:54 +0200 - rev 427219
Push 34296 by rgurzau@mozilla.com at Thu, 19 Jul 2018 09:52:36 +0000
Bug 1449972 - part3: Add shadowdom support to getCssPath, getXPath;r=bgrins MozReview-Commit-ID: 1NqIOSqY4Gg
313140e662627a02478beb8809b26be0c7ee3d8c: Bug 1449972 - part2: Move getCssPath and getXPath to toolkit css-selector;r=bgrins
Julian Descottes <jdescottes@mozilla.com> - Wed, 18 Jul 2018 07:33:21 +0200 - rev 427218
Push 34296 by rgurzau@mozilla.com at Thu, 19 Jul 2018 09:52:36 +0000
Bug 1449972 - part2: Move getCssPath and getXPath to toolkit css-selector;r=bgrins getCssPath and getXPath will need to reuse the same logic as findCssSelector to handle shadowDOM support. This patch moves the methods next to findCssSelector, in toolkit's css-selector.js to avoid duplicating logic between devtools/ and toolkit/ The content of the methods is stricltly the same, except for the Node global not available in css-selector.js. Instead we use `ele.ownerGlobal.Node` here. MozReview-Commit-ID: J0KuORWLUoO
11b67cb2ff4accff4fdd91c6ab8b1a0c259b18d2: Bug 1449972 - part1: Move shadowdom logic outside of getRootBindingParent;r=bgrins
Julian Descottes <jdescottes@mozilla.com> - Tue, 17 Jul 2018 11:45:34 +0200 - rev 427217
Push 34296 by rgurzau@mozilla.com at Thu, 19 Jul 2018 09:52:36 +0000
Bug 1449972 - part1: Move shadowdom logic outside of getRootBindingParent;r=bgrins This is a follow-up to the changes made in Bug 1449968. It makes more sense to preserve getRootBindingParent from shadowdom logic because: - getBindingParent for a node in a shadow root returns the host component, so it was weird that getRootBindingParent would return a node lower in the hierarchy - getRootBindingParent is currently duplicated between toolkit and devtools, and this made the implementations inconsistent MozReview-Commit-ID: LNVEY8TzUKI
627f2adec73bfe730ffe52b24dcfbae813860190: Bug 1476647 - Fix TableWidget scroll position calculation;r=miker
Julian Descottes <jdescottes@mozilla.com> - Wed, 18 Jul 2018 18:01:29 +0200 - rev 427216
Push 34296 by rgurzau@mozilla.com at Thu, 19 Jul 2018 09:52:36 +0000
Bug 1476647 - Fix TableWidget scroll position calculation;r=miker MozReview-Commit-ID: Kn9PQMXG8bC
756e2c3052d46f673f03b697c095cea99c896dde: Backed out 3 changesets (bug 1449972) for ES lint failure in /builds/worker/checkouts/gecko/devtools/shared/inspector/css-logic.js on a CLOSED TREE
Margareta Eliza Balazs <ebalazs@mozilla.com> - Thu, 19 Jul 2018 08:31:56 +0300 - rev 427215
Push 34296 by rgurzau@mozilla.com at Thu, 19 Jul 2018 09:52:36 +0000
Backed out 3 changesets (bug 1449972) for ES lint failure in /builds/worker/checkouts/gecko/devtools/shared/inspector/css-logic.js on a CLOSED TREE Backed out changeset 952a605a3b21 (bug 1449972) Backed out changeset c3379a87de69 (bug 1449972) Backed out changeset 5f678f861c4d (bug 1449972)
952a605a3b21461b90b261e38953deb4775bcc12: Bug 1449972 - part3: Add shadowdom support to getCssPath, getXPath;r=bgrins
Julian Descottes <jdescottes@mozilla.com> - Tue, 17 Jul 2018 14:20:54 +0200 - rev 427214
Push 34296 by rgurzau@mozilla.com at Thu, 19 Jul 2018 09:52:36 +0000
Bug 1449972 - part3: Add shadowdom support to getCssPath, getXPath;r=bgrins MozReview-Commit-ID: 1NqIOSqY4Gg
c3379a87de694e2149c676bc973adefdb306adb1: Bug 1449972 - part2: Move getCssPath and getXPath to toolkit css-selector;r=bgrins
Julian Descottes <jdescottes@mozilla.com> - Wed, 18 Jul 2018 07:33:21 +0200 - rev 427213
Push 34296 by rgurzau@mozilla.com at Thu, 19 Jul 2018 09:52:36 +0000
Bug 1449972 - part2: Move getCssPath and getXPath to toolkit css-selector;r=bgrins getCssPath and getXPath will need to reuse the same logic as findCssSelector to handle shadowDOM support. This patch moves the methods next to findCssSelector, in toolkit's css-selector.js to avoid duplicating logic between devtools/ and toolkit/ The content of the methods is stricltly the same, except for the Node global not available in css-selector.js. Instead we use `ele.ownerGlobal.Node` here. MozReview-Commit-ID: J0KuORWLUoO
5f678f861c4ddce230b84f8f0169409ed2f267f3: Bug 1449972 - part1: Move shadowdom logic outside of getRootBindingParent;r=bgrins
Julian Descottes <jdescottes@mozilla.com> - Tue, 17 Jul 2018 11:45:34 +0200 - rev 427212
Push 34296 by rgurzau@mozilla.com at Thu, 19 Jul 2018 09:52:36 +0000
Bug 1449972 - part1: Move shadowdom logic outside of getRootBindingParent;r=bgrins This is a follow-up to the changes made in Bug 1449968. It makes more sense to preserve getRootBindingParent from shadowdom logic because: - getBindingParent for a node in a shadow root returns the host component, so it was weird that getRootBindingParent would return a node lower in the hierarchy - getRootBindingParent is currently duplicated between toolkit and devtools, and this made the implementations inconsistent MozReview-Commit-ID: LNVEY8TzUKI
bdf8618dc2c36ebbea502b9e2fb608eca4674cc8: Bug 1453629 - nsIWidget::GetNativeIMEContext() should return pseudo IME context if TextInputProcessor has a composition on the widget r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 17 Jul 2018 22:31:51 +0900 - rev 427211
Push 34296 by rgurzau@mozilla.com at Thu, 19 Jul 2018 09:52:36 +0000
Bug 1453629 - nsIWidget::GetNativeIMEContext() should return pseudo IME context if TextInputProcessor has a composition on the widget r=m_kato Key of TextCompositionArrary to search composition on widget is native IME context. However, if TextInputProcessor dispatches composition events via TextEventDispatcher, TextEventDispatcher::InitEvent() sets native IME context of dispatching composition events to pseudo IME context (that's raw pointer of TextEventDispatcher and process ID). IMEStateManager::DispatchCompositionEvent() looks for existing TextComposition with native IME context stored in WidgetCompositionEvent before dispatching an event. However, after dispatching it, it looks for remaining TextComposition instance with widget stored in WidgetCompositionEvent. Then, TextCompositionArrary::IndexOf(nsIWidget*) will look for an instance with the result of nsIWidget::GetNativeIMEContext() and this never returns actual native IME context. Therefore, IMEStateManager::DispatchCompositionEvent() always fails to remove TextComposition instance from the array even after a test composition is finished. This patch moves nsIWidget::GetNativeIMEContext() to nsBaseWidget to refer nsBaseWidget::mTextEventDispatcher makes it return pseudo IME context if TextInputProcessor has input transaction. Therefore, IMEStateManager becomes always removes TextComposition from the array when every composition ends. MozReview-Commit-ID: H1PCtPjBYJR
7e60e86dd8d84d2b7d296404b622bb22045d4cfe: Bug 1371142 - Confirm that the page loaded is about:blank before continuing with the test. r=Gijs
Jared Wein <jwein@mozilla.com> - Wed, 18 Jul 2018 15:40:37 -0400 - rev 427210
Push 34296 by rgurzau@mozilla.com at Thu, 19 Jul 2018 09:52:36 +0000
Bug 1371142 - Confirm that the page loaded is about:blank before continuing with the test. r=Gijs This matches the behavior that is implemented in subdialogs.js where the load event handler is not removed until the new location is about:blank. MozReview-Commit-ID: FZHW6Z63M2M
0b41f0b2c5b706fd83ed5011df02c82ab2d0e7f5: Bug 1476158 - Enable dom.animations-api.core.enabled on beta/release; r=bz
Brian Birtles <birtles@gmail.com> - Wed, 18 Jul 2018 10:46:38 +0900 - rev 427209
Push 34296 by rgurzau@mozilla.com at Thu, 19 Jul 2018 09:52:36 +0000
Bug 1476158 - Enable dom.animations-api.core.enabled on beta/release; r=bz Intent to ship: https://groups.google.com/forum/#!topic/mozilla.dev.platform/fcFctnUjs7A MozReview-Commit-ID: CMMUWvxSm1T
32f324bf03c0eb39a7b463f49e1fd21c266faff9: Bug 1476158 - Guard CSSAnimation and CSSTransition interfaces behind getAnimations() pref; r=bz
Brian Birtles <birtles@gmail.com> - Wed, 18 Jul 2018 10:32:33 +0900 - rev 427208
Push 34296 by rgurzau@mozilla.com at Thu, 19 Jul 2018 09:52:36 +0000
Bug 1476158 - Guard CSSAnimation and CSSTransition interfaces behind getAnimations() pref; r=bz The CSSAnimation and CSSTransition interfaces are only needed to represent CSS animations and CSS transitions returned by the {Document,Element}.getAnimations() API. Bug 1471814 introduced the dom.animations-api.getAnimations.enabled pref but neglected to guard the CSSAnimation and CSSTransition interfaces behind this pref, leaving them guarded by the dom.animations-api.core.enabled pref instead. This patch updates the pref used to guard these interfaces so that when we turn on the dom.animations-api.core.enabled pref by default we don't also end up shipping these interfaces. MozReview-Commit-ID: GjfvOltxlJy
a3b5c278794cea0fb05eb374f190a74fbd6f50d6: Bug 1476174 - Fix-up the change from bug 1474024 to avoid creating lto object files in installed locations. r=ted
Mike Hommey <mh+mozilla@glandium.org> - Tue, 17 Jul 2018 11:29:49 +0900 - rev 427207
Push 34296 by rgurzau@mozilla.com at Thu, 19 Jul 2018 09:52:36 +0000
Bug 1476174 - Fix-up the change from bug 1474024 to avoid creating lto object files in installed locations. r=ted
5351f1299717c5a09cc39ee149c1b1a53fac04b8: Bug 1456919 - Shuffle fds correctly in process_util_mac. r=erahm
Jed Davis <jld@mozilla.com> - Fri, 13 Jul 2018 15:16:48 -0600 - rev 427206
Push 34296 by rgurzau@mozilla.com at Thu, 19 Jul 2018 09:52:36 +0000
Bug 1456919 - Shuffle fds correctly in process_util_mac. r=erahm MozReview-Commit-ID: K17Bn44NU48
99011a1e3da55e8f58054e6646cd10fab9e590b9: Bug 1475382 - Turn off async content process launching, pending better error handling. r=spohl
Jed Davis <jld@mozilla.com> - Fri, 13 Jul 2018 15:20:25 -0600 - rev 427205
Push 34296 by rgurzau@mozilla.com at Thu, 19 Jul 2018 09:52:36 +0000
Bug 1475382 - Turn off async content process launching, pending better error handling. r=spohl At the moment this isn't actually async because we immediately require the pid and block on launch anyway. It also crashes the entire browser on otherwise recoverable launch errors, because code that wants the pid isn't set up to handle that operation failing. MozReview-Commit-ID: 5favGu34QCv
7c10f1db88f01d23aa1a9406f6a7d9b295feaa42: Bug 1475382 - Remove debugging crashes added in bug 1461459. r=spohl
Jed Davis <jld@mozilla.com> - Fri, 13 Jul 2018 15:18:03 -0600 - rev 427204
Push 34296 by rgurzau@mozilla.com at Thu, 19 Jul 2018 09:52:36 +0000
Bug 1475382 - Remove debugging crashes added in bug 1461459. r=spohl These are no longer providing useful information. There are still a noticeable number of failures on Windows, but we've narrowed them down to within SandboxBroker::LaunchApp. MozReview-Commit-ID: 9srWLNZq1Wo
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip