Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
23464005:
Explicitly register each key system. (Closed)
|
Created:
7 years, 3 months ago by ddorwin Modified:
7 years, 3 months ago CC:
chromium-reviews, joi+watch-content_chromium.org, feature-media-reviews_chromium.org, jam, darin-cc_chromium.org Base URL:
svn://svn.chromium.org/chrome/trunk/src Visibility:
Public. |
DescriptionExplicitly register each key system.
Key systems are now explicitly added rather than loaded from arrays of structs.
This is in preparation for moving knowledge of key systems and registration out
of content/.
BUG=224793
TEST=exsting content_unittests
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=220664
Patch Set 1 #
Total comments: 4
Patch Set 2 : Removed AddParentKeySystem #Patch Set 3 : rebase only #
Total comments: 52
Patch Set 4 : review feedback #
Total comments: 1
Patch Set 5 : xhwang review updates #Patch Set 6 : Do not crash when DCHECK is off (should only be possible in tests) #Patch Set 7 : Fix target-specific build failures resulting from previous patch. Use DLOG_IF to avoid DCHECK_ALWAY… #Patch Set 8 : Fix target-specific build failures resulting from previous patch. #Patch Set 9 : Fix Clear Key on Android #
Messages
Total messages: 25 (0 generated)
(PTAL at the interfaces, but don't do a full review yet.) Initialization may be slightly slower, but this is a lot better overall. In addition to allowing us to move knowledge of key systems outside content, it avoids checking for compatibility on every call. Looking ahead to having chrome/ register key systems, we can either (1) allow chrome/ to call content/ whenever it wants to or (2) have content/ (KeySystems) ask ContentClient to register key systems when it needs to initialize itself. #1 has the advantage of allowing late additions (i.e. component installer). #2 avoids initializing, with potential IPCs, unless necessary, but could add a delay to the first canPlayType() call. (Note: we would initialize all key systems at once.) Assuming we want to do #2, it should probably look something like ContentClient::AddPepperPlugins(). This means I need to define a complex struct and replace the three Add*() functions in key_systems.h with a single call out to ContentClient. I like the separation of the three functions I have currently, but that seems too noisy for ContentClient.
I like this! Does (1) mean there's a window of time where there are no key systems provided by chrome/? Or could chrome/ guarantee it would provide the key systems before the first time it's required? I'm OK with (2) as well, but if it uses IPCs then having #s on the perf impact would be nice as this would be in the critical path to video startup time. https://codereview.chromium.org/23464005/diff/1/content/renderer/media/crypto... File content/renderer/media/crypto/key_systems.h (right): https://codereview.chromium.org/23464005/diff/1/content/renderer/media/crypto... content/renderer/media/crypto/key_systems.h:45: bool use_aes_decryptor); what's this thing for?
On 2013/08/27 17:20:36, scherkus wrote: > I like this! > > Does (1) mean there's a window of time where there are no key systems provided > by chrome/? Or could chrome/ guarantee it would provide the key systems before > the first time it's required? I would only use this option if there was no such window. I assumed this would happen during renderer initialization. I'm not sure which interface in content/public/renderer/ these would be added to. content/renderer/renderer_main.cc might have to call out to a client to start the process anyway. > > I'm OK with (2) as well, but if it uses IPCs then having #s on the perf impact > would be nice as this would be in the critical path to video startup time. Wouldn't this be better than impacting the startup performance of every renderer, though? > > https://codereview.chromium.org/23464005/diff/1/content/renderer/media/crypto... > File content/renderer/media/crypto/key_systems.h (right): > > https://codereview.chromium.org/23464005/diff/1/content/renderer/media/crypto... > content/renderer/media/crypto/key_systems.h:45: bool use_aes_decryptor); > what's this thing for?
https://codereview.chromium.org/23464005/diff/1/content/renderer/media/crypto... File content/renderer/media/crypto/key_systems.h (right): https://codereview.chromium.org/23464005/diff/1/content/renderer/media/crypto... content/renderer/media/crypto/key_systems.h:45: bool use_aes_decryptor); On 2013/08/27 17:20:37, scherkus wrote: > what's this thing for? It's used to answer to CanUseAesDecryptor(). We could assume this if the pepper_type/uuid values are "empty". With this API signature, it also serves to solve the "last parameter after ifdef" issue.
On 2013/08/27 18:02:28, ddorwin wrote: > On 2013/08/27 17:20:36, scherkus wrote: > > I like this! > > > > Does (1) mean there's a window of time where there are no key systems provided > > by chrome/? Or could chrome/ guarantee it would provide the key systems before > > the first time it's required? > > I would only use this option if there was no such window. I assumed this would > happen during renderer initialization. > > I'm not sure which interface in content/public/renderer/ these would be added > to. content/renderer/renderer_main.cc might have to call out to a client to > start the process anyway. > > > > I'm OK with (2) as well, but if it uses IPCs then having #s on the perf impact > > would be nice as this would be in the critical path to video startup time. > > Wouldn't this be better than impacting the startup performance of every > renderer, though? Indeed it would! Unless you do something like pepper where all the information is passed via the command line flag, but that seems a bit gross :) If we do this ... I think it'd be worth: 1) Doing the IPC 2) Adding UMA 3) Seeing what we get!
Overall it looks good. I just have one question about AddParentKeySystem. I wonder why we need this call explicitly? Given a concrete key system, the list of it's parent key system is determined. Also based on the spec, if we support a concrete key system, then we need to support all the parent key systems. So I wonder why we don't automatically add all parent key systems, or have a run-time check e.g. IsParentKeySystem(concrete_key_system)? https://codereview.chromium.org/23464005/diff/1/content/renderer/media/crypto... File content/renderer/media/crypto/key_systems_info.cc (right): https://codereview.chromium.org/23464005/diff/1/content/renderer/media/crypto... content/renderer/media/crypto/key_systems_info.cc:96: 0x0, 0x0, 0x0, 0x0,0x0, 0x0, 0x0, 0x0, }, space/align
On 2013/08/27 20:58:05, xhwang wrote: > Overall it looks good. I just have one question about AddParentKeySystem. I > wonder why we need this call explicitly? Given a concrete key system, the list > of it's parent key system is determined. Also based on the spec, if we support a > concrete key system, then we need to support all the parent key systems. So I > wonder why we don't automatically add all parent key systems, or have a run-time > check e.g. IsParentKeySystem(concrete_key_system)? This allowed separation of the configuration of a concrete KS and the addition of parents. It also allows multiple parents if we wanted. Otherwise, we'd add a [vector of] string to AddConcreteSupportedKeySystem(). If we go with #2, this will be collapsed anyway. For now, I'll add a single parent string parameter to AddConcreteSupportedKeySystem(). https://codereview.chromium.org/23464005/diff/1/content/renderer/media/crypto... File content/renderer/media/crypto/key_systems_info.cc (right): https://codereview.chromium.org/23464005/diff/1/content/renderer/media/crypto... content/renderer/media/crypto/key_systems_info.cc:96: 0x0, 0x0, 0x0, 0x0,0x0, 0x0, 0x0, 0x0, }, On 2013/08/27 20:58:05, xhwang wrote: > space/align Done. (space)
I removed AddParentKeySystem(). This is now ready for review.
lgtm w/ nits https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... File content/renderer/media/crypto/key_systems.cc (right): https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:36: #endif // defined(ENABLE_PEPPER_CDMS) nit: you can leave off these // comments if you want consider it's 1 line of code (also it's not technically correct given the elifs) here and rest of file https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:264: #if defined(ENABLE_PEPPER_CDMS) de-indent this https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... File content/renderer/media/crypto/key_systems.h (right): https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.h:77: // Returns whether AesDecryptor can be used for the given |key_system|. fix docs https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... File content/renderer/media/crypto/key_systems_info.cc (right): https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems_info.cc:79: defined(WIDEVINE_CDM_CENC_SUPPORT_AVAILABLE) indent by 2 more https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems_info.cc:99: std::string()); any reason why you use std::string() here but "" on line 94? I don't care which one ... but consistency is nice I wonder if this is an appropriate case for string_util's EmptyString() (although historically we've never bothered to use it in media code)
https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... File content/renderer/media/crypto/key_systems.cc (right): https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:36: #endif // defined(ENABLE_PEPPER_CDMS) On 2013/08/29 20:11:47, scherkus wrote: > nit: you can leave off these // comments if you want consider it's 1 line of > code (also it's not technically correct given the elifs) OOC: Really? Chrome code seems to do it all the time with else blocks. > > here and rest of file Done. I also converted some separate blocks to use #elif for consistency. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:264: #if defined(ENABLE_PEPPER_CDMS) On 2013/08/29 20:11:47, scherkus wrote: > de-indent this Done. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... File content/renderer/media/crypto/key_systems.h (right): https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.h:77: // Returns whether AesDecryptor can be used for the given |key_system|. On 2013/08/29 20:11:47, scherkus wrote: > fix docs Done. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... File content/renderer/media/crypto/key_systems_info.cc (right): https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems_info.cc:79: defined(WIDEVINE_CDM_CENC_SUPPORT_AVAILABLE) On 2013/08/29 20:11:47, scherkus wrote: > indent by 2 more Done. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems_info.cc:99: std::string()); On 2013/08/29 20:11:47, scherkus wrote: > any reason why you use std::string() here but "" on line 94? Because I added this one later. :) Done. > > I don't care which one ... but consistency is nice I thought std::string() is preferred - is that correct? > > I wonder if this is an appropriate case for string_util's EmptyString() > (although historically we've never bothered to use it in media code) I don't think so: // There is only one case where you should use these: functions which need to // return a string by reference (e.g. as a class member accessor), and don't // have an empty string to use (e.g. in an error case). These should not be // used as initializers, function arguments, or return values for functions // which return by value or outparam. https://codereview.chromium.org/23464005/diff/32001/content/renderer/media/cr... File content/renderer/media/crypto/key_systems_info.cc (right): https://codereview.chromium.org/23464005/diff/32001/content/renderer/media/cr... content/renderer/media/crypto/key_systems_info.cc:100: kEmptyUuid, Hopefully addressing "extended initializer lists only available with -std=c++11 or -std=gnu++11 [-Werror]"
lgtm % nits https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... File content/renderer/media/crypto/key_systems.cc (right): https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:63: typedef base::hash_set<std::string> CodecMappings; Shall we name this a Set? https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:78: typedef std::map<std::string, KeySystemProperties> KeySystemMappings; nit: rename to KeySystemPropertiesMappings? https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:80: typedef std::map<std::string, std::string> ParentKeySystemMappings; nit: Can we rename all "Mappings" to "Map"? https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:124: << "Key system already registered"; Use IsConcreteSupportedKeySystem()? https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:150: false); fit in one line? https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:154: codecs.insert(mime_type_codecs[j]); Will CodecMappings codecs(mime_type_codecs.begin(), mime_type_codecs.end()); work? https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:160: DCHECK(key_system_iter != key_system_map_.end()); Use IsConcreteSupportedKeySystem()? https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:162: // mime_types_map may not be repeated for a given key system. s/may/must/ ? https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:168: return key_system_map_.find(key_system) != key_system_map_.end(); shall we s/key_system_map_/concrete_key_system_map_/ ? https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:198: if (parent_key_system_iter != parent_key_system_map_.end()) Wrap this into IsParentKeySystem(key_system)? https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:210: mime_type, std::string(), concrete_key_system); use {} since we have multiple lines in the "if" block. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:215: return false; use {} around the "if" block https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:223: key_system_map_.find(concrete_key_system); indent https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:232: key_system_map_.find(concrete_key_system); indent https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:244: key_system_map_.find(concrete_key_system); ditto https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... File content/renderer/media/crypto/key_systems.h (right): https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.h:39: // |key_system| that can be used to check supported types. Add a comment about what if we want to have multiple parent key system? https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.h:54: CONTENT_EXPORT void AddSupportedType(const std::string& key_system, s/key_system/concrete_key_system/ ? https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... File content/renderer/media/crypto/key_systems_info.cc (right): https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems_info.cc:58: static void RegisterWidevine() { I <3 this function! https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems_info.cc:121: #if defined(WIDEVINE_CDM_AVAILABLE) Does it make sense to wrap the above to RegisterClearKey(), and RegisterExternalClearKey()?
https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... File content/renderer/media/crypto/key_systems.cc (right): https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:63: typedef base::hash_set<std::string> CodecMappings; On 2013/08/29 21:45:26, xhwang wrote: > Shall we name this a Set? Separate CL. I'd like to keep as much similar in this CL as possible. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:78: typedef std::map<std::string, KeySystemProperties> KeySystemMappings; On 2013/08/29 21:45:26, xhwang wrote: > nit: rename to KeySystemPropertiesMappings? Ditto. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:80: typedef std::map<std::string, std::string> ParentKeySystemMappings; On 2013/08/29 21:45:26, xhwang wrote: > nit: Can we rename all "Mappings" to "Map"? Ditto. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:124: << "Key system already registered"; On 2013/08/29 21:45:26, xhwang wrote: > Use IsConcreteSupportedKeySystem()? Done. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:150: false); On 2013/08/29 21:45:26, xhwang wrote: > fit in one line? Done. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:154: codecs.insert(mime_type_codecs[j]); On 2013/08/29 21:45:26, xhwang wrote: > Will > CodecMappings codecs(mime_type_codecs.begin(), mime_type_codecs.end()); > work? Done. Thanks. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:160: DCHECK(key_system_iter != key_system_map_.end()); On 2013/08/29 21:45:26, xhwang wrote: > Use IsConcreteSupportedKeySystem()? In this case, we need the iter anyway, so this seems fine. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:162: // mime_types_map may not be repeated for a given key system. On 2013/08/29 21:45:26, xhwang wrote: > s/may/must/ ? Done. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:168: return key_system_map_.find(key_system) != key_system_map_.end(); On 2013/08/29 21:45:26, xhwang wrote: > shall we s/key_system_map_/concrete_key_system_map_/ ? Ditto. (Later) https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:198: if (parent_key_system_iter != parent_key_system_map_.end()) On 2013/08/29 21:45:26, xhwang wrote: > Wrap this into IsParentKeySystem(key_system)? We need the iter anyway. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:210: mime_type, std::string(), concrete_key_system); On 2013/08/29 21:45:26, xhwang wrote: > use {} since we have multiple lines in the "if" block. Done. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:215: return false; On 2013/08/29 21:45:26, xhwang wrote: > use {} around the "if" block Done. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:223: key_system_map_.find(concrete_key_system); On 2013/08/29 21:45:26, xhwang wrote: > indent Done. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:232: key_system_map_.find(concrete_key_system); On 2013/08/29 21:45:26, xhwang wrote: > indent Done. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:244: key_system_map_.find(concrete_key_system); On 2013/08/29 21:45:26, xhwang wrote: > ditto Done. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... File content/renderer/media/crypto/key_systems.h (right): https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.h:39: // |key_system| that can be used to check supported types. On 2013/08/29 21:45:26, xhwang wrote: > Add a comment about what if we want to have multiple parent key system? Done. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.h:54: CONTENT_EXPORT void AddSupportedType(const std::string& key_system, On 2013/08/29 21:45:26, xhwang wrote: > s/key_system/concrete_key_system/ ? Done. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... File content/renderer/media/crypto/key_systems_info.cc (right): https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems_info.cc:58: static void RegisterWidevine() { On 2013/08/29 21:45:26, xhwang wrote: > I <3 this function! Done. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems_info.cc:121: #if defined(WIDEVINE_CDM_AVAILABLE) On 2013/08/29 21:45:26, xhwang wrote: > Does it make sense to wrap the above to RegisterClearKey(), and > RegisterExternalClearKey()? Done. I had considered it and decided not to because it required an extra #ifdef, but I did it now.
thanks! lgtm++
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/ddorwin@chromium.org/23464005/40001
I addressed the deferred comments in https://codereview.chromium.org/23464005/. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... File content/renderer/media/crypto/key_systems.cc (right): https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:63: typedef base::hash_set<std::string> CodecMappings; On 2013/08/29 22:20:18, ddorwin wrote: > On 2013/08/29 21:45:26, xhwang wrote: > > Shall we name this a Set? > > Separate CL. I'd like to keep as much similar in this CL as possible. Done in new CL. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:78: typedef std::map<std::string, KeySystemProperties> KeySystemMappings; On 2013/08/29 22:20:18, ddorwin wrote: > On 2013/08/29 21:45:26, xhwang wrote: > > nit: rename to KeySystemPropertiesMappings? > > Ditto. Done in new CL. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:80: typedef std::map<std::string, std::string> ParentKeySystemMappings; On 2013/08/29 22:20:18, ddorwin wrote: > On 2013/08/29 21:45:26, xhwang wrote: > > nit: Can we rename all "Mappings" to "Map"? > > Ditto. Done in new CL. https://codereview.chromium.org/23464005/diff/20001/content/renderer/media/cr... content/renderer/media/crypto/key_systems.cc:168: return key_system_map_.find(key_system) != key_system_map_.end(); On 2013/08/29 22:20:18, ddorwin wrote: > On 2013/08/29 21:45:26, xhwang wrote: > > shall we s/key_system_map_/concrete_key_system_map_/ ? > > Ditto. (Later) Done in new CL.
Failed to trigger a try job on android_dbg HTTP Error 400: Bad Request
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/ddorwin@chromium.org/23464005/53001
Sorry for I got bad news for ya. Compile failed with a clobber build on android_clang_dbg. http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_cl... Your code is likely broken or HEAD is junk. Please ensure your code is not broken then alert the build sheriffs. Look at the try server FAQ for more details.
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/ddorwin@chromium.org/23464005/75001
Retried try job too often on win7_aura for step(s) content_unittests http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win7_aura&...
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/ddorwin@chromium.org/23464005/88001
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/ddorwin@chromium.org/23464005/21006
Retried try job too often on win7_aura for step(s) interactive_ui_tests http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win7_aura&...
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/ddorwin@chromium.org/23464005/21006
Message was sent while issue was closed.
Change committed as 220664 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
