Function in web_ui_util.cc is no longer used to get the
text_defaults_md.css resource for shared resources. Keep our override
for the function resouce because it's still used in several places.
Additionally, copy over our text_defaults_md.css via util.js so that
it's used when chromium GRD is auto generated.
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/ba11d6dc4a110c2c456eb453b445832847230b5e
commit ba11d6dc4a110c2c456eb453b445832847230b5e
Author: dpapad <dpapad@chromium.org>
Date: Wed Feb 24 18:26:57 2021 +0000
WebUI: Replace SharedResourcesDataSource with a regular WebUIDataSource.
SharedResourcesDataSource was a custom class directly subclassing
URLDataSource (and used for serving chrome://resources URLs). By doing
so it included a lot of duplicated functionality for code that is
already available in regular WebUIDataSourceImpl subclasses, for
example
- Registering resources
- Registering loadTimeData strings
- Calculating mime types based on a path's extension
- Locating and serving WebUI files from pak files
- Overriding specific CSP policies
By using a regular WebUIDataSourceImpl a lot of duplicated code is
deleted. Moreover, WebUIDataSourceImpl is a more mature class, that is
heavily used across WebUI. For example this CL helped discover a bug
where $i18n{...} string placeholders where incorrectly used in
cr_components/ (fixed at r854879) because of CHECK()s that did not
exist in SharedResourcesDataSource.
In order to support chrome://resources/css/text_defaults.css $i18n{...}
replacements, web_ui_url_loader_factory.cc has been modified to perform
$i18n{...} replacements in CSS files too (previously only done for HTML
files, and conditionally for JS files).
Bug: 1179207
This is mandatory now upstream, otherwise the build will fail.
Chromium change:
https://chromium.googlesource.com/chromium/src.git/+/aa0c216c0236a118e51e0e4f07c8ee48667c7004
commit aa0c216c0236a118e51e0e4f07c8ee48667c7004
Author: dpapad <dpapad@chromium.org>
Date: Mon Feb 1 19:01:58 2021 +0000
Grit: Force all generated files to specify a resource_path attribute.
- Remove Grit logic to replace the gen folder with "@out_folder@"
when generating GritResourceMap keys.
- Instead add an assertion to ensure that generated files use
|resource_path| to specify keys for the GritResourceMap.
Note that the assertion is applied only in grd files that specify
an output type of "resource_map_source".
Also remove an alias in shared_resources_data_source.cc that was needed
for android_clang_arm builds (see explanation at [1]). The workaround
is no longer necessary as the files in question are added to grd files
using generate_grd(), and they are leveraging |resource_path|, and not
using the output folder location as GritResourceMap keys anymore.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=1020284#c45
Fixed: 1171239
Chromium change:
https://chromium.googlesource.com/chromium/src.git/+/b8cc59e15f318760e3992cd98cf5508b7796dd59
commit b8cc59e15f318760e3992cd98cf5508b7796dd59
Author: rbpotter <rbpotter@chromium.org>
Date: Tue Dec 22 01:33:14 2020 +0000
optimize_webui: Support external_paths mapping argument
- Refactor rollup plugin now that all chrome://resources files are
read from the same folder to use a map and helper instead of
duplicating logic for the Polymer and resources cases.
- Add new external_paths argument to the rollup plugin, allowing URL
prefixes to be mapped to directories.
- Use this argument to pass the necessary mappings for resources and
Polymer files to the plugin, instead of hardcoding the paths there
- Allow the argument to also be extended by invokers, so that
individual WebUIs can add their own mappings in addition to the
defaults for chrome://resources and chrome://resources/polymer/v3_0.
Bug: 1156829
https://source.chromium.org/chromium/chromium/src/+/efc282784459e1ec69a524d901d8694cce5230c5
commit efc282784459e1ec69a524d901d8694cce5230c5
Author: rbpotter <rbpotter@chromium.org>
Date: Tue Sep 1 04:37:15 2020 +0000
Web UI: Add preprocessed resources and use in rollup
Preprocess all shared JS module resources into:
<root_gen_dir>/ui/webui/resources/webui_preprocessed
and read all these resources from this directory when bundling with
rollup.
Bug: 1071641
Also, adjusted br_elements resource names to prevent collision with
cr_elements resource names.
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/456a8a60d47b523f9ff7b6c5d54ff051e7003963
commit 456a8a60d47b523f9ff7b6c5d54ff051e7003963
Author: dpapad <dpapad@chromium.org>
Date: Thu Nov 12 06:42:27 2020 +0000
WebUI: Auto-generate ui/webui/resources/css/ resources grdp file.
Moving most IDR_WEBUI_CSS_* resources from webui_resources.grd to
the auto-generated webui_generated_resources.grd.
Resources that rely on flattenhtml=true are not affected, since
|flattenhtml| is purposefully not supported by generate_grd().
Bug: 1132403
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/aa298022efdaaf3637faf741990ad311f5978cee
commit aa298022efdaaf3637faf741990ad311f5978cee
Author: Wei Li <weili@chromium.org>
Date: Tue Oct 27 18:37:21 2020 +0000
Remove SetFocusForPlatform() API
SetFocusForPlatform() was used to override Button and its subclasses'
focus behavior. Now the platform default focus behavior becomes Button's
default setting. This API is no longer needed.
Bug: 1001103
This made sense when Chromium's //c/b/resources/tools/rollup_plugin.js
considered that source JS files could come from both the sources and
the generated directories, but this is no longer the case as all those
JS files are under <root_gen_dir>/ui/webui/resources/webui_preprocessed
now, so we need to update Brave's code to adapt to this new scenario.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/efc282784459e1ec69a524d901d8694cce5230c5
commit efc282784459e1ec69a524d901d8694cce5230c5
Author: rbpotter <rbpotter@chromium.org>
Date: Tue Sep 1 04:37:15 2020 +0000
Web UI: Add preprocessed resources and use in rollup
Preprocess all shared JS module resources into:
<root_gen_dir>/ui/webui/resources/webui_preprocessed
and read all these resources from this directory when bundling with
rollup.
Bug: 1071641
Chromium change:
https://chromium.googlesource.com/chromium/src/+/315b3141c41dbdddb3d8b168cf7867b74df11904
commit 315b3141c41dbdddb3d8b168cf7867b74df11904
Author: Tommy Steimel <steimel@chromium.org>
Date: Wed Jun 17 21:22:32 2020 +0000
Make cr_elements available in chrome-untrusted:// frames
- This CL makes updates polymer.py to always produce scheme-relative
URLs when converting HTML imports that contain "chrome://" to JS
imports.
- This also changes optimize_webui.py and rollup_plugin.js to handle
scheme-relative URLs.
This allows chrome-untrusted:// frames using Polymer 3 to use
cr_elements/ without hitting failures due to absolute
chrome://resources URLs inside cr_elements/ imports.
Bug: 1051835, 866236
- Move everything to es-modules rather than html imports. There are a number of ways these can be generated: completely manual or automatic via `polymer_modulizer` or `js_modulizer`. Template html can then optionally be 'included' in to the JS file via `html_to_js`.
- With a single patch in to a module requested by all webui pages (web_ui_listener_behavior.js), brave's polymer_overriding.js can inject any neccessary global template modifications.
chrome://resources/cr_elements/ is now redirected so a relative path
needs to be used to get import from {} statement generated.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/8afa59b8f3d39ca65c111e49b19475516f01c7a2
commit 8afa59b8f3d39ca65c111e49b19475516f01c7a2
Author: Demetrios Papadopoulos <dpapad@chromium.org>
Date: Thu Jan 23 22:39:02 2020 +0000
WebUI: Port cr_components/certificate_manager to Polymer3.
- Add polymer_modulizer() and js_modulizer() rules as necessary to
generate a Polymer3 version of certificate-manager at build time.
- Remove unnecessary settings.Router references from tests.
- Auto-generate tests for the Polymer3 version (and update Settings
WebUI data source as needed)
- Add a missing assertion in js_modulizer.py that was discovered.
The Polymer3 version will be used by follow up CLs to migrate
chrome://certificate-manager and eventually chrome://settings
Bug: 1042558
- Rollup plugin is used for polymer v3
- Needed to add `polymer_modulizer` calls in BUILD.gn for modules referenced
- Added dep to the main 3 places which need this done (bookmarks/downloads/history)
- Solved missing CrSearchFieldBehavior reference
Chromium change:
https://chromium.googlesource.com/chromium/src/+/5d96fd383c53023c8972b2af9e607a31e62e8112
commit 5d96fd383c53023c8972b2af9e607a31e62e8112
Author: rbpotter <rbpotter@chromium.org>
Date: Fri Oct 25 01:56:27 2019 +0000
WebUI: Update optimize_webui() to handle Polymer3
Use rollup along with existing Polymer CSS build and Uglify tools
to bundle Polymer 3 pages in optimized builds.
This will be used by the extensions Web UI in a followup CL:
https://chromium-review.googlesource.com/c/chromium/src/+/1817293
Bug: 965770
By moving third-party fonts to the standard directory pattern for
third-party code in Chromium, we don't have to teach the license
script about our extra path.
* Use `@media (prefers-color-scheme: dark)` instead of `[dark]`.
* Turn on kWebUIDarkMode feature on all platforms - this feature now
gates the above @media directive.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/6e5a6179e616f62bb575b1cd5e1c078fd4a0bc47
commit 6e5a6179e616f62bb575b1cd5e1c078fd4a0bc47
Author: Dan Beam <dbeam@chromium.org>
Date: Fri Jun 7 21:44:46 2019 +0000
WebUI Dark Mode: update ui/webui to use @media queries
This changes the implementation around how dark mode is queried in CSS.
Bug: 965811
https://chromium.googlesource.com/chromium/src/+/f0a7e117061208634ebf1cff20c4253db53f1b7a
commit f0a7e117061208634ebf1cff20c4253db53f1b7a
Author: Dan Beam <dbeam@chromium.org>
Date: Fri Jun 7 18:40:58 2019 +0000
Make @media (prefers-color-scheme:) respect features::kWebUIDarkMode
while on chrome:// URLs
This allows us to use this mechanism in CSS:
@media (prefers-color-scheme: dark) {
}
to vary styles for Chrome web UI in dark mode while also disabling via
feature on certain platforms.
This unblocks us from migrating to the @media query (from the existing
[dark] attribute syntax) and later removing a bit of JS/C++ custom code
in favor of simply using the web platform.
R=futhark@chromium.org
BUG=965811
https://bugs.chromium.org/p/chromium/issues/detail?id=965811
* Replaced all occurrances of paper-button with cr-button.
* Removed paper_button_style.css.
* Added cr-button template style overrides to polymer_overriding.
* Patched polymer.html to include polymer_overriding and removed
polymer_overriding from brave_settings_overrides.
Chromium change:
Removal of paper-button:
https://chromium.googlesource.com/chromium/src/+/03d1652fb3cecd58f02ce783da958901cc2c31db
commit 03d1652fb3cecd58f02ce783da958901cc2c31db
Author: Esmael El-Moslimany <aee@chromium.org>
Date: Wed Jul 10 21:58:43 2019 +0000
WebUI: remove paper-button from third_party/polymer
Bug: 967793
Bug link with other commits:
https://bugs.chromium.org/p/chromium/issues/detail?id=967793
Fix https://github.com/brave/brave-browser/issues/5330
This fixes the issue with the downloads page due to a timing issue with the download item list rendering. That list uses iron-list via downloads/manager.html. The list will not render if the list component's element does not have either a width or a height (via flex, explicit css, or otherwise). In the course of the page load, there is specific timing where the page has width *just* before the items that are provided to the iron-list are rendered. This timing could definitely be improved upstream.
The download page asks the toolbar whether the search field is clear or not (so that the download page knew to render the entire list of downloads, or one filtered to the search term).
Somehow having an extra polymer template to ensure had rendered before our toolbar would return the correct value for this caused this timing to be off, and so when the iron-list was first rendered it did not do anything because there was no width or height to the element. At any time later, forcing the iron-list to re-evaluate it's rendering ability by resizing the window (since it subscribes directly to this event), or running `downloadsList.fire('iron-resize')` directly, would caus the list to render successfully.
Interestingly, there is an attempt in the upstream code to force firing of this event to prevent this issue, but it actually happens too early, or rather it does not listen to all the properties that could cause this issue: https://cs.chromium.org/chromium/src/chrome/browser/resources/downloads/manager.js?rcl=044ab765751f0d98b0758a6de98265797ee67793&l=122
mkarolin