Meta data display (bug 1995) needs space in the status bar. Meta data display needs to function fully when a page has been fully loaded. The progess meter is only needed when the page hasn't been fully loaded. Therefore, reusing the space taken by the progress meter for meta data display seems like an obvious choice. Curretly the progess meter is on the left in the status bar. If it appeared and disappeared there, it would cause the primary status bar text being drawn is different locations depending on the visibility of the progress meter. That would make the UI look unstable. I suggest moving the progress meter to the right in the status bar. That way it can vanish without causing any repositioning of the primary status bar text.

I agree on the first part. The progress meter space should be reused once the page is loaded. But putting it on the right would break the general left-to-right flow of status from general to specific. See: ___________________________________________________________ X [#####():::] 13 kb of 18 kb read, 3 seconds remaining "|""|""""""""""""|""""""""""""""""""""""""""""""""""""""""" | | +- status text (specific status) | +-------------- progress meter (general status) +----------------- hourglass(/throbber?) (very general status) Then when the page is loaded, we could still reuse the space: ___________________________________________________________ [] http://bugzilla.mozilla.org/votehelp.html [English :^] "|""|"""""""""""""""""""""""""""""""""""""""""""|"""""""""" | | +- metadata | +--------------------------------------------- more metadata +------------------------------------------------ document validity icon Is it acceptable to require the user to wait for the page to finish loading (or for them to press Stop), before we show metadata? If so, then the progress meter should probably stay where it is.

Can we not just have the progress meter similar to Netscape 4.x on the Mac where the progress meter takes up the entire status bar and lives under the status text (can't really describe it but ask someone who has a mac if you can take a look and see what I mean)

I don't like Mac 4.x's approach. It makes status text quite difficult to see, especially when progress is indeterminate (you're trying to read black text on an animated barbershop of light and dark gray).

Left-to-right flow from general to specific makes some sense, but if the progress meter vanishes in that scenario, the position of the metadata display moves and makes the UI look unstable. No, I don't think meta data should only be displayed once the page has fully loaded. If meta data is displayed with more general data on the left, a progress meter on the right would obscure only less important meta data while the page is loading. After loading the progress meter could vanish leaving room to more meta data and at the same time the general meta data display wouldn't need to move.

Reassigning from bdonohoe to hangas

Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...

updating to new owner. sorry for the spam.

I was wrong, Henri was right. Having the progress bar on the left would make status text jump around between loading and not-loading states. So, the progress bar should stay where it is, but it should disappear completely (as in {display: none}) when nothing is loading. This will make more space for status text, and make the browser window less cluttered. --> XP Apps: GUI.

taking

per comment 8, removing dependency. this bug is no longer about moving the statusbar, only about hiding/showing it

Comment on attachment 92269 [details] [diff] [review] Better patch After applying this patch, the progressmeter does not progress anymore. You can fix it by removing the hidden="true" attribute in <statusbarpanel> I have no idea why xul is behaving that way but I have not investigated further. In addition, Mail/News also uses the statusbar progress meter. I think you should apply the same fix for consistency. Could you check all the places where it is used?

>After applying this patch, the progressmeter does not progress anymore. Can't reproduce that here. For me, the progressbar behaves the same with or without the patch (other than that it's hidden if unused with the patch)... Mailnews: Hm... I'll look into that

Now I do see the progress-meter working with a new profile. Boh... Sorry for the false alarm.

still have to check for other occurences

Comment on attachment 93111 [details] [diff] [review] mailnews part ah... this includes the fix for another bug... ignore the clearly unrelated lines :)

ok, I think I got them all now. ready for review.

Comment on attachment 92269 [details] [diff] [review] Better patch r=chanial@noos.fr (new mail address) I don't feel myself comfortable to review the Mail/News pathces since I never touched them

sspitzer, could you review the two mailnews patches on this bug?

bienvenu, could you review the two mailnews patches on this bug?

I'd need to run with this patch to make sure everything is working OK for mail/news, and I don't have a working tree at the moment. I'll try to get to it as soon as I can, but it might be a few days.

now rediffed to not include the unrelated changes (which have been checked in in the meantime)

Christian, can you attach some screen shots? cc jglick, as we'll need her approval since this is a UI change.

note, we've also got a progress meter in the compose window, advanced message search, advanced addressbook search.

notice the missing progressmeter if, otoh, the progressmeter is in use, the window looks as before want a screenshot of the subscribe window as well?

sspitzer, hm, right; looks like my lxr search was incomplete. I'll make a patch for them too... but tomorrow.

you might want to wait for jglick to comment before doing that, to see if she agrees with this change to the UI.

>So, the progress bar should stay where it is, but it should disappear >completely (as in {display: none}) when nothing is loading. This will make more >space for status text... I agree. This change is ok with me.

removing browser from summary, as this affects mailnews as well.

that's interesting. advanced addressbook search does not seem to ever use the progressmeter, even though it is shown. jglick: is it therefore ok to always hide it? it does not serve a function anyway. (this is easier to code. if it will ever be working, it can be shown again)

this should be the last dialog, pending a reply to comment 34; sspitzer, could you review the patches here now?

>advanced addressbook search does not seem to ever use the progressmeter, even >though it is shown. is it therefore ok to always hide it? it does not serve a >function anyway. Yes. Would be nice to have it working at some point though.

sorry for the delay. I'll do some reviews and testing over the next few days. I think this will make it into mozilla 1.2

*** Bug 79926 has been marked as a duplicate of this bug. ***

-> default owner sspitzer, I gave up caring about my UI patches... so there's no need to review this anymore.

At one point the progress meter was allowed as a direct child of the status bar. That would have allowed this bug to be fixed with a line of CSS...

nsbeta1- per the nav triage team.

issue 2002120408, progress bar at bottom right of browser window remains filled in a great majority of the time, you get no true indication of page loading progress. Tme morphing Mozilla icon at the upper right doesn't morph any longer, just sits there, a dull blue-gray rectangle. harvey r. savage

Comment on attachment 93842 [details] [diff] [review] subscribe dialog If subscribe had been correctly written to use StartMeteors and StopMeteors which attachment 95312 [details] [diff] [review] fixes then this wouldn't be necessary.

Comment on attachment 95716 [details] [diff] [review] msg compose window Nits: use .hidden instead of setAttribute, and hide the panel before resetting the progressmeter.

Comment on attachment 95721 [details] [diff] [review] message search window Bug 229818 will obsolete this patch too.

Comment on attachment 93842 [details] [diff] [review] subscribe dialog Patch bitrotted.

Comment on attachment 95721 [details] [diff] [review] message search window Patch has bitrotted.

Comment on attachment 95312 [details] [diff] [review] mailnews main window part Patch has "bitrotted".

Comment on attachment 92269 [details] [diff] [review] Better patch hmm, this totally does not apply anymore...

Comment on attachment 140177 [details] [diff] [review] browser patch (checked in) >+ // Show the progress meter >+ this.statusPanel.removeAttribute("hidden"); > // Turn the progress meter and throbber off. >+ this.statusPanel.setAttribute("hidden", "true"); Nit: Please use .hidden here.

Comment on attachment 140177 [details] [diff] [review] browser patch (checked in) sr=bzbarsky with neil's nit addressed

On WinXP, with mozilla 1.7b, there is no progressmeter in modern and in classic the height is 1px off (see next attachment). I've updated the target milestone to 1.8a, because mozilla 1.2 is long past and we need this for the 1.8 cycle and removed keyword nsbeta1- "nsbeta1- This keyword will be added to bugs which the Netscape evaluation team has rejected for the next Netscape release." There will be no future Netscape release, so it is now useless to still have such keyword anyway. Christian, my Q for you is: "Are you still working on this bug?" If yes, why is the bug status set to NEW and if not, why is it (still) assigned to you? Cheers, /HJ

Oops, attachment 144572 [details] is a PSP file (default setting of Paint Shop Pro 8) Here's an JPG version of the same image.

I'd appreciate it if people would not change the target milestone of my bugs I'll need to look at the mailnews patches again (browser part is checked in), and I intend to do that at some time, yes. What do you mean with "both a hidden and displayed progressmeter"? it is obviously displayed in that screenshot?

(In reply to comment #57) > I'd appreciate it if people would not change the target milestone of my bugs Sorry Biesi, but I am missing the logic of this. What is your point? What is the logic of using mozilla 1.2beta? Mozilla 1.2beta is ancient history by now and developers, like me, can hijack your non resolved bugs, if they want to! > I'll need to look at the mailnews patches again (browser part is checked in), > and I intend to do that at some time, yes. Guess you don't need help with this bug, but that was my point, but I'll rather pass now. > What do you mean with "both a hidden and displayed progressmeter"? it is > obviously displayed in that screenshot? True, not a perfect screenshot, but it is an combined screenshot. Just look at the off-line icon. Look at the shading, obviously one pixel off.

(btw, you didn't remove nsbeta1- earlier, doing that now) (In reply to comment #58) > Sorry Biesi, but I am missing the logic of this. What is your point? What is the > logic of using mozilla 1.2beta? Mozilla 1.2beta is ancient history by now and > developers, like me, can hijack your non resolved bugs, if they want to! it's a way to organize my buglist... ok well, right now it's somewhat unorganized, but anyway :) > Guess you don't need help with this bug, but that was my point, but I'll rather > pass now. Oh, if you want to take a look at updating the mailnews patches, that would be cool. I don't know when I'll find the time for this. I am sorry for assuming that you just wanted to know the state of this bug, rather than work on it :) as for why this bug is NEW... I like to use NEW vs ASSIGNED as a way to keep track of whether the bug already has a mostly-ready patch or not. this one hasn't :) > True, not a perfect screenshot, but it is an combined screenshot. Just look at > the off-line icon. Look at the shading, obviously one pixel off. Ahh. I finally see your point :) it would be nice though not to make this bug a general dumping ground for progressmeter issues :) as in, your bug would be a different bug I'd say. hm... it may have been caused by the patch here, because we now change whether progressbar appears. but anyway... please file a new bug, cc me, and mention the bug# here. thanks. sorry if comment 57 was sounding impolite/rude, I certainly didn't mean it to be.

I think this caused regression bug 235871. In particular, in some themes, the progress meter was the tallest thing in the status bar. With this patch, this means the window resizes when the status bar appears and disappears.

neeed to look at backing this out on the 1.7 branch....

need to look at backing this out on the 1.7 branch....

can someone put together a patch to back out on the 1.7 branch?

> can someone put together a patch to back out on the 1.7 branch? I can look into doing that. I'm just looking at bonsai now to see what was landed (browser and mailnews, or just browser).

christian, should the TM be set to 1.8a, since I'm about to back this out of 1.7? (see bug #235871) also, it doesn't look like you checked in the mail parts of this patch, just the mozilla/xpfe parts. is that correct?

(In reply to comment #66) > christian, should the TM be set to 1.8a, since I'm about to back this out of > 1.7? (see bug #235871) ok, well, setting to something by which I maybe finish this up.... > also, it doesn't look like you checked in the mail parts of this patch, just the > mozilla/xpfe parts. > > is that correct? Yes. The mailnews part don't have reviews yet, and some need updating. they wouldn't need to be backed out anyway I think, since the problem is just that webpages are continuously reloading, right?

>> also, it doesn't look like you checked in the mail parts of this patch, just the >> mozilla/xpfe parts. >> >> is that correct? > >Yes. The mailnews part don't have reviews yet, and some need updating. >they wouldn't need to be backed out anyway I think, since the problem is just >that webpages are continuously reloading, right? you might be right about that. but let's be safe and keep the mailnews ones for 1.8 and not land them in 1.7 final. if you have cycles, can you also review (I already have r=neil) my backout patch in bug #235871?

christian, thanks for the review. I've backed out this fix from the 1.7 branch, but the trunk still has it so the bug remains open. I've asked asa to figure out if we should fix mozilla or let all theme developers know they need to fix their themes. clearning the blocker 1.7 as this is not part of 1.7

Comment on attachment 138749 [details] [diff] [review] mailnews main window, unbitrotted With .hidden

-> default owner, doesn't look like I'm going to get to updating the mailnews patches anytime soon...

Comment on attachment 189104 [details] [diff] [review] mailnews main window, unbitrotted This appears to be the same as attachment 138749 [details] [diff] [review] and as per comment 70 I prefer .hidden instead of set or removeAttribute.

Comment on attachment 189104 [details] [diff] [review] mailnews main window, unbitrotted OK. I did not notice that comment.

set/removeAttribute() -> .hidden

Can someone check attachment 189176 [details] [diff] [review] in? Neil?

Pretty sure this broke the Subscribe window (IMAP/NNTP): Error: this.statusPanel has no properties Source File: chrome://messenger/content/mailWindow.js Line: 435

Comment on attachment 189537 [details] [diff] [review] Fix for regression (checked in) why not hidden="true"?

(In reply to comment #79) >(From update of attachment 189537 [details] [diff] [review] [edit]) >why not hidden="true"? It sets shown during startup anyway (although for news it loads synchronously so you don't notice...)

Comment on attachment 93842 [details] [diff] [review] subscribe dialog This will be fixed by Attachment 189537 [details] [diff]

what makes us show the search window progress bar, i.e., remove the hidden attribute?

@bienvenu: it's the conde in mailWindow.js, which also does this for the subscribe dialog in the regression fix @neil: could you check in the regression fix?

*** Bug 301585 has been marked as a duplicate of this bug. ***

Comment on attachment 189805 [details] [diff] [review] Message search window (checked in) Okay, looks good. Let's get these two into the lizard, too...

Is there more work to do, here? If not, let's resolve this.

There is more work: /editor/ui/composer/content/TextEditorAppShell.xul, line 162 -- <statusbarpanel class="statusbarpanel-progress"> /extensions/inspector/resources/content/statusbarOverlay.xul, line 8 -- <statusbarpanel class="statusbarpanel-progress"> /mailnews/base/search/resources/content/FilterListDialog.xul, line 225 -- <statusbarpanel class="statusbarpanel-progress">

> /editor/ui/composer/content/TextEditorAppShell.xul, line 162 -- > <statusbarpanel class="statusbarpanel-progress"> AFAICT, this is only used in a (mostly defunct) debug test page? > /extensions/inspector/resources/content/statusbarOverlay.xul, line 8 -- > <statusbarpanel class="statusbarpanel-progress"> This file is referenced by DOMI's jar.mn only, so it's unused and could be removed anyway? > /mailnews/base/search/resources/content/FilterListDialog.xul, line 225 -- > <statusbarpanel class="statusbarpanel-progress"> True.

I didn't check that any further yet. CCing the module owners of composer and inspector. daniel,caillon: Can the progressmeters in the last comment be removed?

Matthias, Are you still working on this ?

This has been mostly fixed a long time ago, any remaining issues should be filed as followup bugs.