New issue
Advanced search Search tips

Issue 889611 link

Starred by 2 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

grit gzipped_resource_file_map_source prevents resources from being filtered (200kB?)

Project Member Reported by mthiesse@chromium.org, Sep 26

Issue description

Using WebUI as the primary example (since they're over 200kB binary size on Android), webui_resources_map.cc prevents Android's generate_resource_whitelist from filtering unused WebUI resources because all of the IDR IDs are referenced.

The problem is really more complicated than that, because without WebUIs resource map, a bunch of actually used resources might be filtered because WebUI doesn't use the IDR ids for its resources, and somehow just uses the original filenames in its html/js.


 
Cc: agrieve@chromium.org
Labels: Binary-Size

Comment 2 Deleted

>  WebUI doesn't use the IDR ids for its resources, and somehow just uses the original filenames in its html/js.

Are you familiar with how chrome://resources URLs are implemented? Even if the IDR_* is not directly appearing in the code, these are used to implement chrome://resources URLs and are used by [1]. I think you should have a look at it, and see if that invalidates any of your assumptions.


[1] https://cs.chromium.org/chromium/src/content/browser/webui/shared_resources_data_source.cc
FWIW, the proper way of filtering out unused resources on Android is to modify the corresponding grd files to exclude them. Having said that, it's not very easy to determine what is used and not used on Android.

Example of a large part of WebUI resources that are exluded on Android can be seen at https://cs.chromium.org/chromium/src/ui/webui/resources/webui_resources.grd?l=526-530 (which basically includes all Polymer related resources).

Comment 5 Deleted

I would hesitate to say "proper way" - as you say yourself it's not easy to determing what is and is not used, and things will inevitably go stale over time. Would be better if we could figure out an automated way to do this like with non-mapped resources.
> if we could figure out an automated way to do this like with non-mapped resources

What do you mean by non-mapped resources?

The way JS/HTML/CSS/PNG etc files are included in to the final Chrome binary is done via GRIT (and has always been that way as far as I can remember). There is a lot of code to support all that infra. In short:

 1) Build time: Source files are pre-processed via GRIT to accomodate various <if expr> <include> and other tags.
 2) Build time: They are gzipped (sometimes) and combined to .pak files (which is a Chrome invented format) containing multiple source files.
 3) Run time: Pak files are unpacked and brought to memory.
 4) Run time: C++ backend code serves those files from chrome://resources

This is a simplified version of what actually goes on.

I think it would help a bit more if you describe what you are trying to achieve overall, instead of directly drilling down to a specific file.

Having said that, I don't think there is an easy automated way of determining what is used and not used. For example chrome://version is a WebUI page that exists on Android. All transitive chrome:// deps of that page are needed. You would need to chase all those down, as well as any other WebUI pages on Android to figure out what is definitely not needed.
I'm certainly not suggesting there's an easy way. It would require us doing something like enumerating all of the DEPS for chrome://version in chrome/browser/ui/webui/version_ui.cc (repeat for every piece of WebUI for every platform), and working around the map referencing the IDR values so that they can be stripped if unused.

What I'm referring to by non-mapped resources are all grd files that don't output type="gzipped_resource_file_map_source" and can be stripped by generate_resource_whitelist on Android.
To attempt to be perfectly clear, I'm not intending to prescribe an exact solution to the problem here, I'm neither knowledgeable in webUI nor grit.

I'm pointing out that we're including a lot of unused resources on Android, I'm pointing out why it happens, and I'm pointing out that it's not good.
> I'm pointing out that we're including a lot of unused resources on Android

Is this speculation, or do you have a list of files that you can confidently say that they are unused in Android? If so, there is a way to exclude them.
 

> I'm pointing out why it happens, and I'm pointing out that it's not good.

I don't understand your explanation. Basically the bug title makes it sound that gzipped_resource_file_map_source is somehow responsible for the situation. To me it seems completely unrelated.

The reason for potentially unused files being included in Android is that a lot of WebUI pages depend on  chrome://resources/... files and it is not easy to gather all transitive deps and tell  what is not needed.
> Is this speculation, or do you have a list of files that you can confidently say that they are unused in Android? If so, there is a way to exclude them.

I'm pretty confident that IDR_WEBUI_ANALYTICS_JS is unused on Android. I don't have a list, because as we both know it's difficult to determine whether something is really unused.

>I don't understand your explanation. Basically the bug title makes it sound that gzipped_resource_file_map_source is somehow responsible for the situation. To me it seems completely unrelated.

This bug isn't intended to be specific to WebUI. There are other grit files that use gzipped_resource_file_map_source, and they also prevent any of their resources, even if unused, from being stripped.

I could be wrong, but as far as I can tell, gzipped_resource_file_map_source is the only reason that WebUI resources aren't already being stripped on Android - if the map didn't exist, I think the resources would erroneously be stripped even when used. Maybe that was intentionally designed that way, but it looks accidental and hacky to me.

>The reason for potentially unused files being included in Android is that a lot of WebUI pages depend on  chrome://resources/... files and it is not easy to gather all transitive deps and tell  what is not needed.

Right, we've already agreed on this part. I'm suggesting that this is a problem that should be fixed.

Sign in to add a comment