Downloads not being instantly displayed under "brave://downloads" until window resize #5330
Comments
kjozwiak
added
bug
feature/user-interface
rebron
added
the
priority/P3
|
The issue is reproducible on Windows 10 x64
|
|
Reproduced in a debug version with 76.0.3809.72 on a Mac. |
|
@bsclifton, didn't get a chance to take a closer look, assigning to you. |
|
Reproduced in Version 0.67.123 Chromium: 76.0.3809.87 (Offizieller Build) (64-Bit) on Linux. Also, another user reports the same at community: https://community.brave.com/t/downloads-view-seems-to-be-broken-in-the-latest-dev-version/72838 |
|
Reproduced in 0.67.123 Chromium: 76.0.3809.87 (Official Build) (64-bit) on Windows 10 |
|
Reproduced in Version 0.68.121 Chromium: 76.0.3809.100 (Official Build) beta (64-bit), on Windows 8.1. |
|
Happens every time I open the downloads tab. Version 0.67.125 Chromium: 76.0.3809.100 (Official Build) (64-bit) |
Tbh, this is a good temporary solution. LOL |
|
Still exists in Version 0.69.107 Chromium: 76.0.3809.100 (Official Build) beta (64-bit). |
|
@rebron @bsclifton we should reprioritize this as a +1 from https://twitter.com/kameshkotwani/status/1163347365379502080 |
rebron
added
priority/P2
… polymer dom-if template Fix brave/brave-browser#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
|
Verified passed with
Verification passed on
Verification PASSED on
Verification passed on
|
Test plan
See brave/brave-core#3212
Description
Downloads are not being displayed under
brave://downloads/instantly at times. You'll need to resize the current browser window for the entries to be displayed.Couldn't reproduce it with
76.0.3809.71 (Official Build) beta. Might be a regression with C76 as every channel but release is affected.Steps to Reproduce
Extra Small File (5MB)&Small File (10MB))Show Allvia the download barActual result:
Expected result:
Downloads entries should be instantly displayed under
brave://downloads/without the need to resize the browser window.Reproduces how often:
100% reproducible using the above STR.
Brave version (brave://version info)
Version/Channel Information:
0.66.101 Chromium: 75.0.3770.1420.67.114 Chromium: 76.0.3809.620.68.108 Chromium: 76.0.3809.620.69.77 Chromium: 76.0.3809.62Other Additional Information:
76.0.3809.71 (Official Build) beta.Miscellaneous Information:
CCing @brave/legacy_qa @rebron @bsclifton
The text was updated successfully, but these errors were encountered: