Closed Bug 32331 Opened 25 years ago Closed 25 years ago

progress meter paints the "barber pole" outside its boundaries

Categories

(Core :: XUL, defect, P5)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jwbaker, Assigned: pavlov)

References

Details

(Keywords: helpwanted)

Attachments

(2 files)

screenshot of progressmeter without double buffer
1.58 KB, image/png
Details
second indicator
28.07 KB, image/jpeg
Details
Build 2000031615 i686-pc-linux-gnu. Navigate to a page that takes a while to load (slashdot.org comes to mind). While the barber-shop-pole status meter thing is twirling, resize the window. Notice that the status meter now extends beyond its intended boundaries, and partially extends behind the status text.
Typo in the summary, sorry.
Summary: Resizing window corrupts corrupts status meter → Resizing window corrupts status meter
Unable to confirm this in windows 3/17 build under win98 (I crash when resizing while big pages are loading). Changing component to XPToolkit Widgets.
Assignee: cbegle → trudelle
Component: Browser-General → XP Toolkit/Widgets
QA Contact: asadotzler → jrgm
After initially failing to reproduce this, I did manage to see this a few times (in two flavours: barber-pole extends to cover text to its left; 2) progressmeter "disappears"). I found the "New Checkins" link on www.mozilla.org to be a good page to reproduce this (but it's hit and miss). 2000-03-17-08 mozilla build linux rh6.0
duplicate reported and jrgm@netscape.com has reproduced. Marking this one Confirmed to bring it into appropriate RADARs.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 32413 has been marked as a duplicate of this bug. ***
Looks gone in 2000032005. Was a fix checked in?
I can't reproduce it in 32006 either. resolving as wfm. Please reopen if it comes back.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Bah! The reason we can't reproduce it in 032005 and 032006 is because the bug exists only on the trunk, and those two builds are both nb1b. So consider fixed in the branch, but broken on the trunk. Reopening.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I can reproduce the barber-pole overrun easiliy, but nothing else. reassigning to evaughan as p5 for m18. putting on helpwanted radar
Assignee: trudelle → evaughan
Status: REOPENED → NEW
Keywords: helpwanted
Priority: P3 → P5
Target Milestone: --- → M18
Mass moving M18 bugs to M19
Target Milestone: M18 → M19
*** Bug 35341 has been marked as a duplicate of this bug. ***
Add to summary to help finding dups.
Summary: Resizing window corrupts status meter → Resizing window corrupts status meter (progress meter)
Seems bug 33927, bug 35239 and bug 35189 are also duplicates of this one.
Bringing over my comments from 35189 regarding very related bugs: bug 21639 "Progress meter paints three times for each update" (Marked fixed 2000-01-14) bug 29118 "Extra refreshes while drawing the progress bar" (Open. Assigned to: kmcclusk@netscape.com)
*** Bug 33927 has been marked as a duplicate of this bug. ***
This appears to be Linux only (based on the 20000410nn builds for mac, win32 and linux -- can reproduce easily on Linux, but cannot on mac/win32).
*** Bug 35437 has been marked as a duplicate of this bug. ***
*** Bug 35584 has been marked as a duplicate of this bug. ***
*** Bug 35723 has been marked as a duplicate of this bug. ***
This is not just due to resizing. If you have a relatively small window, a similar things happen.
Heck, it happens to me when the window is _maximized_, and the bar overwrites the "Transferring data..." often after the page first loads.
In linux, this happens when the window is maximized, iconified, shrunk, etc. etc....basically whenever the geometry of the window is changed or reloaded, i guess. the barber pole bleeds to the right and sometimes down -- it appears a bit like it was before the barber pole was moved into a box...except of course that it's not moving =)
oh gee...come to think of it, it also happens often when the file/edit/etc. menus are used or when the scroll bars appear (i'm using native scrollbars by the way). so i suppose it happens without any resizing as well
as far as i can see there are actually TWO barberpoles there. One is the animated one - in the right place. The other one is not animated and is located approx. 1 cm. to the right of "the real thing" and a few pixels down. It on occation refreshes when pages are loading. Cover mozilla with another app during download and raise moz to top: there it is. During the loading of a page, the statusfield displaying URL will often refresh, and cover SOME but not all of the so called "bleeding". It would seem there is actually another instance of the barberpole in the code somewhere, offset as described.
*** Bug 36225 has been marked as a duplicate of this bug. ***
Updating summary from "Resizing window corrupts status meter (progress meter)". This can occur without resizing. (Linux only).
Summary: Resizing window corrupts status meter (progress meter) → progress meter paints the "barber pole" outside its boundaries
and i was wrong: it's one and the same barberpole.. and it's huge. But the area where it animates is limited. The rest is a part of the same gif however. This can be seen when you stumble across those pages where the barberpole never stops and the STOP button doesnt work either. If you repeatedly click stop, all the time, the area "outside the window to the reguolar animation" will refresh so quick you see it's actually one and the same animated gif. I use 2000-041816 now, and found a good site to test this: http://www.digi.no Why is the barberpole-gif so big? Because of various resolutions etc? If it had had the dimensions of the "Border" it's supposed to animate within, this wouldn't have been a problem. But if that border has different dimensions for different screen resolutions, it's of course a problem as long as only one mutual gif is used. The angles on that gif's poles indicate to me it can be stretched without loss of quality though? (45 degrees). Or has a strech already occured, causing this weird look? (I'm running at 1024*768)
I'm having the same overrun (to the right about 80 pixels and down about 5), but it goes away after resizing the window. It seems the redraw after resize does the progress correctly. Only the initial drawing of the window is placing the progress bar lines in the wrong place.
The barber pole is done with a simple tiled animated background image. I think when linux draws the image its not clipping correctly when it tiles. Assigning to Pav for investigation.
Assignee: evaughan → pavlov
This is shown very well when you turn double buffering off, progress meter draws over buttons below it all the time. I attach png how it looks without double buffer.
Well today there ARE two progress meters there - insame position. Saw that in todays stripped down version, build ID 2000-042518 When the page starts loading the vertially striped barber-pole starts spinning. Then it changes to the old indicator (?), with a percent count on top. Attaching screenshot.
Attached image second indicator —
*** Bug 37869 has been marked as a duplicate of this bug. ***
*** Bug 38032 has been marked as a duplicate of this bug. ***
*** Bug 38032 has been marked as a duplicate of this bug. ***
has this bug been fixed on the 2000051208 build? The barberpole seems to stay within the boundaries for me.
yes, this was fixed with the new tiling code
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Verified fixed on Linux Build 2000051308
verified
Status: RESOLVED → VERIFIED
*** Bug 40824 has been marked as a duplicate of this bug. ***
Is the picture of the second indicator "outside boundaries"? Because I still see it the way the 2nd attached picture shows it in current nightly.
all seems OK now. (2000-060420)
Love the new progress meter :-)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: