Closed Bug 44126 Opened 25 years ago Closed 24 years ago

status bar progress meter craziness

Categories

(SeaMonkey :: UI Design, defect, P3)

Product:
SeaMonkey
Component:
UI Design
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: mozilla, Assigned: law)

References

Details

(Keywords: polish, Whiteboard: [nsbeta3-])

[some crasher is really getting to me... this is the third time I've written this bug report. should mean it's really well written, right?] This bug brought to you by my unusual genius for browser torture. Believe me, "progress meter craziness" is pretty accurate... Short form: When a frame/page changes while dragging the scroll bar, the progress meter can go crazy, reporting wildly inaccurate values for file completion. To reproduce: --Load up Moz and start choffmann's browser buster from Debug --Wait and watch until you get a page with a reasonably long scrollbar. --About 22 seconds after the page changes (the timer is set for 25 seconds) grab the scroll-handle thingy with the cursor and drag it slowly down. A few seconds before the page should change, drag the page up slowly. --When the page changes, hold onto the handle and keep moving it. Watch the status meter (barbershop thingy) in the bottom left (on the modern skin at least). What happens: the status meter goes into gray-bar-with-percentage-readout mode and starts displaying values from 100% to over 9000%. The numbers change quickly (I think because of each image download.) Eventually the craziness settles down, and goes away. What should happen: Nothing insane, and at least the values shouldn't go >100%. Notes on reproducing: This is likely a tough bug to reproduce. I've been practicing and can't get it at will or even on a regular basis. I'm also not sure that I have a complete handle on how to do it. The procedure above described is the best I can get towards actually describing how it happens. I can't state that this is exactly how to reproduce or the only way to get this problem. In fact, I would bet against both statements. (I've seen it happen recently in a totally unrelated situation.) It seems to happen most reliably on the C|Net pages in the browser buster, and I suspect that caching reduces reproducibility. In any case, it'll have to be felt out. Other mitigating factors: I can currently only test this on a laptop with a touchpad, so I don't know if this is easier or harder to do with a mouse. I'm also on a LAN connection (as I would think the Netscapers here are, at least). And it occurs to me I should disable the gfx scollbars and test that. Platform/builds: This happens on 2000062720, and I discovered it on the previous day's build. I'll test it on Linux soon, but right now can only confirm NT (cursed be its name).
Sorry -- fixing title to be less insane.
Summary: progress meter crazinessprogress meter craziness → progress meter craziness
over to XPToolkit. I was unable to reproduce in my 10 minutes of trying. leaving unconfirmed for now. adding qawanted keyword (looking for help reproducing)
Assignee: asa → trudelle
Component: Browser-General → XP Toolkit/Widgets
QA Contact: doronr → jrgm
I don't see this either (62908). Adding qawanted, as I assume asa meant to.
Keywords: qawanted
I can't reproduce this as described, but I did see some >100% numbers in yesterdays build. However, the progressmeter passively displays what it is told to display, so the whacky numbers are coming from somewhere in the application code. Over to don for reassignment.
Assignee: trudelle → don
Component: XP Toolkit/Widgets → XP Apps
QA Contact: jrgm → sairuh
I also just noticed numbers > 100% also, and I saw it go from higher numbers to lower numbers (i.e. 87% -> 69%)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
would this be a dup of bug 42442?
No. This bug is (I believe) a problem of the wrong values being passed from the navigator.js (?) into the progressmeter widget. No painting problems, etc.; just the wrong number. The other bug seems more like Worksforme, because I can't reproduce it. Can the reporter?
I've tried a few times recently and haven't gotten it to do it again. I'll give it the old college try tomorrow and if I can't reproduce, I'll give WORKSFORME my official blessing. (If anyone cares.)
I've managed to reproduce the bug several times on 2000071120 on NT today. The best way to do it, I think, is a quick down-and-up motion right as the page starts to reload. I'm also pretty sure that what happens is that the images report wrong (very high) numbers when you do it right (or wrong, I guess.) The numbers change with the images, so I think this works best on non-cached sites with lots of small images on a fast connection. I'm not sure what a slow connection would show. This time around I'm having the most luck with the ZDNet pages.
Component: XP Apps → XP Apps: GUI Features
Summary: progress meter craziness → download progress meter craziness
law
Assignee: don → law
*** Bug 45575 has been marked as a duplicate of this bug. ***
*** Bug 45593 has been marked as a duplicate of this bug. ***
*** Bug 46172 has been marked as a duplicate of this bug. ***
*** Bug 46289 has been marked as a duplicate of this bug. ***
Just a note, this is still happening to me. I found a reproducable testcase: go to http://www.diburim.co.il. When it loads select View > Character Coding > More > Visual Hebrew. Just now I got ~1100% loaded Also adding nsbeta3 and polish keywords, and updating platform/os to all (from the 2 bugs I just marked dups of this)
Keywords: nsbeta3, polish
OS: Windows NT → All
Hardware: PC → All
I am seeing this too..definitely..on all platforms today . This is a bad problem.
I've reproduced this on Mac build 2000072608. With home.netscape.com. I didn't mess with the scrollbar or handle any other chrome. i just loaded the page and watched the numbers get all silly. I also noticed the apparent decreasing of the percentages mentioned earlier as well. upping severity form 'minor' as this is loss of function and it looks like you don't necessarily have to jump thorugh hoops to make this happen.
Severity: minor → normal
QA Contact: sairuh → claudius
*** Bug 46889 has been marked as a duplicate of this bug. ***
*** Bug 47370 has been marked as a duplicate of this bug. ***
Try http://bugzilla.mozilla.org/showattachment.cgi?attach_id=12271. The progress meter will go over 35000% !!!
nav triage team: ok, so we can't do simple math, or we're just REALLY fast 'cause we say so! change summary to be more descriptive
Summary: download progress meter craziness → status bar progress meter craziness
Whiteboard: [nsbeta3-]
*** Bug 48249 has been marked as a duplicate of this bug. ***
*** Bug 48502 has been marked as a duplicate of this bug. ***
*** Bug 48531 has been marked as a duplicate of this bug. ***
*** Bug 48573 has been marked as a duplicate of this bug. ***
Should be marked mostfreq.
I noticed this bug when loading a CNet news story. I wasn't doing anything funky with the scrollbars, only thing possibly weird I did was start loading the page while another was loading. So, one was loading, I had a URL on the clipboard and middle-clicked the window to load the new one (using Linux), and while loading that one I saw the craziness. It got up to 999% then dropped into the 400's then 200's then 100's.
*** Bug 55141 has been marked as a duplicate of this bug. ***
Netscape Nav Triage Team - during our triage session, someone noted that this had been fixed - Bill, can you clarify?
I think this is invalid now, since percentages are no longer shown.
gonna make it WFM
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
and VERIFIED WFM
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.