Issue metadata
Sign in to add a comment
|
HTML, Javascript, and CSS in pak files should be compressed. |
||||||||||||||||||||||
Issue descriptionChrome and WebView pak files include substantial quantities of HTML for, for example, error pages. This HTML includes inline CSS and Javascript. These files are included as is, with no stripping of spaces or comments. As a result the chrome resources.pak file for Android (which is stored uncompressed in the Chrome APK) contains more than 500kB of Javascript or CSS comments, and 500kB of whitespace (including, however some whitespace in comments). At the very least we should strip comments and remove unnecessary whitespace, and we could possibly compress these pages further using the closure compiler or similar as part of our build process. Webview resources are smaller but still contain include roughly 100kB of comments and spaces. Note:- Although my investigations have been on Android I think this applies to all platforms.
,
Jun 10 2016
bauerb@ suggested that we might also gzip these pages within the pak files, and unzip them on loading. While this would cost some time, it should be insignificant compared with the time to display the pages.
,
Jun 13 2016
So, as it turns out, someone already had exactly the same idea as #2 -- see issue 609219 :-D
,
Jun 13 2016
That issue appears to be about gzipping infrequently used resources - while that overlaps somewhat, we should also look at minifying them, since that will reduce their size at no runtime performance cost at all..
,
Jun 14 2016
,
Jun 14 2016
One issue I have found experimenting with this is that some of our Javascript resource files aren't pure Javascript. Specifically they contain <include ...> statements and <if ...> blocks that are used to preprocess the files before including them in the resource file. These are currently processed by grit as part of creating the resource file. As such, with the current structure, the closure compiler gives errors if used on the raw Javascript resources and cannot be used to strip comments and spaces until the preprocessor has been run. As such it seems we have two choices: 1. Calling the closure compiler from within grit, after preprocessing, to strip spaces and comments. 2. Run our preprocessor before running either the compiler or grit, as a separate step, and then feed the preprocessed Javascript files into the compiler. The first option is probably easier, but has the disadvantage that the stripped Javascript would only ever exist within grit, so all the source files for a particular resource file will have to be stripped every time that resource file is rebuilt. This could slow down the build (although I don't yet know by how much). It also introduces a direct dependency between grit and the closure compiler, which could make grit more difficult to maintain in future. The second option would allow us to have individual targets for each stripped file, hence meaning that they would only be rebuilt when needed, but means splitting up grit into a preprocessor and a resource file builder. This probably more work than the first option. Thoughts? Comments? Note:- I think all this applies equally to the CSS and HTML resource files, although I have yet to investigate how we compress these. Grit will still have to do the final flattening of HTML files that reference CSS or Javascript files, since this has to be done after the language sensitive stripping.
,
Jun 15 2016
+groby@ +grit Owners To implement this I am intending to create a new grit tool that just preprocesses a the <if...> and <include..> lines in a single (Javascript, CSS or HTML file). This will be based on groby@'s recent CL (https://codereview.chromium.org/2014793002) although will be controlled differently. For resources that needed stripping the process would then be: - Preprocess the resources - Run the appropriate whitespace/comment stripper on the resources - Run grit build. This will allow a separate GN (and hence ninja) target for each file we want to strip, hence allowing the comment stripper only to be run on changed files. I still need to look at how we tell the grit build tool to pick up the preprocessed files in place of the originals, but other than this I don't think this will need any changes to the build tool. Any comments from grit experts (or others) on this proposal?
,
Jun 15 2016
I a bit worry about debuggability if we minify too much. As long as we're not obfuscating, I think devtool's pretty-print button should be good enough to put whitespace back in, but maybe we'd also want to consider doing this only in release mode? I don't actually see how #7 allows for a separate ninja rule for each file unless you're thinking of running a scanner from an exec_script(), which I don't think is a good idea. It might be simpler to just take the build speed hit of obfuscating every time, but only when in release mode. If it's really a slowdown, we could also have grit not bother re-minifying if the minified version is newer than the source.
,
Jun 15 2016
For Javascript the closure compiler gives us the choice of just whitespace (and comment) removal, "simple" optimization, or "advanced" optimization. I was planning to start with just whitespace removal, and then possibly later investigate the gains from simple or advanced optimization (either of which would obfuscate the code). I will make sure that we can easily make different choices (including no stripping) for different builds, and, I agree that it may make sense only to turn this on for release builds. I have not yet investigated whitespace removers for CSS or HTML, but I don't expect to use anything that does more than simple whitespace and comment removal. My thoughts on ninja steps is that one could have targets such as extension_list_js_stripped. This would depend on extension_list.js (and a dependency file) and would run something like: grit preprocess extension_list.js -o extension_list_preprocessed.js closure_compiler --whitespace-only extension_list_preprocessed.js > extension_list_stripped.js The final grit step would then depend on this target, and on all the other similar targets. This would, of course, mean that all the files we wanted to strip would have to be explicitly listed in our GN build files; but we already list all our C++ and Java source files in our build files (for Java this was a change from GYP) so this seems to fit with the general philosophy of our build process.
,
Jun 15 2016
Gotcha, yeah it's that "they all must be listed explicitly part" that I just wanted to ensure you were aware of. I agree it would be an improvement though, since for targets to notice they are stale, they need to have all inputs listed in .gn files.
,
Jun 15 2016
Random question: grd include statements already have a compress attribute. Why not add a compress="minify" option?
,
Jun 15 2016
,
Jun 15 2016
> Why not add a compress="minify" option? I did consider that, and even started to experiment with it, but there are two reasons that that felt the wrong way to go: 1 - it would pull lots of external tools and extra functionality into grit (in particular it would make grit dependent on the closure compiler). I tend to feel the model of small separate tools working together is typically more flexible and maintainable than a single monolithic tool. 2 - bauerb@ suggested the closure compiler might be slow. If it is then it seems sensible to exploit ninja to only run it when its inputs have changed. This is difficult to do if it called from grit. I accept that the changes required to do it my way are possibly more complex, but my feeling is that the result will be cleaner. Unmerging from issue 783368 since we should also deal with whitespace in CSS and HTML resources, but I will look at what happened on that issue tomorrow.
,
Jun 16 2016
There is another way in which this is not a duplicate of issue 783368 . According to https://bugs.chromium.org/p/chromium/issues/detail?id=78368#c40 the primary motivation for that issue is type checking. While that is a laudable aim, it is not the aim here. My motivation for raising this issue is that on Android the sizes of the Chrome and Webview APKs are a significant issue for users, since large APKs are slower to download (particularly on mobile networks) and use too much of the very limited disk space on some devices. As such my intention here is to run the Closure compiler purely as a whitespace and comment stripper, with minimal typechecks. We may later choose to introduce typechecks, and solve any problems that discovers, but that is a separate task.
,
Jun 16 2016
I did, of course, mean issue 78368 in my last two comments.
,
Jul 5 2016
I have now written a design document for this: https://docs.google.com/document/d/1XUte4m_wkPwQ9I-MfVZfBhksoL0E2_7Eb7N-PkXQKvw/edit?usp=sharing
,
Jul 6 2016
I'm working on a related bug: https://bugs.chromium.org/p/chromium/issues/detail?id=472927 CL: https://codereview.chromium.org/2088123002/
,
Jul 6 2016
,
Jul 6 2016
The CL (not yet landed) for this is https://codereview.chromium.org/2094193004/. Please take a look if you are interested, and in particular if you are working on something related.
,
Jul 11 2016
Issue 455984 has been merged into this issue.
,
Aug 2 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/055b3f32db776858013eafe927c994a4d822376c commit 055b3f32db776858013eafe927c994a4d822376c Author: dbeam <dbeam@chromium.org> Date: Tue Aug 02 20:26:24 2016 Make Chrome-specific enhancements optional in runner.jar BUG= 619091 R=tbreisacher@chromium.org NOTRY=true Review-Url: https://codereview.chromium.org/2113053002 Cr-Commit-Position: refs/heads/master@{#409306} [modify] https://crrev.com/055b3f32db776858013eafe927c994a4d822376c/third_party/closure_compiler/README.chromium [modify] https://crrev.com/055b3f32db776858013eafe927c994a4d822376c/third_party/closure_compiler/runner/src/org/chromium/closure/compiler/Runner.java
,
Aug 2 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b16b05a3e4f0ef231f2b6a8df10d6ecff4284518 commit b16b05a3e4f0ef231f2b6a8df10d6ecff4284518 Author: Dan Beam <dbeam@chromium.org> Date: Tue Aug 02 21:40:57 2016 Add the ability to pass arguments to runner.jar This is used mainly so that the Chrome-specific compiler pass can be enabled and disabled. BUG= 619091 R=aberent@chromium.org, jamiewalch@chromium.org Review URL: https://codereview.chromium.org/2117653002 . Cr-Commit-Position: refs/heads/master@{#409336} [modify] https://crrev.com/b16b05a3e4f0ef231f2b6a8df10d6ecff4284518/remoting/compile_js.gypi [modify] https://crrev.com/b16b05a3e4f0ef231f2b6a8df10d6ecff4284518/remoting/webapp/build_template.gni [modify] https://crrev.com/b16b05a3e4f0ef231f2b6a8df10d6ecff4284518/third_party/closure_compiler/closure_args.gni [modify] https://crrev.com/b16b05a3e4f0ef231f2b6a8df10d6ecff4284518/third_party/closure_compiler/closure_args.gypi [modify] https://crrev.com/b16b05a3e4f0ef231f2b6a8df10d6ecff4284518/third_party/closure_compiler/compile.py [modify] https://crrev.com/b16b05a3e4f0ef231f2b6a8df10d6ecff4284518/third_party/closure_compiler/compile2.py [modify] https://crrev.com/b16b05a3e4f0ef231f2b6a8df10d6ecff4284518/third_party/closure_compiler/compile_js.gypi [modify] https://crrev.com/b16b05a3e4f0ef231f2b6a8df10d6ecff4284518/third_party/closure_compiler/compile_js2.gypi [modify] https://crrev.com/b16b05a3e4f0ef231f2b6a8df10d6ecff4284518/third_party/closure_compiler/compiler_test.py [modify] https://crrev.com/b16b05a3e4f0ef231f2b6a8df10d6ecff4284518/third_party/closure_compiler/runner/runner.jar [modify] https://crrev.com/b16b05a3e4f0ef231f2b6a8df10d6ecff4284518/ui/file_manager/compile_js.gypi
,
Aug 3 2016
So, dumb question: we're talking about text here. Text compresses really really well with deflate. Why aren't we just compressing these things and decompressing on-the-fly as we read them from the resources? I get that minification and stripping allows us to avoid modifications to the code that does the reading, but surely there are other cases where we would want to read compressed data, no? These are complementary things but my gut is that just compressing with deflate will achieve at least as much as trying to minify/strip. Did I miss something?
,
Aug 3 2016
We can't deflate the whole PAK file, since doing so would require us to inflate it on install, and keep an inflated copy of it on disk, rather than reading it directly from memory resources. If you are thinking of deflating individual resources, see the discussion in https://docs.google.com/document/d/1_kIGIklObY9NJhfPUvd-Iqq8Cj1jChU9d43pZzwft1Y/edit?pref=2&pli=1. I think minifying and deflating are complementary, and we might later deflate some individual resources; but unless we are careful, deflation (or rather re-inflation) will considerably increase Clank's use of memory.
,
Aug 3 2016
Thanks, Anthony. That makes sense.
,
Aug 3 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8dfa12f1b8845bc912728471d19d9915119456d7 commit 8dfa12f1b8845bc912728471d19d9915119456d7 Author: aberent <aberent@chromium.org> Date: Wed Aug 03 12:43:34 2016 Strip comments and whitespace from javascript resources On Android strip comments and whitespace from javascript resources. Add an option to grit build that provides a command that strips comments and whitespace, and modify grit so that this is applied to all javascript resource and scripts within HTML resources. Add a python script that wraps the closure compiler to implement this command. Pull it all together with GN. BUG= 619091 Review-Url: https://codereview.chromium.org/2179033002 Cr-Commit-Position: refs/heads/master@{#409498} [modify] https://crrev.com/8dfa12f1b8845bc912728471d19d9915119456d7/third_party/closure_compiler/closure_args.gni [modify] https://crrev.com/8dfa12f1b8845bc912728471d19d9915119456d7/third_party/closure_compiler/compile2.py [add] https://crrev.com/8dfa12f1b8845bc912728471d19d9915119456d7/third_party/closure_compiler/js_minify.py [modify] https://crrev.com/8dfa12f1b8845bc912728471d19d9915119456d7/third_party/closure_compiler/runner/runner.jar [modify] https://crrev.com/8dfa12f1b8845bc912728471d19d9915119456d7/tools/grit/grit/format/html_inline.py [add] https://crrev.com/8dfa12f1b8845bc912728471d19d9915119456d7/tools/grit/grit/format/minifier.py [modify] https://crrev.com/8dfa12f1b8845bc912728471d19d9915119456d7/tools/grit/grit/gather/chrome_html.py [modify] https://crrev.com/8dfa12f1b8845bc912728471d19d9915119456d7/tools/grit/grit/node/include.py [modify] https://crrev.com/8dfa12f1b8845bc912728471d19d9915119456d7/tools/grit/grit/tool/build.py [modify] https://crrev.com/8dfa12f1b8845bc912728471d19d9915119456d7/tools/grit/grit_rule.gni
,
Aug 3 2016
,
Aug 3 2016
andrewhayden@: compress="gzip" in GRD files does what you're talking about -- it keeps the file gzipped on disk. i made a proof-of-concept using net/'s filter system for more efficient decompressing as well as dropping the custom file header currently used to identify these resources[1] (so mmapping is more straight-forward). agrieve@/smaier@ have also been very careful, only gzipping or brotli'ing developer-facing chrome:// pages, but there's more we can do here.[2] [1] https://codereview.chromium.org/2149323003/ [2] https://codereview.chromium.org/2152143002/
,
Sep 16 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9dcdbe36c99b33e9205338cf58e9a38620b365e9 commit 9dcdbe36c99b33e9205338cf58e9a38620b365e9 Author: dbeam <dbeam@chromium.org> Date: Fri Sep 16 06:17:21 2016 Compress chrome://history's resources Theoretically shaves 78658 bytes[1] off of resources.pak's on-disk size (which is especially helpful on Android). R=agrieve@chromium.org,smaier@chromium.org BUG= 619091 [1] https://docs.google.com/spreadsheets/d/1iHF05utMcECxc8tb3ziHQlEJmXlk98-PFWhkGoY545Q/edit Review-Url: https://codereview.chromium.org/2152143002 Cr-Commit-Position: refs/heads/master@{#419110} [modify] https://crrev.com/9dcdbe36c99b33e9205338cf58e9a38620b365e9/chrome/browser/browser_resources.grd [modify] https://crrev.com/9dcdbe36c99b33e9205338cf58e9a38620b365e9/chrome/browser/ui/webui/history_ui.cc
,
Oct 5 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/00508fbc7b679b71cb87a62a20efd4c0977f530b commit 00508fbc7b679b71cb87a62a20efd4c0977f530b Author: agrieve <agrieve@chromium.org> Date: Wed Oct 05 15:58:31 2016 gzip compress more chrome:// pages Specifically: - chrome://bluetooth-internals - chrome://invalidations - chrome://offline-internals - chrome://predictors - chrome://profiler - chrome://usb-internals - chrome://site-engagement This shrinks ChromePublic.apk by 58kb. BUG= 619091 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation Review-Url: https://codereview.chromium.org/2388303005 Cr-Commit-Position: refs/heads/master@{#423173} [modify] https://crrev.com/00508fbc7b679b71cb87a62a20efd4c0977f530b/chrome/browser/browser_resources.grd [modify] https://crrev.com/00508fbc7b679b71cb87a62a20efd4c0977f530b/chrome/browser/resources/invalidations_resources.grd [modify] https://crrev.com/00508fbc7b679b71cb87a62a20efd4c0977f530b/chrome/browser/ui/webui/bluetooth_internals/bluetooth_internals_ui.cc [modify] https://crrev.com/00508fbc7b679b71cb87a62a20efd4c0977f530b/chrome/browser/ui/webui/engagement/site_engagement_ui.cc [modify] https://crrev.com/00508fbc7b679b71cb87a62a20efd4c0977f530b/chrome/browser/ui/webui/invalidations_ui.cc [modify] https://crrev.com/00508fbc7b679b71cb87a62a20efd4c0977f530b/chrome/browser/ui/webui/offline/offline_internals_ui.cc [modify] https://crrev.com/00508fbc7b679b71cb87a62a20efd4c0977f530b/chrome/browser/ui/webui/predictors/predictors_ui.cc [modify] https://crrev.com/00508fbc7b679b71cb87a62a20efd4c0977f530b/chrome/browser/ui/webui/profiler_ui.cc [modify] https://crrev.com/00508fbc7b679b71cb87a62a20efd4c0977f530b/chrome/browser/ui/webui/usb_internals/usb_internals_ui.cc
,
Oct 13 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6a700b0e8bddef30af43a7ceaff4ad8dd4693a1b commit 6a700b0e8bddef30af43a7ceaff4ad8dd4693a1b Author: dbeam <dbeam@chromium.org> Date: Thu Oct 13 22:45:23 2016 Gzip compress chrome://accessibility resources BUG= 619091 R=agrieve@chromium.org Review-Url: https://codereview.chromium.org/2399553002 Cr-Commit-Position: refs/heads/master@{#425197} [modify] https://crrev.com/6a700b0e8bddef30af43a7ceaff4ad8dd4693a1b/content/browser/accessibility/accessibility_ui.cc [modify] https://crrev.com/6a700b0e8bddef30af43a7ceaff4ad8dd4693a1b/content/browser/webui/web_ui_data_source_impl.cc [modify] https://crrev.com/6a700b0e8bddef30af43a7ceaff4ad8dd4693a1b/content/browser/webui/web_ui_data_source_impl.h [modify] https://crrev.com/6a700b0e8bddef30af43a7ceaff4ad8dd4693a1b/content/content_resources.grd
,
Oct 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/00508fbc7b679b71cb87a62a20efd4c0977f530b commit 00508fbc7b679b71cb87a62a20efd4c0977f530b Author: agrieve <agrieve@chromium.org> Date: Wed Oct 05 15:58:31 2016 gzip compress more chrome:// pages Specifically: - chrome://bluetooth-internals - chrome://invalidations - chrome://offline-internals - chrome://predictors - chrome://profiler - chrome://usb-internals - chrome://site-engagement This shrinks ChromePublic.apk by 58kb. BUG= 619091 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation Review-Url: https://codereview.chromium.org/2388303005 Cr-Commit-Position: refs/heads/master@{#423173} [modify] https://crrev.com/00508fbc7b679b71cb87a62a20efd4c0977f530b/chrome/browser/browser_resources.grd [modify] https://crrev.com/00508fbc7b679b71cb87a62a20efd4c0977f530b/chrome/browser/resources/invalidations_resources.grd [modify] https://crrev.com/00508fbc7b679b71cb87a62a20efd4c0977f530b/chrome/browser/ui/webui/bluetooth_internals/bluetooth_internals_ui.cc [modify] https://crrev.com/00508fbc7b679b71cb87a62a20efd4c0977f530b/chrome/browser/ui/webui/engagement/site_engagement_ui.cc [modify] https://crrev.com/00508fbc7b679b71cb87a62a20efd4c0977f530b/chrome/browser/ui/webui/invalidations_ui.cc [modify] https://crrev.com/00508fbc7b679b71cb87a62a20efd4c0977f530b/chrome/browser/ui/webui/offline/offline_internals_ui.cc [modify] https://crrev.com/00508fbc7b679b71cb87a62a20efd4c0977f530b/chrome/browser/ui/webui/predictors/predictors_ui.cc [modify] https://crrev.com/00508fbc7b679b71cb87a62a20efd4c0977f530b/chrome/browser/ui/webui/profiler_ui.cc [modify] https://crrev.com/00508fbc7b679b71cb87a62a20efd4c0977f530b/chrome/browser/ui/webui/usb_internals/usb_internals_ui.cc
,
Nov 4 2016
[Automated comment] removing mislabelled merge-merged-2840
,
Nov 16 2017
Issue 129760 has been merged into this issue.
,
Nov 16 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82 commit f31ae65e2f6064f39d95371bb2ac32d68bfe7b82 Author: Reilly Grant <reillyg@chromium.org> Date: Thu Nov 16 20:40:04 2017 Enable gzip compression of WebUI resources on iOS This patch copies the logic for loading gzipped WebUI resources from the non-iOS WebUI loading code and disables the exception in Grit that prevented resources from being gzipped in the iOS build. This reduces the size of resources.pak on iOS by 243 kB and starts to unify more of the WebUI infrastructure between iOS and other platforms. Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs Change-Id: I24473ea75b172210060723afa219281d0937c398 Bug: 619091 Reviewed-on: https://chromium-review.googlesource.com/770325 Commit-Queue: Reilly Grant <reillyg@chromium.org> Reviewed-by: Jochen Eisinger <jochen@chromium.org> Reviewed-by: Eugene But <eugenebut@chromium.org> Cr-Commit-Position: refs/heads/master@{#517173} [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/chrome/browser/ui/webui/physical_web/physical_web_ui.cc [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/components/resources/physical_web_ui_resources.grdp [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/content/browser/BUILD.gn [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/content/browser/webui/url_data_manager_backend.cc [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/content/test/BUILD.gn [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/chrome/app/resources/ios_resources.grd [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/chrome/browser/ui/webui/crashes_ui.cc [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/chrome/browser/ui/webui/flags_ui.cc [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/chrome/browser/ui/webui/gcm/gcm_internals_ui.cc [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/chrome/browser/ui/webui/net_export/net_export_ui.mm [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/chrome/browser/ui/webui/ntp_tiles_internals_ui.cc [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/chrome/browser/ui/webui/omaha_ui.cc [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/chrome/browser/ui/webui/physical_web_ui.cc [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/chrome/browser/ui/webui/signin_internals_ui_ios.cc [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/chrome/browser/ui/webui/sync_internals/sync_internals_ui.cc [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/chrome/browser/ui/webui/version_ui.mm [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/web/ios_web_resources.grd [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/web/public/url_data_source_ios.h [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/web/public/web_ui_ios_data_source.h [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/web/test/test_resources.grd [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/web/webui/url_data_manager_ios_backend.mm [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/web/webui/url_data_source_ios.mm [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/web/webui/url_data_source_ios_impl.cc [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/web/webui/url_data_source_ios_impl.h [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/web/webui/web_ui_ios_data_source_impl.h [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/web/webui/web_ui_ios_data_source_impl.mm [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ios/web/webui/web_ui_mojo_inttest.mm [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/tools/grit/grit/node/base.py [modify] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ui/base/BUILD.gn [rename] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ui/base/webui/i18n_source_stream.cc [rename] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ui/base/webui/i18n_source_stream.h [rename] https://crrev.com/f31ae65e2f6064f39d95371bb2ac32d68bfe7b82/ui/base/webui/i18n_source_stream_unittest.cc
,
Nov 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/89a01f157a882f2a8d7cc36d323ef6d62645ae29 commit 89a01f157a882f2a8d7cc36d323ef6d62645ae29 Author: Reilly Grant <reillyg@chromium.org> Date: Fri Nov 17 22:04:28 2017 Compress shared WebUI resource files This reduces the size of an official build of ChromePublic.apk by 403 KiB and the size of resources.pak on a Chrome OS build by 1.46 MiB. Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation;master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs Change-Id: I7f6502cc17136dd15a2b3e026bbe5c84e3fb337d Bug: 619091 Reviewed-on: https://chromium-review.googlesource.com/770550 Reviewed-by: Eugene But <eugenebut@chromium.org> Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org> Reviewed-by: Michael Giuffrida <michaelpg@chromium.org> Reviewed-by: Xiyuan Xia <xiyuan@chromium.org> Commit-Queue: Reilly Grant <reillyg@chromium.org> Cr-Commit-Position: refs/heads/master@{#517578} [modify] https://crrev.com/89a01f157a882f2a8d7cc36d323ef6d62645ae29/chrome/browser/resources/welcome/dice_welcome/welcome.css [modify] https://crrev.com/89a01f157a882f2a8d7cc36d323ef6d62645ae29/chrome/browser/resources/welcome/welcome.css [modify] https://crrev.com/89a01f157a882f2a8d7cc36d323ef6d62645ae29/chrome/browser/ui/webui/welcome_ui.cc [modify] https://crrev.com/89a01f157a882f2a8d7cc36d323ef6d62645ae29/components/proximity_auth/webui/DEPS [modify] https://crrev.com/89a01f157a882f2a8d7cc36d323ef6d62645ae29/components/proximity_auth/webui/proximity_auth_ui.cc [modify] https://crrev.com/89a01f157a882f2a8d7cc36d323ef6d62645ae29/content/browser/webui/shared_resources_data_source.cc [modify] https://crrev.com/89a01f157a882f2a8d7cc36d323ef6d62645ae29/ios/web/webui/shared_resources_data_source_ios.h [modify] https://crrev.com/89a01f157a882f2a8d7cc36d323ef6d62645ae29/ios/web/webui/shared_resources_data_source_ios.mm [modify] https://crrev.com/89a01f157a882f2a8d7cc36d323ef6d62645ae29/tools/polymer/txt_to_polymer_grdp.py [modify] https://crrev.com/89a01f157a882f2a8d7cc36d323ef6d62645ae29/ui/base/webui/web_ui_util.cc [modify] https://crrev.com/89a01f157a882f2a8d7cc36d323ef6d62645ae29/ui/base/webui/web_ui_util.h [modify] https://crrev.com/89a01f157a882f2a8d7cc36d323ef6d62645ae29/ui/webui/resources/cr_components/cr_components_resources.grdp [modify] https://crrev.com/89a01f157a882f2a8d7cc36d323ef6d62645ae29/ui/webui/resources/cr_elements_images.grdp [modify] https://crrev.com/89a01f157a882f2a8d7cc36d323ef6d62645ae29/ui/webui/resources/cr_elements_resources.grdp [modify] https://crrev.com/89a01f157a882f2a8d7cc36d323ef6d62645ae29/ui/webui/resources/polymer_resources.grdp [modify] https://crrev.com/89a01f157a882f2a8d7cc36d323ef6d62645ae29/ui/webui/resources/webui_resources.grd
,
Jan 18 2018
Some new discussion started here: https://bugs.chromium.org/p/chromium/issues/detail?id=789933 https://chromium-review.googlesource.com/c/chromium/src/+/853500 The same topic and the need of creating one general approach. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by jbudorick@chromium.org
, Jun 10 2016