Issue in nsTreeBodyFrame::GetImage
I was styling a xul tree cell with
treechildren::-moz-tree-image(richCol) {
list-style-image:
url(data:image/png;base64,iVBORw0KGgoNSUhEUgAAARQAAABgCAYAAADctI0aAAAITElEQVR4nO2dy5HbOhBFGcvEoUC81aaZgbfMwlVMgysHoRC8Zhp6iwfQl80GCOpjSVPnVLFq+AHQANEXDdCCuw4AAD6Nvu8vZjb863LNbDSz6V+XCwBP5F5BMbOTmV3laBIJBAWU1A+vZnbt+/6i98xsqvUvM5t9mij9ng1mNkg5c+Xe1cxOrfn1fX8u1TUq66O5R1CiBktCsZsfggIZM5tcH5rNbEx/jyoWyQGHfC8LUElQzGzIDlyzoe/7sz6T0kx6L4tI6vdVEch2VQRlrKX/WO4UlCalLqRFUCBE+0aKPlYDVhDBbK7JvWuOonfKnNTJVWDS37O71xRVvJ2gaLjnlFrDwNldn1wIqS/Eh26L4tfyzY0gyjvUwsyU5qzlOPsRFAhR5/aDVuTMJUFJ+QwtghINrFp2jlhkit80CDdOeW4alA9TUsLkjKM7z4o+aSWyuEh+GrqtGqeWrw8b9wQh562NqWEkggIRfjpxq6D0fX/O1x4hKOIrmzWenfpsBMXb3hrt3I1Wwl2ffZQhjTepo+oL8GFdur80ZC1fH6bVwsx83wuGswVBgRV+wOu62wUl9eWVGMi9TRReExS/vqIiYDuLtXuCEtXx6chon0VjLhl5r6CU8g0E5VRrCAQFjpAdM7i+WUPx/cYLSuDkOkDW/MavoRT9plUE3kpQ7P91ijx1WVQ2VVDDwkFEoSYoq5cmI8Kwl2+0kJSV3l0bTeatwZRnlOcQFKh+NQnEYuOgDdFyy5Qn+sqjfdUvyu5+hi7Z69dCj0yh7sZNQ5aQzC3sTPJ8UVDk/jKd8aFeKd/SynQwGmxWygt2IijQdd0yQvvD973oA8IYRCDR4uyuoAT5+ShocmVVI4p
adOR85vv8GxQAAICX8rvrumvXdT+De9d0tP6w6Ed6/k86P0kez+KPlJGPX08sr+u67kvK+krXjrYVwLfkUwUllxUdv59QnqL1QlAAhE8UFM33T3D/2YISgaAAdMcFRcN9Hw20CsrPSh5HbI7ExKN1+N2tIwtflyhdZCNTHoAC6mSlIzuJd0C/ZtEiKKXyWsQhk9P8OPCsX2uJ7Mj12KsnggJQ4Iig/Oq20Ux21K9uX1D0XB3viEBEz0cCcHLPZjHQ6CjXI9erJGpf7j6CAlDgyJQn+qKiz+wJir+fyQ7d+nXmFkHJ59GCamRXSWh9eQgKgPCJgpLtiNZeHiEo2Z5IsPw5ggIgHBGU2rNdd9uUR52zdcqjn4y9CD1CUHI9sz06TfI2IygAwhFBUWfU45GLsn69okSOImoR014d9gQlH3quNiIoAI6jn40jUclpWz8bezGIPj23TH9KAqeRzq1rKCp0THkAPpQ8vcAxAeBucsQE8BrMbDSzKbrX9/3FzIYHlDGb2bXv+/O9eb0jZjaX6mZmJzO7mtnN//q47/uzmc0H7Nlt6/Rux1ttasj77n4DH8izBaWW/3fhuwqKmQ3J9nw09QUE5cOpdeiGtM8WlOlZI+G7oO1/1PlbeFKeVUFJ7+0apNkVRgTlw3lnQXlmaP0ufDdBubc8BOVF5FEghaiX6LoPNdN6xJiu++eu7rl8fZLrJ5+mVVBceasOF9nrbAh/dCh1WZ7JoXbQVpPel+Mk12eXZ+g0Zjb2fX9JdVzK1vMsEmY2uPdzcuXOyQm9XVN+ttJWY+H6kqbm4L4eks9J0mudLnJtdO8o12c3qvTvTZ+vCUp+tvZu4AZKnSS/ZDk/uc49B868ilBSB1udi5NHArUrKMku7fxLZKPpfb1qI2FyQBW7xXGTXWrn1cxOfd+f1bm1PHHoUc8LZY+uXSd3
PootTYIS1d8LSsmRshA6++Yoz1o9tK1S2ovaLu12sa2ITHKvGGFE7ar9ak9QInvgTqRT+hezmb7oiOEdzaexOALJo8LgX6Y1TnncSBZFVavR2eVRCq0vgZ2LOIhDr8Qrqp/YEEVOm3m/CoYvL9l2jmxxbXxIUKL2j9J421silCidFzNX5uq9qG1709RIMPQdNQjKt/za9xbY3whkGZkfISiFsu4SlMqXjGXa5MtvEJTaSJgdQ+tXDMcRlHW6WwUlascgLYLyTqQXuBEBK0x5tPNGgqLXzE1j7O9c/uRfqIqBxwnK5Owa0uFD+rFVUIJnz66TTz5kt7+RUG6Pk63XVh4uKOlvLXO0uqBoe+i7ze9S35UOFKspj0QMNwmK5Kt9YUx5FgVF6rTKN3/lye/AlyltgKC8AltPI0qLn14AIkFZFsjkWmlR1y8cNn/lcVOUqXS9VVB8XYMOfPb2+/oGIvdwQfF2yt8bQcnn8pwX3NWUNLB1U697BMXZ452+KChBnX0/9Iuyvp8gKADwAEr/GvQFdty9OxkAvJh3cWIEBeAbcIsTR78P8b9JucEOBAXg00FQACDaDKn4q2CXLtpkKHTi6Ne8wS+Oa1tJluzb2C7XBl8mADyZws/Xly355LpusOT3S1ntD6KkKGS1T0ppIyB/39vgNhza7Ouh1922APxcHeDZBFHCZs+JaP+RaFqyN82IoozWKU8UKVlhD5VoyrO3KxsAPIBoQxu9p+KiDnxEUCze7KhZUJyQ+V3lEBSAdyGaNkSbMqfzWRx7clOKsSQobgvHVXl+q0IpZ/W8L0fTui0sBwQF4IXIFoerhdVgwXP5Lw7S/VnuFQXFTVdm79ySTxar1VaSO1s7qu1+bQVBAQAAeB3/AbetLugtT8G5AElFTkSuQmCC);
}
But when the first time it calling to GetImage, it's always failed, after a
period of times, it's succeed, so I need to know why this happening, is that
designed intently or just a bug?
nsresult
nsTreeBodyFrame::GetImage(int32_t aRowIndex, nsTreeColumn* aCol, bool
aUseContext,
nsStyleContext* aStyleContext, bool
aAllowImageRegions, imgIContainer** aResult)
{
*aResult = nullptr;
nsAutoString imageSrc;
mView-GetImageSrc(aRowIndex, aCol, imageSrc);
nsRefPtrimgRequestProxy styleRequest;
if (!aUseContext !imageSrc.IsEmpty()) {
aAllowImageRegions = false;
}
else {
// Obtain the URL from the style context.
aAllowImageRegions = true;
styleRequest = aStyleContext-StyleList()-GetListStyleImage();
if (!styleRequest)
return NS_OK;
nsCOMPtrnsIURI uri;
styleRequest-GetURI(getter_AddRefs(uri));
nsAutoCString spec;
uri-GetSpec(spec);
CopyUTF8toUTF16(spec, imageSrc);
}
// Look the image up in our cache.
nsTreeImageCacheEntry entry;
if (mImageCache.Get(imageSrc, entry)) {
// Find out if the image has loaded.
uint32_t status;
imgIRequest *imgReq = entry.request;
imgReq-GetImageStatus(status);
imgReq-GetImage(aResult); // We hand back the image here. The GetImage
call addrefs *aResult.
bool animated = true; // Assuming animated is the safe option
// We can only call GetAnimated if we're decoded
if (*aResult (status imgIRequest::STATUS_DECODE_COMPLETE))
(*aResult)-GetAnimated(animated);
if ((!(status imgIRequest::STATUS_LOAD_COMPLETE)) || animated) {
// We either aren't done loading, or we're animating. Add our row as a
listener for invalidations.
nsCOMPtrimgINotificationObserver obs;
imgReq-GetNotificationObserver(getter_AddRefs(obs));
if (obs) {
static_castnsTreeImageListener* (obs.get())-AddCell(aRowIndex, aCol);
}
return NS_OK;
}
}
if
How to retrieve imgIContainer synchronously by imgRequestProxy ?
I want to draw images in a dynamic way, and the image are transparent and have backgrounds, so I don't want the background draw and the image draw are separate so that the I will see flicking. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How to retrieve imgIContainer synchronously by imgRequestProxy ?
In other works, is there any way to decode a local image to nsCOMPtrimgIContainer synchronously, the image is a url like url(data:image/png;base64,iVBORw0KGgoNSUhEUgAAARQAAABgCAYAAADctI0aAAAITElEQVR4nO2dy5HbOhBFGcvEoUC81aaZgbfMwlVMgysHoRC8Zhp6iw...) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25
On 17:37, Wed, 20 Aug, Jonas Sicking wrote: On Wed, Aug 20, 2014 at 4:24 PM, Jeff Gilbert jgilb...@mozilla.com wrote: I have been asked in the past if we really need to run WebGL tests on Android, if they have coverage on Desktop platforms. And then again later, why B2G if we have Android. There seems to be enough belief in test-once-run-everywhere that I feel the need to *firmly* establish that this is not acceptable, at least for the code I work with. I'm happy I'm not alone in this. I'm a firm believer that we ultimately need to run basically all combinations of tests and platforms before allowing code to reach mozilla-central. There's lots of platform specific code paths, and it's hard to track which tests trigger them, and which don't. I think we can agree on this. However, not running all tests on all platforms per push on mozilla-inbound (or other branch) doesn't mean that they won't be run on mozilla-central, or even on mozilla-inbound prior to merging. I'm a firm believer that running all tests for all platforms for all pushes is a waste of our infrastructure and human resources. I think the gap we need to figure out how to fill is between getting per-push efficiency and full test coverage prior to merging. It would however be really cool if we were able to pull data on which tests tend to fail in a way that affects all platforms, and which ones tend to fail on one platform only. If we combine this with the ability of having tbpl (or treeherder) fill in the blanks whenever a test fails, it seems like we could run many of our tests only one one platform for most checkins to mozilla-inbound. There are dozens of really interesting approaches we could take here. Skipping every nth debug test run is one of the simplest, and I hope we can learn a lot from the experiment. Cheers, Chris signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25
-- - Milan On Aug 21, 2014, at 10:12 , Chris AtLee cat...@mozilla.com wrote: On 17:37, Wed, 20 Aug, Jonas Sicking wrote: On Wed, Aug 20, 2014 at 4:24 PM, Jeff Gilbert jgilb...@mozilla.com wrote: I have been asked in the past if we really need to run WebGL tests on Android, if they have coverage on Desktop platforms. And then again later, why B2G if we have Android. There seems to be enough belief in test-once-run-everywhere that I feel the need to *firmly* establish that this is not acceptable, at least for the code I work with. I'm happy I'm not alone in this. I'm a firm believer that we ultimately need to run basically all combinations of tests and platforms before allowing code to reach mozilla-central. There's lots of platform specific code paths, and it's hard to track which tests trigger them, and which don't. I think we can agree on this. However, not running all tests on all platforms per push on mozilla-inbound (or other branch) doesn't mean that they won't be run on mozilla-central, or even on mozilla-inbound prior to merging. I'm a firm believer that running all tests for all platforms for all pushes is a waste of our infrastructure and human resources. I think the gap we need to figure out how to fill is between getting per-push efficiency and full test coverage prior to merging. The cost of not catching a problem with a test and letting the code land is huge. I only know this for the graphics team, but to Ehsan’s and Jonas’ point, I’m sure it’s not specific to graphics. Now, one is preventative cost (tests), one is treatment cost (fixing issues that snuck through), so it’s sometimes difficult to compare, and we are not alone in first going after the preventative costs, but it’s a big mistake to do so. Now, if we need to save some electricity or cash, I understand that as well, and it eventually translates to the cost to the company the same as people’s time. If we can do something by skipping every n-th debug run, sure, let’s try it. We have to make sure that a failure on a debug test run triggers us going back and re-running the skipped ones, so that we don’t have any gaps in the tests where something may have gone wrong. It would however be really cool if we were able to pull data on which tests tend to fail in a way that affects all platforms, and which ones tend to fail on one platform only. If we combine this with the ability of having tbpl (or treeherder) fill in the blanks whenever a test fails, it seems like we could run many of our tests only one one platform for most checkins to mozilla-inbound. There are dozens of really interesting approaches we could take here. Skipping every nth debug test run is one of the simplest, and I hope we can learn a lot from the experiment. Cheers, Chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
How to implement XPCOM API void render(in long width, in long height, out nsIImageLoadingContent imageContent); in Javascript?
I want to pass a out parameter with render, but don't know how to do that. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25
I think much of the pushback in this thread is due to a misunderstanding of some combination of: * our current buildbot scheduling * the proposal * how trees are sheriffed and merged To clarify: 1) We already have coalescing [*] of jobs on all trees apart from try. 2) This coalescing means that all jobs are still run at some point, but just may not run on every push. 3) When failures are detected, coalescing means that regression ranges are larger and so sometimes result in longer tree integration repo closures, whilst the sheriffs force trigger jobs on the revisions that did not originally run them. 4) When merging into mozilla-central, sheriffs ensure that all jobs are green - including those that got coalesced and those that are only scheduled periodically (eg non-unified PGO builds are only run every 3 hours). (This is a fairly manual process currently, but better tooling should be possible with treeherder). 5) This proposal does not mean debug-only issues are somehow not worth acting on or that they'll end up shipped/on mozilla-central, thanks to #4. 6) This proposal is purely trying to make existing coalescing (#1/#2) more intelligent, to ensure that we expend the finite amount of machine time we have at present on the most appropriate jobs at each point, in order to reduce the impact of #3. Fwiw I'm on the fence as to whether the algorithm suggested in this proposal is the most effective way to aid with #3 - however it's worth trying to find out. Best wishes, Ed [*] Collapsing of pending jobs of the same type, when the queue size is greater than 1. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: Disabling auto-play videos on mobile networks/devices?
Summary: We've had some complaints at times about videos autoplaying on mobile devices when sites request autoplay. We should be more mindful of users and try to avoid using data if they don't want it. Sites should be doing this for us, but we've encountered pages where that is not the case. I'm proposing that we at least disable this if the audio/video has to be pulled over a (paid?) mobile network. It may, because of the context that phones are used, be something we'd disable on mobile in general. i.e. The bug report mentions someone using their phone in a quiet setting at home. Theres also some power usage concerns that this would help with. The spec allows this explicitly Authors are urged to use the autoplay attribute rather than using script to trigger automatic playback, as this allows the user to override the automatic playback when it is not desired. Sites (like games) that want to override this could still use scripting to autoplay (and probably already do). Link to standard: http://www.w3.org/TR/html5/embedded-content-0.html#attr-media-autoplay Platform coverage: Where will this be available? Android, Firefox OS Estimated or target release: Aiming for Firefox 35. Preference behind which this will be implemented: Not sure. We already have a boolean media.autoplay.enabled. I think the best thing would probably be to make it a tri-state.pref. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25
On 8/21/14 9:35 AM, Ed Morley wrote: 4) When merging into mozilla-central, sheriffs ensure that all jobs are green - including those that got coalesced and those that are only scheduled periodically (eg non-unified PGO builds are only run every 3 hours). (This is a fairly manual process currently, but better tooling should be possible with treeherder). To ensure that all code landing in mozilla-central has passed debug tests, sheriffs could merge only from the mozilla-inbound changesets that ran the debug tests. chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25
Thanks Ed. To paraphrase, no test coverage is being lost here, we're just being a little more deliberate with job coalescing. All tests will be run on all platforms (including debug tests) on a commit before a merge to m-c. Jonathan On 8/21/2014 9:35 AM, Ed Morley wrote: I think much of the pushback in this thread is due to a misunderstanding of some combination of: * our current buildbot scheduling * the proposal * how trees are sheriffed and merged To clarify: 1) We already have coalescing [*] of jobs on all trees apart from try. 2) This coalescing means that all jobs are still run at some point, but just may not run on every push. 3) When failures are detected, coalescing means that regression ranges are larger and so sometimes result in longer tree integration repo closures, whilst the sheriffs force trigger jobs on the revisions that did not originally run them. 4) When merging into mozilla-central, sheriffs ensure that all jobs are green - including those that got coalesced and those that are only scheduled periodically (eg non-unified PGO builds are only run every 3 hours). (This is a fairly manual process currently, but better tooling should be possible with treeherder). 5) This proposal does not mean debug-only issues are somehow not worth acting on or that they'll end up shipped/on mozilla-central, thanks to #4. 6) This proposal is purely trying to make existing coalescing (#1/#2) more intelligent, to ensure that we expend the finite amount of machine time we have at present on the most appropriate jobs at each point, in order to reduce the impact of #3. Fwiw I'm on the fence as to whether the algorithm suggested in this proposal is the most effective way to aid with #3 - however it's worth trying to find out. Best wishes, Ed [*] Collapsing of pending jobs of the same type, when the queue size is greater than 1. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Disabling auto-play videos on mobile networks/devices?
Hi Wes, On 2014-08-21, 10:29 AM, Wesley Johnston wrote: Summary: We've had some complaints at times about videos autoplaying on mobile devices when sites request autoplay. We should be more mindful of users and try to avoid using data if they don't want it. Sites should be doing this for us, but we've encountered pages where that is not the case. I'm proposing that we at least disable this if the audio/video has to be pulled over a (paid?) mobile network. It may, because of the context that phones are used, be something we'd disable on mobile in general. i.e. The bug report mentions someone using their phone in a quiet setting at home. Theres also some power usage concerns that this would help with. The spec allows this explicitly Authors are urged to use the autoplay attribute rather than using script to trigger automatic playback, as this allows the user to override the automatic playback when it is not desired. Sites (like games) that want to override this could still use scripting to autoplay (and probably already do). In general, I'm in favour of not autoplaying at all on mobile devices. Link to standard: http://www.w3.org/TR/html5/embedded-content-0.html#attr-media-autoplay Platform coverage: Where will this be available? Android, Firefox OS Estimated or target release: Aiming for Firefox 35. Preference behind which this will be implemented: Not sure. We already have a boolean media.autoplay.enabled. I think the best thing would probably be to make it a tri-state.pref. Why is it not sufficient to just set media.autoplay.enabled=false on mobile platforms? (MXR suggests autoplay is enabled on all platforms.) Is the concern that disabling autoplay too widely will lead to widespread scripted-autoplay, reducing user control yet further? Can you be explicit about the three states of this proposed tri-state pref? Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25
Hey Martin, This is a good idea, and we've been thinking about approaches like this. Basically, the idea is to run tests that (nearly) always pass less often. There are currently some tests that fit into this category, like dom level0,1,2 tests in mochitest-plain, and those are time-consuming to run. Your idea takes this a step further, by identifying tests that sometimes fail, correlating those with code changes, and ensuring those get run. Both of these require some tooling to implement, so we're experimenting initially with approaches that we can get nearly for free, like running some tests only every other commit, and letting sheriffs trigger the missing tests in case a failure occurs. The ultimate solution may blend a bit of both approaches, and will have to balance implementation cost with the gain we get from the related reduction in slave load. Jonathan On 8/21/2014 10:07 AM, Martin Thomson wrote: On 20/08/14 17:37, Jonas Sicking wrote: It would however be really cool if we were able to pull data on which tests tend to fail in a way that affects all platforms, and which ones tend to fail on one platform only. Here's a potential project that might help. For all of the trees (probably try especially), look at the checkins and for each directory affected build up a probability of failure for each of the tests. You would have to find which commits were on m-c at the time of the run to set the baseline for the checkin; and intermittent failures would add a certain noise floor. The basic idea though is that the information would be very simple to use: For each directory touched in a commit, find all the tests that cross a certain failure threshold across the assembled dataset and ensure that those test groups are run. And this would need to include prerequisites, like builds for the given runs. You would, of course, include builds as tests. Setting the threshold might take some tuning, because failure rates will vary across different test groups. I keep hearing bad things about certain ones, for instance and build failures are far less common than test failures on the whole, naturally. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Disabling auto-play videos on mobile networks/devices?
In general, I'm in favour of not autoplaying at all on mobile devices. I think I was just trying to address the spec's statement of overriding when not desired. I don't want to punish sites that are reading that and trying to be good citizens. For instance, video elements are actually a good solution if you want an animated background on a site, and provide good fallbacks when they're disabled. I want to at least discuss making a good faith effort to only disable it when necessary. But I won't argue that we can have a perfect heuristic for that either (I'm not sure how we know if you're in a library). Maybe phone is the best we can do for users. Maybe we need to discuss disabling audio (from audio or video elements) and video separately? Is the concern that disabling autoplay too widely will lead to widespread scripted-autoplay, reducing user control yet further? My concern is that this may break sites without providing much feedback to them about why. I'd like to minimize bustage/confusion for developers, as well as doing our best to respect their requests. Can you be explicit about the three states of this proposed tri-state pref? I was thinking something like: Enabled - Always works Disabled - Never works Dynamic - Up to UA. Technically, I'd be fine putting this behind Enabled, but if we want the dynamic behaviour behind a pref, it seemed simpler to add it here than to start dealing with combinatorials of different prefs. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25
What will be the policy if a test fails and it's unclear which push caused the regression? Is it the sheriff's job, or the people who pushed's job to figure out which push was the culprit and make sure that that push gets backed out? I.e. if 4 pushes land between two testruns, and we see a regression, will the 4 pushes be backed out? Or will sheriffs run the missing tests and only back out the offending push? / Jonas On Thu, Aug 21, 2014 at 10:50 AM, Jonathan Griffin jgrif...@mozilla.com wrote: Thanks Ed. To paraphrase, no test coverage is being lost here, we're just being a little more deliberate with job coalescing. All tests will be run on all platforms (including debug tests) on a commit before a merge to m-c. Jonathan On 8/21/2014 9:35 AM, Ed Morley wrote: I think much of the pushback in this thread is due to a misunderstanding of some combination of: * our current buildbot scheduling * the proposal * how trees are sheriffed and merged To clarify: 1) We already have coalescing [*] of jobs on all trees apart from try. 2) This coalescing means that all jobs are still run at some point, but just may not run on every push. 3) When failures are detected, coalescing means that regression ranges are larger and so sometimes result in longer tree integration repo closures, whilst the sheriffs force trigger jobs on the revisions that did not originally run them. 4) When merging into mozilla-central, sheriffs ensure that all jobs are green - including those that got coalesced and those that are only scheduled periodically (eg non-unified PGO builds are only run every 3 hours). (This is a fairly manual process currently, but better tooling should be possible with treeherder). 5) This proposal does not mean debug-only issues are somehow not worth acting on or that they'll end up shipped/on mozilla-central, thanks to #4. 6) This proposal is purely trying to make existing coalescing (#1/#2) more intelligent, to ensure that we expend the finite amount of machine time we have at present on the most appropriate jobs at each point, in order to reduce the impact of #3. Fwiw I'm on the fence as to whether the algorithm suggested in this proposal is the most effective way to aid with #3 - however it's worth trying to find out. Best wishes, Ed [*] Collapsing of pending jobs of the same type, when the queue size is greater than 1. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Disabling auto-play videos on mobile networks/devices?
In general I think this sounds like a good idea. Not honoring autoplay when on a mobile connection sounds good. I'm unsure what the best behavior is on a mobile device when on a wifi connection, so I don't feel strongly either way there. On Thu, Aug 21, 2014 at 11:16 AM, Wesley Johnston wjohns...@mozilla.com wrote: Can you be explicit about the three states of this proposed tri-state pref? I was thinking something like: Enabled - Always works Disabled - Never works Dynamic - Up to UA. I don't understand this. We are the UA, so what does dynamic actually mean? Making it a tristate for always, never and only on wifi would make sense to me if that's what you mean? / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25
On Thu, Aug 21, 2014 at 03:03:30PM -0700, Jonas Sicking wrote: What will be the policy if a test fails and it's unclear which push caused the regression? You may have missed the main point that it's not What will, but What is. It *is* already the case that tests are skipped. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25
It will be handled just like coalesced jobs today: sheriffs will backfill the missing data, and backout only the offender. An illustration might help. Today we might have something like this, for a given job: linux64-debug win7-debug osx8-debug commit 1 pass pass pass commit 2 pass pass pass commit 3 pass fail pass commit 4 pass fail pass In this case (assuming the two failures are the same), it's easy for sheriffs to see that commit 3 is the culprit and the one that needs to be backed out. During the experiment, we might see something like this: linux64-debug win7-debug osx8-debug commit 1 pass pass pass commit 2 pass not runnot run commit 3 pass fail pass commit 4 pass not runnot run Here, it isn't obvious whether the problem is caused by commit 2 or commit 3. (This situation already occurs today because of random coalescing.) In this case, the sheriffs will backfill missing test data, so we might see: linux64-debug win7-debug osx8-debug commit 1 pass pass pass commit 2 pass pass not run commit 3 pass fail pass commit 4 pass fail not run ...and then they have enough data to determine that commit 3 (and not commit 2) is to blame, and can take the appropriate action. In summary, the sheriffs won't be backing out extra commits because of the coalescing, and it remains the sheriffs' job to backfill tests when they determine they need to do so in order to bisect a failure. We aren't placing any extra burden on developers with this experiment, and part of the reason for this experiment is to determine how much of an extra burden this is for the sheriffs. Jonathan On 8/21/2014 3:03 PM, Jonas Sicking wrote: What will be the policy if a test fails and it's unclear which push caused the regression? Is it the sheriff's job, or the people who pushed's job to figure out which push was the culprit and make sure that that push gets backed out? I.e. if 4 pushes land between two testruns, and we see a regression, will the 4 pushes be backed out? Or will sheriffs run the missing tests and only back out the offending push? / Jonas On Thu, Aug 21, 2014 at 10:50 AM, Jonathan Griffin jgrif...@mozilla.com wrote: Thanks Ed. To paraphrase, no test coverage is being lost here, we're just being a little more deliberate with job coalescing. All tests will be run on all platforms (including debug tests) on a commit before a merge to m-c. Jonathan On 8/21/2014 9:35 AM, Ed Morley wrote: I think much of the pushback in this thread is due to a misunderstanding of some combination of: * our current buildbot scheduling * the proposal * how trees are sheriffed and merged To clarify: 1) We already have coalescing [*] of jobs on all trees apart from try. 2) This coalescing means that all jobs are still run at some point, but just may not run on every push. 3) When failures are detected, coalescing means that regression ranges are larger and so sometimes result in longer tree integration repo closures, whilst the sheriffs force trigger jobs on the revisions that did not originally run them. 4) When merging into mozilla-central, sheriffs ensure that all jobs are green - including those that got coalesced and those that are only scheduled periodically (eg non-unified PGO builds are only run every 3 hours). (This is a fairly manual process currently, but better tooling should be possible with treeherder). 5) This proposal does not mean debug-only issues are somehow not worth acting on or that they'll end up shipped/on mozilla-central, thanks to #4. 6) This proposal is purely trying to make existing coalescing (#1/#2) more intelligent, to ensure that we expend the finite amount of machine time we have at present on the most appropriate jobs at each point, in order to reduce the impact of #3. Fwiw I'm on the fence as to whether the algorithm suggested in this proposal is the most effective way to aid with #3 - however it's worth trying to find out. Best wishes, Ed [*] Collapsing of pending jobs of the same type, when the queue size is greater than 1. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25
On Thu, Aug 21, 2014 at 3:21 PM, Jonathan Griffin jgrif...@mozilla.com wrote: In summary, the sheriffs won't be backing out extra commits because of the coalescing, and it remains the sheriffs' job to backfill tests when they determine they need to do so in order to bisect a failure. We aren't placing any extra burden on developers with this experiment, and part of the reason for this experiment is to determine how much of an extra burden this is for the sheriffs. As long as sheriffs are in support of this (which it sounds like is the case), then this sounds awesome to me. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
