Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Problem/Motivation
There is visual BUG in progress bar when the status is 0%. The progress bar looks like it is broken or something.
There is also "dropping out" visual mistake if percentage goes over 100%.
Proposed resolution
The solution is to add overflow: hidden;
to the .progress_track class.
Comment | File | Size | Author |
---|---|---|---|
#38 | Screenshot 2020-08-04 at 11.55.20 AM.png | 130.16 KB | samiullah |
#38 | Screenshot 2020-08-04 at 11.54.56 AM.png | 136.78 KB | samiullah |
#35 | 2254785-35.patch | 979 bytes | komalk |
#35 | progress-bar-with-1%.png | 12.67 KB | komalk |
#35 | progress-bar-with-3%.png | 13.81 KB | komalk |
Comments
Comment #1
Dragan Eror CreditAttribution: Dragan Eror commentedWill take care of it...
Comment #2
Dragan Eror CreditAttribution: Dragan Eror commentedHere is the patch.
Comment #3
Dragan Eror CreditAttribution: Dragan Eror commentedHere are screenshots after patch is applied...
Comment #4
LewisNyman CreditAttribution: LewisNyman commentedI swear we had a min width for the progress a one point... anyway I've added a min and max width so this can never happen again. Thanks for the report.
Comment #5
rodrigoaguileraI tested this by inserting this html
and playing with the width
everything looks as it should
Comment #7
LewisNyman CreditAttribution: LewisNyman commented4: progress-bar-2254785-4.patch queued for re-testing.
Comment #8
rodrigoaguileraComment #10
rodrigoaguilera4: progress-bar-2254785-4.patch queued for re-testing.
Comment #11
LewisNyman CreditAttribution: LewisNyman commentedSetting back to RTBC post broken HEAD
Comment #12
Dries CreditAttribution: Dries commentedCommitted to 8.x. Thanks.
Comment #13
Bojhan CreditAttribution: Bojhan commentedIt looks like this broke something else, initializing is now at 100% - this should be at 1%
Comment #14
LewisNyman CreditAttribution: LewisNyman commentedWe shouldn't of removed the initial width setting because that's how the batch api works, here's a patch that adds it back.
Comment #15
Bojhan CreditAttribution: Bojhan commentedHmm, interesting - could we try this with 1% and/or 2% it seems like the 3% is a little bit too much for an initial state.
Comment #16
Dragan Eror CreditAttribution: Dragan Eror commentedBefore you do that test how it looks 1% width on 320px wide screen. If necessary maybe good option is to start at 3% for mobiles and use media query to set 1% on bigger screens.
Comment #17
Bojhan CreditAttribution: Bojhan commentedThat part shouldn't be affected by mobile width. That doesn't change the roundness?
Comment #18
BerdirKeep in mind that we are using the progress bar in two very different ways here. One is core/batch API, which is dynamic and if batch API already treats "batch started" as 3% or something then that might make totally sense for it.
The screenshot however is from Search API, which uses the progress bar as a static information to tell you, how many of your nodes or whatever have been indexed already, it does *not* change while you look at that page and if none are indexed, then it is 0%. not 1% or 3% but 0% :)
Seems to me as a backend developer that we should either make the way we display it in core batch API specific and use an additional css class from a batch wrapper or something so that it only applies there or we should simply override it in Search API to behave the way we want it to... like being a static instead of moving, which is still being discussed in corresponding Search API issue ;)
Comment #19
Dragan Eror CreditAttribution: Dragan Eror commentedYes, there is also way to leave it 0% by adding
overflow: hidden;
CSS property.Like it is in patch from #2254785-2: Progress bar 0% or over 100% visual BUG
You can see results by looking screenshots in #2254785-3: Progress bar 0% or over 100% visual BUG
Comment #20
Bojhan CreditAttribution: Bojhan commentedActually for Search API , you would want a "static" bar the one we have animates. I think there is already an open issue for that.
I'd like to still push this to 2 or 1%.
Comment #21
jhedstromNeeds work based on #20.
Comment #22
LewisNyman CreditAttribution: LewisNyman commentedComment #35
komalk CreditAttribution: komalk at Srijan | A Material+ Company for Drupal India Association commentedPatch #14 is failed to apply to 8.9x.
Change it from 3% to 1%.
Attached screenshot for the reference.
Comment #36
samiullah CreditAttribution: samiullah at Salsa Digital commented@komalkolekar please add steps to test this one on clean install of drupal 8.9x
Comment #37
komalk CreditAttribution: komalk at Srijan | A Material+ Company for Drupal India Association commentedStep to reproduced mentioned in #5
https://www.drupal.org/project/drupal/issues/2254785#comment-8787351
Comment #38
samiullah CreditAttribution: samiullah at Salsa Digital commentedLooks good
Applied patch #35
Can be moved to RTBC if no more code review is needed
Comment #41
quietone CreditAttribution: quietone at PreviousNext commentedThis was committed in #12 do Drupal 8.x, re-opened because of a regression. That regression was fixed in #2486431: Progress bar starts at 100%. But this stayed open and was set to NW for #20, which doesn't match the title or the scope. And to avoid two commits for the same issue number I am moving the follow on work toa new issue.
New issue created, #3270657: Reduce the min-width and width for the progress bar and credit moved there. Restoring meta data to when this was fixed.
Cheers.