Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
537773003:
Add a user agent stylesheet for extension options pages (Closed)
|
Created:
6 years, 3 months ago by ericzeng Modified:
6 years, 3 months ago CC:
chromium-reviews, chromium-apps-reviews_chromium.org, extensions-reviews_chromium.org, not at google - send to devlin Base URL:
https://chromium.googlesource.com/chromium/src.git@master Project:
chromium Visibility:
Public. |
DescriptionAdd a user agent stylesheet for extension options pages
Apply WebUI styles to extension options pages that opt into using them
through a user agent stylesheet. The styles are copied from widgets.css
and chrome_shared.css in ui/webui/resources/css/ - this is intentional
so that WebUI changes won't break extensions.
The extension.css stylesheet will only be applied to extensions that
opt in using the "options_ui.chrome_style" manifest entry, and it will
only affect the options page specified in the manifest. The font
stylesheet for extensions have been moved to extension_fonts.css, and
are still applied to every extension page.
BUG=408271
Committed: https://crrev.com/685c341afc41e774ab12d38208fc1ad3fb1ffd6d
Cr-Commit-Position: refs/heads/master@{#294491}
Patch Set 1 #
Total comments: 10
Patch Set 2 : Add comment explaining file copy #Patch Set 3 : Remove Data URI hardcoding, remove deprecated WebKit CSS declarations #
Total comments: 12
Patch Set 4 : Use existing code to get Data URIs from WebUI resource ids #Patch Set 5 : Fix build issues and add attribute for grit processing #Patch Set 6 : Use grit to handle background-image data URIs #
Total comments: 2
Patch Set 7 : Rebase and fix nit #Patch Set 8 : Fix manifest handler build issue #Patch Set 9 : Rebase #Patch Set 10 : Add preprocessor directive to fix Android build #
Messages
Total messages: 36 (11 generated)
ericzeng@chromium.org changed reviewers: + mek@chromium.org, rdevlin.cronin@chromium.org, rockot@chromium.org, yoz@chromium.org
PTAL, I have a couple of concerns about how I'm doing CSS injection. First, I noticed that the styles in extension.css, extension_fonts.css, and platform_app.css show up as a user stylesheet in devtools rather than a user agent stylesheet. Second, I'm using a massive hack to get WebUI checkboxes to work inside extension pages. Since extensions won't be able to access images from ui/webui/resources/images, I'm just using data URLs to pass them in. @mek - since you did the changes for platform_app.css in Dispatcher, do you know what's up with the user/user agent stylesheet?
https://codereview.chromium.org/537773003/diff/1/extensions/renderer/dispatch... File extensions/renderer/dispatcher.cc (right): https://codereview.chromium.org/537773003/diff/1/extensions/renderer/dispatch... extensions/renderer/dispatcher.cc:360: effective_document_url == OptionsPageInfo::GetOptionsPage(extension)) { Is this data copied over to the renderer process? (It may be, I don't know) https://codereview.chromium.org/537773003/diff/1/extensions/renderer/dispatch... extensions/renderer/dispatcher.cc:363: .GetRawDataResource(IDR_EXTENSION_CSS) Naively looking at this, it seems that you inject this style sheet on *all* extension pages, not just the options page. Is that the case, and, if so, intentional? https://codereview.chromium.org/537773003/diff/1/extensions/renderer/resource... File extensions/renderer/resources/extension.css (right): https://codereview.chromium.org/537773003/diff/1/extensions/renderer/resource... extensions/renderer/resources/extension.css:2: * Copyright 2014 The Chromium Authors. All rights reserved. This whole file is just copied from various other css files? Should we mention that?
https://codereview.chromium.org/537773003/diff/1/extensions/renderer/dispatch... File extensions/renderer/dispatcher.cc (right): https://codereview.chromium.org/537773003/diff/1/extensions/renderer/dispatch... extensions/renderer/dispatcher.cc:360: effective_document_url == OptionsPageInfo::GetOptionsPage(extension)) { On 2014/09/04 21:27:37, Devlin wrote: > Is this data copied over to the renderer process? (It may be, I don't know) I don't know either. Which data in particular? https://codereview.chromium.org/537773003/diff/1/extensions/renderer/dispatch... extensions/renderer/dispatcher.cc:363: .GetRawDataResource(IDR_EXTENSION_CSS) On 2014/09/04 21:27:37, Devlin wrote: > Naively looking at this, it seems that you inject this style sheet on *all* > extension pages, not just the options page. Is that the case, and, if so, > intentional? I think the conditional above should catch it - it checks if effective_document_url is equal to the extension's options page. https://codereview.chromium.org/537773003/diff/1/extensions/renderer/resource... File extensions/renderer/resources/extension.css (right): https://codereview.chromium.org/537773003/diff/1/extensions/renderer/resource... extensions/renderer/resources/extension.css:2: * Copyright 2014 The Chromium Authors. All rights reserved. On 2014/09/04 21:27:37, Devlin wrote: > This whole file is just copied from various other css files? Should we mention > that? Done.
https://codereview.chromium.org/537773003/diff/1/extensions/renderer/dispatch... File extensions/renderer/dispatcher.cc (right): https://codereview.chromium.org/537773003/diff/1/extensions/renderer/dispatch... extensions/renderer/dispatcher.cc:360: effective_document_url == OptionsPageInfo::GetOptionsPage(extension)) { On 2014/09/04 22:30:30, ericzeng wrote: > On 2014/09/04 21:27:37, Devlin wrote: > > Is this data copied over to the renderer process? (It may be, I don't know) > > I don't know either. Which data in particular? The extension's manifest data for whether or not it has an options page. https://codereview.chromium.org/537773003/diff/1/extensions/renderer/dispatch... extensions/renderer/dispatcher.cc:363: .GetRawDataResource(IDR_EXTENSION_CSS) On 2014/09/04 22:30:30, ericzeng wrote: > On 2014/09/04 21:27:37, Devlin wrote: > > Naively looking at this, it seems that you inject this style sheet on *all* > > extension pages, not just the options page. Is that the case, and, if so, > > intentional? > > I think the conditional above should catch it - it checks if > effective_document_url is equal to the extension's options page. D'oh. Don't know why I missed that.
https://codereview.chromium.org/537773003/diff/1/extensions/renderer/dispatch... File extensions/renderer/dispatcher.cc (right): https://codereview.chromium.org/537773003/diff/1/extensions/renderer/dispatch... extensions/renderer/dispatcher.cc:360: effective_document_url == OptionsPageInfo::GetOptionsPage(extension)) { On 2014/09/04 22:39:19, Devlin wrote: > On 2014/09/04 22:30:30, ericzeng wrote: > > On 2014/09/04 21:27:37, Devlin wrote: > > > Is this data copied over to the renderer process? (It may be, I don't know) > > > > I don't know either. Which data in particular? > > The extension's manifest data for whether or not it has an options page. I'm pretty sure that it is - the IPC call when extensions are loaded is here: https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ext... And then if you look in the constructor for that struct, it makes a copy of the manifest data here: https://code.google.com/p/chromium/codesearch#chromium/src/extensions/common/...
https://codereview.chromium.org/537773003/diff/1/extensions/renderer/dispatch... File extensions/renderer/dispatcher.cc (right): https://codereview.chromium.org/537773003/diff/1/extensions/renderer/dispatch... extensions/renderer/dispatcher.cc:360: effective_document_url == OptionsPageInfo::GetOptionsPage(extension)) { On 2014/09/04 23:48:58, ericzeng wrote: > On 2014/09/04 22:39:19, Devlin wrote: > > On 2014/09/04 22:30:30, ericzeng wrote: > > > On 2014/09/04 21:27:37, Devlin wrote: > > > > Is this data copied over to the renderer process? (It may be, I don't > know) > > > > > > I don't know either. Which data in particular? > > > > The extension's manifest data for whether or not it has an options page. > > I'm pretty sure that it is - the IPC call when extensions are loaded is here: > https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ext... > > And then if you look in the constructor for that struct, it makes a copy of the > manifest data here: > https://code.google.com/p/chromium/codesearch#chromium/src/extensions/common/... Yes, the renderer ought to have all the manifest data. (Back in the day, we were trying to determine which manifest handlers we needed in the renderer; we decided to go with all of them, for simplicity.)
I was able to remove the hardcoded Data URIs from the CSS. Now I can get the images I need, convert them to Data URIs, and insert them into the stylesheet programmatically, which is slightly better. I'm not sure if there is a better way, and it looks like CSP will make it hard to load local resources even if I tried.
On 2014/09/04 01:00:54, ericzeng wrote: > @mek - since you did the changes for platform_app.css in Dispatcher, do you know > what's up with the user/user agent stylesheet? I'm not sure, but I assume this comment in dispatcher.cc has something to do with this: // Blink doesn't let us define an additional user agent stylesheet, so // we insert the default platform app or extension stylesheet into all // documents that are loaded in each app or extension. https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/disp... File extensions/renderer/dispatcher.cc (right): https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/disp... extensions/renderer/dispatcher.cc:185: std::string GetPNGAsDataURI(int resource_id) { Is this the same as webui::GetBitmapDataUrlFromResource (from ui/base/webui/web_ui_util.h)? If so, can you use that other method instead? https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/disp... extensions/renderer/dispatcher.cc:410: frame->document().insertStyleSheet(WebString::fromUTF8(stylesheet)); Would it make sense to cache the preprocessed stylesheet somehow? It's not like the css can ever change while running, but then the few string replacements are probably not very expensive and option pages aren't opened very frequently so just always doing this on demand is probably fine. https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/reso... File extensions/renderer/resources/extension.css (right): https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/reso... extensions/renderer/resources/extension.css:10: * breaking extensions, however please keep the files in sync if possible. "please keep in sync" comments probably work better if the comment is in both files that should be kept in sync? https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/reso... File extensions/renderer/resources/extensions_renderer_resources.grd (right): https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/reso... extensions/renderer/resources/extensions_renderer_resources.grd:57: <include name="IDR_EXTENSION_FONTS_CSS" file="extension_fonts.css" type="BINDATA"/> I'm not entirely sure, but will this work to get the <if expr> bits to be evaluated by grit? The original widgets.css etc files are included as <structure name="IDR_WEBUI_CSS_WIDGETS" file="css/widgets.css" type="chrome_html" flattenhtml="true" /> instead of the <include> you use here (I have no idea what the flattenhtml attribute there does though, it only seems to be present for widgets.css, not for most of the other webui css files).
https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/disp... File extensions/renderer/dispatcher.cc (right): https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/disp... extensions/renderer/dispatcher.cc:185: std::string GetPNGAsDataURI(int resource_id) { On 2014/09/10 20:46:30, Marijn Kruisselbrink wrote: > Is this the same as webui::GetBitmapDataUrlFromResource (from > ui/base/webui/web_ui_util.h)? If so, can you use that other method instead? Yes, done. https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/disp... extensions/renderer/dispatcher.cc:410: frame->document().insertStyleSheet(WebString::fromUTF8(stylesheet)); On 2014/09/10 20:46:30, Marijn Kruisselbrink wrote: > Would it make sense to cache the preprocessed stylesheet somehow? It's not like > the css can ever change while running, but then the few string replacements are > probably not very expensive and option pages aren't opened very frequently so > just always doing this on demand is probably fine. Yeah, I don't think options pages are going to be used frequently enough to require caching. https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/reso... File extensions/renderer/resources/extension.css (right): https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/reso... extensions/renderer/resources/extension.css:10: * breaking extensions, however please keep the files in sync if possible. On 2014/09/10 20:46:30, Marijn Kruisselbrink wrote: > "please keep in sync" comments probably work better if the comment is in both > files that should be kept in sync? The WebUI team didn't want to worry about breaking extensions, hence the file copy, so I don't think we should expect that changes to those files are immediately synced to here. https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/reso... File extensions/renderer/resources/extensions_renderer_resources.grd (right): https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/reso... extensions/renderer/resources/extensions_renderer_resources.grd:57: <include name="IDR_EXTENSION_FONTS_CSS" file="extension_fonts.css" type="BINDATA"/> On 2014/09/10 20:46:30, Marijn Kruisselbrink wrote: > I'm not entirely sure, but will this work to get the <if expr> bits to be > evaluated by grit? The original widgets.css etc files are included as > <structure name="IDR_WEBUI_CSS_WIDGETS" > file="css/widgets.css" type="chrome_html" > flattenhtml="true" /> > instead of the <include> you use here (I have no idea what the flattenhtml > attribute there does though, it only seems to be present for widgets.css, not > for most of the other webui css files). Which <if expr> are you referring to? I am not familiar with how grit works. It seems that the other CSS files in extensions work just fine as an <include>.
https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/reso... File extensions/renderer/resources/extensions_renderer_resources.grd (right): https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/reso... extensions/renderer/resources/extensions_renderer_resources.grd:57: <include name="IDR_EXTENSION_FONTS_CSS" file="extension_fonts.css" type="BINDATA"/> On 2014/09/10 21:29:30, ericzeng wrote: > On 2014/09/10 20:46:30, Marijn Kruisselbrink wrote: > > I'm not entirely sure, but will this work to get the <if expr> bits to be > > evaluated by grit? The original widgets.css etc files are included as > > <structure name="IDR_WEBUI_CSS_WIDGETS" > > file="css/widgets.css" type="chrome_html" > > flattenhtml="true" /> > > instead of the <include> you use here (I have no idea what the flattenhtml > > attribute there does though, it only seems to be present for widgets.css, not > > for most of the other webui css files). > > Which <if expr> are you referring to? I am not familiar with how grit works. It > seems that the other CSS files in extensions work just fine as an <include>. If you look at widgets.css (or at the extension.css file you added) you see various lines like <if expr="is_win">, these lines are not valid css. What happens (if I understand how it works) is that (if you properly tell grit to process these files as "chrome_html" files) grit will parse these tags and only include the bits that are correct for the current platform. But having said that, there seems to be more magic that grit does, which might help or hurt you. One thing it seems to do is replace relative file urls with data urls (just look at widgets.css as it is injected into webui pages, it has data urls instead of relative urls). So maybe just running your css through grit (with the proper relative paths to the png files) will do all the hard work for you at compile time. (but again, I'm not entirely sure how grit works, so it might be more complicated then that...
https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/reso... File extensions/renderer/resources/extensions_renderer_resources.grd (right): https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/reso... extensions/renderer/resources/extensions_renderer_resources.grd:57: <include name="IDR_EXTENSION_FONTS_CSS" file="extension_fonts.css" type="BINDATA"/> On 2014/09/10 21:45:40, Marijn Kruisselbrink wrote: > On 2014/09/10 21:29:30, ericzeng wrote: > > On 2014/09/10 20:46:30, Marijn Kruisselbrink wrote: > > > I'm not entirely sure, but will this work to get the <if expr> bits to be > > > evaluated by grit? The original widgets.css etc files are included as > > > <structure name="IDR_WEBUI_CSS_WIDGETS" > > > file="css/widgets.css" type="chrome_html" > > > flattenhtml="true" /> > > > instead of the <include> you use here (I have no idea what the flattenhtml > > > attribute there does though, it only seems to be present for widgets.css, > not > > > for most of the other webui css files). > > > > Which <if expr> are you referring to? I am not familiar with how grit works. > It > > seems that the other CSS files in extensions work just fine as an <include>. > If you look at widgets.css (or at the extension.css file you added) you see > various lines like <if expr="is_win">, these lines are not valid css. What > happens (if I understand how it works) is that (if you properly tell grit to > process these files as "chrome_html" files) grit will parse these tags and only > include the bits that are correct for the current platform. > > But having said that, there seems to be more magic that grit does, which might > help or hurt you. One thing it seems to do is replace relative file urls with > data urls (just look at widgets.css as it is injected into webui pages, it has > data urls instead of relative urls). So maybe just running your css through grit > (with the proper relative paths to the png files) will do all the hard work for > you at compile time. (but again, I'm not entirely sure how grit works, so it > might be more complicated then that... If I change the type from BINDATA it looks like grit is taking care of the <if expr> for me. However, I'm certain that I won't be allowed to use the relative urls for background-image. I've done a little testing and it looks like grit doesn't touch the parameters to url(...), at least in extension_renderer_resources.
https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/reso... File extensions/renderer/resources/extensions_renderer_resources.grd (right): https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/reso... extensions/renderer/resources/extensions_renderer_resources.grd:57: <include name="IDR_EXTENSION_FONTS_CSS" file="extension_fonts.css" type="BINDATA"/> On 2014/09/10 22:13:48, ericzeng wrote: > On 2014/09/10 21:45:40, Marijn Kruisselbrink wrote: > > On 2014/09/10 21:29:30, ericzeng wrote: > > > On 2014/09/10 20:46:30, Marijn Kruisselbrink wrote: > > > > I'm not entirely sure, but will this work to get the <if expr> bits to be > > > > evaluated by grit? The original widgets.css etc files are included as > > > > <structure name="IDR_WEBUI_CSS_WIDGETS" > > > > file="css/widgets.css" type="chrome_html" > > > > flattenhtml="true" /> > > > > instead of the <include> you use here (I have no idea what the flattenhtml > > > > attribute there does though, it only seems to be present for widgets.css, > > not > > > > for most of the other webui css files). > > > > > > Which <if expr> are you referring to? I am not familiar with how grit works. > > It > > > seems that the other CSS files in extensions work just fine as an <include>. > > If you look at widgets.css (or at the extension.css file you added) you see > > various lines like <if expr="is_win">, these lines are not valid css. What > > happens (if I understand how it works) is that (if you properly tell grit to > > process these files as "chrome_html" files) grit will parse these tags and > only > > include the bits that are correct for the current platform. > > > > But having said that, there seems to be more magic that grit does, which might > > help or hurt you. One thing it seems to do is replace relative file urls with > > data urls (just look at widgets.css as it is injected into webui pages, it has > > data urls instead of relative urls). So maybe just running your css through > grit > > (with the proper relative paths to the png files) will do all the hard work > for > > you at compile time. (but again, I'm not entirely sure how grit works, so it > > might be more complicated then that... > > If I change the type from BINDATA it looks like grit is taking care of the <if > expr> for me. > > However, I'm certain that I won't be allowed to use the relative urls for > background-image. I've done a little testing and it looks like grit doesn't > touch the parameters to url(...), at least in extension_renderer_resources. I just tested this, if I add the following to extensions_renderer_resources.grd: <structures> <structure name="IDR_EXTENSION_CSS" file="extension.css" type="chrome_html" flattenhtml="true" /> </structures> (as well as add "structures": [26890] to the extensions_renderer_resources.grd entry in tools/gritsettings/resource_ids) And then change the resource urls in extension.css to be things like url(../../../ui/webui/resources/images/select.png) grit correctly replaces all these urls with data urls.
https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/reso... File extensions/renderer/resources/extensions_renderer_resources.grd (right): https://codereview.chromium.org/537773003/diff/40001/extensions/renderer/reso... extensions/renderer/resources/extensions_renderer_resources.grd:57: <include name="IDR_EXTENSION_FONTS_CSS" file="extension_fonts.css" type="BINDATA"/> On 2014/09/10 22:32:04, Marijn Kruisselbrink wrote: > On 2014/09/10 22:13:48, ericzeng wrote: > > On 2014/09/10 21:45:40, Marijn Kruisselbrink wrote: > > > On 2014/09/10 21:29:30, ericzeng wrote: > > > > On 2014/09/10 20:46:30, Marijn Kruisselbrink wrote: > > > > > I'm not entirely sure, but will this work to get the <if expr> bits to > be > > > > > evaluated by grit? The original widgets.css etc files are included as > > > > > <structure name="IDR_WEBUI_CSS_WIDGETS" > > > > > file="css/widgets.css" type="chrome_html" > > > > > flattenhtml="true" /> > > > > > instead of the <include> you use here (I have no idea what the > flattenhtml > > > > > attribute there does though, it only seems to be present for > widgets.css, > > > not > > > > > for most of the other webui css files). > > > > > > > > Which <if expr> are you referring to? I am not familiar with how grit > works. > > > It > > > > seems that the other CSS files in extensions work just fine as an > <include>. > > > If you look at widgets.css (or at the extension.css file you added) you see > > > various lines like <if expr="is_win">, these lines are not valid css. What > > > happens (if I understand how it works) is that (if you properly tell grit to > > > process these files as "chrome_html" files) grit will parse these tags and > > only > > > include the bits that are correct for the current platform. > > > > > > But having said that, there seems to be more magic that grit does, which > might > > > help or hurt you. One thing it seems to do is replace relative file urls > with > > > data urls (just look at widgets.css as it is injected into webui pages, it > has > > > data urls instead of relative urls). So maybe just running your css through > > grit > > > (with the proper relative paths to the png files) will do all the hard work > > for > > > you at compile time. (but again, I'm not entirely sure how grit works, so it > > > might be more complicated then that... > > > > If I change the type from BINDATA it looks like grit is taking care of the <if > > expr> for me. > > > > However, I'm certain that I won't be allowed to use the relative urls for > > background-image. I've done a little testing and it looks like grit doesn't > > touch the parameters to url(...), at least in extension_renderer_resources. > > I just tested this, if I add the following to extensions_renderer_resources.grd: > <structures> > <structure name="IDR_EXTENSION_CSS" > file="extension.css" type="chrome_html" > flattenhtml="true" /> > > </structures> > > (as well as add "structures": [26890] to the > extensions_renderer_resources.grd entry in tools/gritsettings/resource_ids) > > And then change the resource urls in extension.css to be things like > url(../../../ui/webui/resources/images/select.png) grit correctly replaces all > these urls with data urls. Wow, I didn't know that was possible. Thanks!
lgtm https://codereview.chromium.org/537773003/diff/100001/extensions/renderer/res... File extensions/renderer/resources/extensions_renderer_resources.grd (right): https://codereview.chromium.org/537773003/diff/100001/extensions/renderer/res... extensions/renderer/resources/extensions_renderer_resources.grd:56: <include name="IDR_EXTENSION_FONTS_CSS" file="extension_fonts.css" type="chrome_html"/> nit: I think this can just stay type="BINDATA", you don't really gain anything by changing this.
https://codereview.chromium.org/537773003/diff/100001/extensions/renderer/res... File extensions/renderer/resources/extensions_renderer_resources.grd (right): https://codereview.chromium.org/537773003/diff/100001/extensions/renderer/res... extensions/renderer/resources/extensions_renderer_resources.grd:56: <include name="IDR_EXTENSION_FONTS_CSS" file="extension_fonts.css" type="chrome_html"/> On 2014/09/10 23:37:34, Marijn Kruisselbrink wrote: > nit: I think this can just stay type="BINDATA", you don't really gain anything > by changing this. Done.
The CQ bit was checked by ericzeng@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patchset/537773003/120001
The CQ bit was checked by ericzeng@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patchset/537773003/140001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: android_arm64_dbg_recipe on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/android_arm64_d...) android_clang_dbg_recipe on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...)
The CQ bit was checked by ericzeng@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patchset/537773003/160001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: android_dbg_tests_recipe on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/android_dbg_tes...)
The CQ bit was checked by ericzeng@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patchset/537773003/160001
The CQ bit was unchecked by ericzeng@chromium.org
The CQ bit was checked by ericzeng@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patchset/537773003/180001
The CQ bit was unchecked by ericzeng@chromium.org
The CQ bit was checked by ericzeng@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patchset/537773003/180001
Message was sent while issue was closed.
Committed patchset #10 (id:180001) as 5382cd94f2e63062b8b82b6a8d30dbd17c48cdf7
Message was sent while issue was closed.
Patchset 10 (id:??) landed as https://crrev.com/685c341afc41e774ab12d38208fc1ad3fb1ffd6d Cr-Commit-Position: refs/heads/master@{#294491} |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
