Closed Bug 628654 Opened 14 years ago Closed 14 years ago

Show connecting / waiting / loading status messages in small overlay on top of content at bottom of screen

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 4.0b11
Tracking Flags:
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: beltzner, Assigned: dao)

References

(Depends on 3 open bugs, Blocks 1 open bug)

Details

(Whiteboard: [hardblocker][fx4-fixed-bugday])

Attachments

(2 files, 1 obsolete file)

patch
(deleted), patch
Gavin
: review+
Details | Diff | Splinter Review
screenshot
(deleted), image/png
Details
The status bar was removed, and there is a concern that the browser feels slower for that removal since messages about page load status were removed with it. This bug is about restoring those messages (as they appeared in Firefox 3.6) to Firefox 4. Let's not scope creep - please file additional bugs for: returning link hover messages to this spot, calling this new widget the "status bar" and returning the menuItem in the View Menu for it, etc. // Design Like seen in Chrome, provide a grey-background, rounded-corner overlay on top of content anchored to the bottom-right (or bottom-left in RTL locales) of the screen in which the page load status messages will appear. This overlay should disappear when the page is done loading. It's fine if this obscures content while messages exist, and even if the mouse cursor falls on top of or beneath it. // Implementation Notes After talking to various engineers, I suspect the safest and easiest way to implement this would be a new XUL window in the browser <deck>, though some felt that a new top-level window would be required. If we create a top-level window, we need to make sure it doesn't have an impact on a11y or mouse drivers and other programs which index our window heirarchy - see bug 130078 for some of the issues that we've encountered when messing with that sort of thing.
blocking2.0: --- → betaN+
Whiteboard: [hardblocker]
Please ping MarcoZ for accessibility QA as soon as viable.
Attached image screenshot (obsolete) (deleted) —
I'd think just sticking a box in the tab would be the way to go. It's quite easy as shown in the screenshot. Not sure why one would think a separate window is necessary. Is there some functionality about this that I'm missing other than per-tab status messages?
The status messages are handled globally, so I don't think we need/want one widget per tab.
True, but I assume it would only show the messages associated with the current tab, and show no status for background tabs that are loading?
Sure, but that was already handled for the status bar and most of that code should still be around.
Please keep in mind for systems using hardware acceleration a widget is not free perf wise, even though it's not terribly expensive.
Is bug 603777 now officially being moved to a future release or is it still being consider for Firefox 4??? There's been no recent change of status of bug 603777 to indicate what the official decision is since bug 628654 was filed.
Do we expect strings impact here?
No, we'd be re-using the strings that were in the code before, and remain in the code now AFAICT. That's why I didn't mark it [strings] :) re: bug 603777, quite right, I'm removing hard blocking status, moving to future. Though if this gets done quickly, then we can think about some of the "future" ideas I expressed in comment 0 where this widget becomes the "Status Bar" and when turned off, these status messages appear as proposed in bug 603777.
Neil: that's really exciting; can you post the WIP patch or proof of concept code that does that? Drew knows how to hook it back into the messages sent by the platform, and perhaps we can get an early first cut. Also adding shorlander for styling.
Blocks: 605409
Blocks: 628738
FWIW, we don't need OS level window widgets here, because we don't need to render this new piece of UI outside of our main window boundaries. So, I think discussions about what sorts of effects a new OS level window would have here are irrelevant.
(In reply to comment #11) > FWIW, we don't need OS level window widgets here, because we don't need to > render this new piece of UI outside of our main window boundaries. ... unless we want to do what Chrome does when the mouse pointer would overlap the overlay, which is to slide the overlay below the window.
I just stuck a box with some text in it inside the <stack> in tabbrowser.xml. Nothing particularly exciting. I was more interested in knowing what aspects were thought to require a separate widget. But Dao thinks there should only be one per window.
(In reply to comment #12) > ... unless we want to do what Chrome does when the mouse pointer would overlap > the overlay, which is to slide the overlay below the window. Unless we are OK with delaying our ship schedule by several weeks, I think we should keep this as simple as possible.
(In reply to comment #12) > (In reply to comment #11) > > FWIW, we don't need OS level window widgets here, because we don't need to > > render this new piece of UI outside of our main window boundaries. > > ... unless we want to do what Chrome does when the mouse pointer would overlap > the overlay, which is to slide the overlay below the window. Chrome does that because it displays link hover targets in the same box, and the link that the user hovers might be at the bottom left corner of the visible content area. We're not going to display link targets there, and by the analogy that we don't move any other piece of our UI based on the mouse pointer location, we don't need to do this here too. Let's keep the discussion focused on what we need to do to get this ready for Firefox 4. We can solve other problems later.
(In reply to comment #14) > (In reply to comment #12) > > ... unless we want to do what Chrome does when the mouse pointer would overlap > > the overlay, which is to slide the overlay below the window. > Unless we are OK with delaying our ship schedule by several weeks, I think we > should keep this as simple as possible. Indeed. I can cite half a dozen bugs where changes to our native widget structure broke some popular mouse driver or a11y tool that required some nasty hack or emulation on our part to fix. Changing our usage of native widgets on Windows at this point in the cycle is extremely risky because of all of this third party software.
Comment 0 said links hovered-over would be shown in the lower left. What changed that decision, other than the link being scrolled to the same real estate? That seems solvable without sliding. /be
(In reply to comment #16) > (In reply to comment #14) > > (In reply to comment #12) > > > ... unless we want to do what Chrome does when the mouse pointer would overlap > > > the overlay, which is to slide the overlay below the window. > > Unless we are OK with delaying our ship schedule by several weeks, I think we > > should keep this as simple as possible. > > Indeed. I can cite half a dozen bugs where changes to our native widget > structure broke some popular mouse driver or a11y tool that required some nasty > hack or emulation on our part to fix. Changing our usage of native widgets on > Windows at this point in the cycle is extremely risky because of all of this > third party software. Er, no... Using a native widget != changing our native widget structure. We would be using a XUL panel like I did here: http://en.design-noir.de/mozilla/linktarget-display/
(In reply to comment #17) > Comment 0 said links hovered-over would be shown in the lower left. What > changed that decision, other than the link being scrolled to the same real > estate? That seems solvable without sliding. Try reading it again, please. It specifically says let's not scope creep and to file other bugs for that. This is specifically about connecting / waiting / loading status. I'm really wondering why this suddenly has to be changed. These changes have been in the tree for months, and we want to ship by the end of next month. I can't see that happening if we suddenly want to completely change how we do this *again*. Remember folks, we are planning on shipping a Firefox 5.0 three months after 4.0, so 4.0 does not have to be perfect.
If using a XUL panel allows the flexibility for us or Add-Ons to put link targets there (which, yes, should be a separate bug) then that feels like the right choice. I am excited that we can do this without adding a new top level window - that's where the complexity/risk seemed to be coming from, by my estimation.
No longer blocks: 628738
Blocks: 541656
Shawn: sorry I misread comment 0. I was prone to do that because it does not line up with email about this issue, which specified the hovered-link on lower left outcome. The rest of your comment is misdirected if it's aimed at me -- I'm told that this bug is going to get fixed for Fx4 and (last I heard), so is the link hovering issue. Beltzner, what's the bug for link hovering? /be
(In reply to comment #21) > Beltzner, what's the bug for link hovering? > > /be Bug 541656
(In reply to comment #22) > (In reply to comment #21) > > Beltzner, what's the bug for link hovering? > > > > /be > > Bug 541656 That's a low bug number and no one has commented this year. Its summary is also slightly off. Is it really the bug? /be
(In reply to comment #23) > That's a low bug number and no one has commented this year. Its summary is also > slightly off. Is it really the bug? > > /be If you are referring to displaying the link URL at the bottom of the window instead of the right side of the location bar, yes. The bug was created over a year ago, as it was one of the options originally considered.
Being that it's too late to add strings, I would assume users won't get the option on whether they want to display this or not? I have no idea why we couldn't continue with the current implementation we've gone with and extend that by simply flashing "Connecting" and "Loading" on the right of the Awesome Bar. It's important to stress that Chrome's implementation of URL Preview and Connection Status isn't superior it's just more traditional. Which is why it's imperative that backtracking like this is done with prefs (even if hidden for the next release) in order to maintain innovative goals while enabling legacy users the ability to take comfort in a more traditional feel; as we done with tabs positioning. It should also be noted that many users of Firefox have decided to do so over Chrome, so while parity-Chrome can be good, Chrome-clone is far from it and actually saps confidence in the product, it's management and it's direction. Regarding the numbers we're seeing on Firefox Input Dashboard, there was recently a piece of Planet Mozilla which highlighted the reality of reviews and how they're generally very good or very bad in their very nature and generally always lean heavily towards very bad.
If we're going to show status messages (I don't think we should) in the Awesome Bar we should take care not to make it become jittery. If we end-align the text then the start of it will be jumping all over the place as the page load progresses, making it hard to read and probably annoying the user to no end. Better would be to pick a spot on the bar and have all status text start-align there, eliding text where needed. Of course, that would cause short texts to have some blank space at the end; maybe that can be made to look acceptable anyway? Even then, I think it's too in-your-face, so again, I don't think we should. Given the current (time, resource, no new strings) constraints, having a hovering status where the status bar used to be is the safest bet.
Let's first and foremost be clear that we don't _NEED_ to show status messages. It was the goal of a paid and qualified team to define a direction for this product and one of the directions for that product which this team created and I can only assume were professional enough to flesh out before presenting was to remove the status messages. To then go on to say that we should restore said status messages because the _perception_ of speed is affected doesn't make sense to me. The perception of speed versus what? What is the comparison to here? And why are we attempting to remedy it with smoke and mirrors as opposed to actually putting more resources into speeding up the real time loading of pages with bugs like bug 573948? There are a ton of bugs that could've/should've/would've increased speed, but due to time constraints didn't make the cut. The solution however is not paper over the cracks. I agree that adding more flashing/blinking to the status bar isn't the best solution. But you do not get to beta 10 before you decide to start backtracking on UI design. Especially for something like this. Which is for all intents and purposes available as an extension for those that want or even feel they need it.
Advocacy comments are not welcome, and just adding noise. Please stop. As per comment 0, we are *not* trying to change the nature of the status messages in this bug. That can be addressed in a follow-up bug, but to avoid scope creep, the scope of this bug is restricted to restoring the same set of status messages as existed in Firefox 3.6. Brendan: Frank duped the follow-up bug 628738 to the previously-filed and pretty-much-identical bug 541656. Neil: can we get that WIP, please? Or Dao, can you modify your patch from bug 541656 to hold the status messages? This is going nowhere without an implementation.
I don't have any patch or work in progress.
Assignee: nobody → dao
Attached patch patch (deleted) — — Splinter Review
Only tested on Linux, but the code and styling is identical across platforms. Notes on the default statuses: "Done" is removed, "Stopped" is currently commented out, "Timed Out" is still there. These are mostly arbitrary choices at this point.
Attachment #507340 - Flags: review?(gavin.sharp)
Attached image screenshot (deleted) —
Attachment #506747 - Attachment is obsolete: true
Dao, could you please attach an RTL screenshot as well?
How will this affect grooveshark? The playback buttons are right in that corner and the site regularly triggers the progress indicator while its loading ads and songs. At a brief glance it seems like you will still be able to hit the playback buttons but a good chunk of them might get cut off. Are we able to click through the status message?
Don't you think this is a screen waste for addonbar users? Showing a popup above the addonbar which popup can be put on that...
The add-on bar is a waste for most users. There was a larger design, only part of which was implemented. Should we take the add-on bar out too? Rather: please cut the chatter, comment 34 is advocacy via rhetorical questioning. /be
Comment 34 is right in that if you enable the add-on bar, this is less efficient than Firefox 3.6. We could fix this by displaying status messages in the add-on bar when it's visible. But this belongs in a separate bug or the newsgroups. It's basically what I originally implemented for link feedback in bug 541656 (because the status bar wasn't gone back then, so the overlay would only be used when the status bar was hidden). (In reply to comment #32) > Dao, could you please attach an RTL screenshot as well? It looks the same, attached to the right corner. (In reply to comment #33) > At a brief glance it seems like you will still be able to hit the playback > buttons but a good chunk of them might get cut off. Are we able to click > through the status message? The overlay changes sides when you hover over it.
Depends on: 629304
To address comment 33, other than going the top level widget/window route (in which case it could just move down, Chrome style), could we make the overlay hide when the user moves the mouse over it? And keep it hidden until the (top level) page loads?
We could do that, but comment 33 isn't currently an issue.
Comment on attachment 507340 [details] [diff] [review] patch >diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js >+/* > case Components.results.NS_BINDING_ABORTED: > msg = gNavigatorBundle.getString("nv_stopped"); > break; >+*/ Just remove this? >- msg = gNavigatorBundle.getString("nv_done"); And file a followup on removing the strings? Discussion in bug 605409 suggests that we probably want to add |role="status"| to the statuspanel's label. We can handle that in that bug as a followup, though. r=me with those addressed. I'm very upset at the process that led to this bug being filed and marked a hardblocker - I think it's incredibly broken. I don't think we should actually be taking this patch at all, but I don't think objecting with an r- would be particularly productive at this stage.
Attachment #507340 - Flags: review?(gavin.sharp) → review+
Depends on: 629626
http://hg.mozilla.org/mozilla-central/rev/7eac2da4ca5e
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b11
This appears to have introduced a new (near-perma-)orange in the tree, see bug 629628. I'm thinking of backing it out unless someone has a better suggestion fairly soon.
Depends on: 629628
Backed out for causing persistent orange: http://hg.mozilla.org/mozilla-central/rev/9962128c19d6
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #44) > A new patch was committed for this: > http://hg.mozilla.org/mozilla-central/rev/8432660873e0 ... with position:fixed instead of position:relative in order to not affect the content height.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
(In reply to comment #26) > If we're going to show status messages (I don't think we should) in the Awesome > Bar we should take care not to make it become jittery. If we end-align the text > then the start of it will be jumping all over the place as the page load > progresses, making it hard to read and probably annoying the user to no end. > Better would be to pick a spot on the bar and have all status text start-align > there, eliding text where needed. Of course, that would cause short texts to > have some blank space at the end; maybe that can be made to look acceptable > anyway? Even then, I think it's too in-your-face, so again, I don't think we > should. But it's okay that the links shown in the Awesome Bar still have this behavior? Wasn't the original intent to right align them at some fixed point so that the start position to read from never changes... or did that just get passed over at some point?
Looks awesome. Any chances to also make LINKs to look like this instead in location ? Because this place is more intuitive than looking on upper right, while ppl eyes in browsing look mostly on down-left side of the screen like for example this bug tracker... :)
(In reply to comment #47) > Looks awesome. > > Any chances to also make LINKs to look like this instead in location ? > Because this place is more intuitive than looking on upper right, > while ppl eyes in browsing look mostly on down-left side of the screen like for > example this bug tracker... :) https://bugzilla.mozilla.org/show_bug.cgi?id=541656 Try this add-on https://addons.mozilla.org/en-US/firefox/addon/link-target-display/ (by Dao:)
I am not impressed. If this is written into the final build, you can be sure my theme will write it right back out. If users want a status, they'd re-enable the bar down there. Otherwise, you should assume the user DOES NOT WANT.
How would they re-enable the status bar, exactly?
(In reply to comment #49) > I am not impressed. If this is written into the final build, you can be sure my > theme will write it right back out. If users want a status, they'd re-enable > the bar down there. Otherwise, you should assume the user DOES NOT WANT. I think there's a big difference between "DOES NOT WANT" and "HAS NO CHOICE IN THE MATTER". The author of the Status-4-Evar extension said that his will completely overwrite this change anyhow, so the argument can be made the other way. A much more important issue, I'll agree, is that the link hovers currently provide very limited visibility into the full URL, but a lot of those bugs to patch up the issues have been set to not blocking 4.0. Big potential security issue... sad. I'm fine with this change though.
(In reply to comment #50) > How would they re-enable the status bar, exactly? The newly named Add-on bar can be enabled in the single menu under Options or View>Toolbars in classic menu style. If that's enabled, it should be assumed the user wants things down there. If it isn't, they don't like it. I use an auto-hide taskbar in Windows, and having a state or objects of the UI down there has always been a major annoyance, because that's where I go for OS operations. Now that Firefox uses the Title bar for rendering, there's plenty of area up top for users that want it there, and the Add-on bar for those who want their UI below. I thought this had already been established as an aesthetic to follow by its very presence.
Blocks: 603594
Will there be an option to turn this off in about:config or the prefs dialog?
(In reply to comment #53) > (In reply to comment #50) > > How would they re-enable the status bar, exactly? > > The newly named Add-on bar can be enabled in the single menu under Options or > View>Toolbars in classic menu style. If that's enabled, it should be assumed > the user wants things down there. If it isn't, they don't like it. I use an > auto-hide taskbar in Windows, and having a state or objects of the UI down > there has always been a major annoyance, because that's where I go for OS > operations. Now that Firefox uses the Title bar for rendering, there's plenty > of area up top for users that want it there, and the Add-on bar for those who > want their UI below. I thought this had already been established as an > aesthetic to follow by its very presence. See comment 25, comment 27 and see comment 28. I'd say that all that's needed to be said on this issue has been said and a decision has been made which won't be changed.
Is it possible to set minimal width like it is in Chrome (~340px)? Dynamic width is very annoying...
In the current implement of status messages, if mouse hovers on the messages on left side, the messages is switched to right side. However, I seem that this implement is hard to use for wide-screen...? It is too big to move line of sight?
The loading indicator looks ugly with the text shadow. Please make it simple like Google Chrome.
Bug 629898 and bug 629899 filed for comments 58 and 59. For any other suggestions for improvements or bug reports, please file new bugs.
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b11pre) Gecko/20110129 Firefox/4.0b11pre This looks particularly bad when scrollbars are visible on the screen in smaller windows. Tested this on OSX, see screenshot. Is it not possible to have it float behind the horizontal scrollbar? http://i.imgur.com/zjUv0.png
Depends on: 629898
Depends on: 629923
Filed a follow up proposal: Bug 629925 - Return connection status to the left when mouse leaves the area
Depends on: 629925
Depends on: 629899, 629907
The problem is that all of these actions are non-intuitive and counter to the way the rest of the browser UI works. If you see a message and want more info you can normally hover over it to get a tooltip with more information. Trying to hover to get the tooltip and have it move away form the mouse does not seem to follow the design of the way most other browser elements work.
(In reply to comment #39) > I'm very upset at the process that led to this bug being filed and marked a > hardblocker - I think it's incredibly broken. I don't think we should actually > be taking this patch at all, but I don't think objecting with an r- would be > particularly productive at this stage. For the record (belatedly), I couldn't agree with Gavin more.
Is there at least ANY way to get rid of this totally useless overlay? Everything I need to is presented to me by the spinner icon in the according tab. I don't want anything down there, and don't even dare to put the url-on-hover down there.
(In reply to comment #66) > (In reply to comment #39) > > > I'm very upset at the process that led to this bug being filed and marked a > > hardblocker - I think it's incredibly broken. I don't think we should actually > > be taking this patch at all, but I don't think objecting with an r- would be > > particularly productive at this stage. > > For the record (belatedly), I couldn't agree with Gavin more. And the UX team agrees — we're not the ones that wanted this either, for the record. Just wanted to state it plainly here in the bug, since I have spoken to people at Mozilla asking why we suddenly changed our mind on this. We didn't. We also believe it was way too late in the process to take this, as opposed to fixing some of the rough edges in the existing implementation. That doesn't mean we shouldn't help out with making the current direction better, though. Unfortunately, it was not our decision to make (and let's not have the discussion of "why" in this bug) — we're trying to assist and help out with the current direction, to make it as good as possible, given the constraints.
Depends on: 629964
I filed a follow-up bug here, https://bugzilla.mozilla.org/show_bug.cgi?id=629915, to discuss improvements to this. New bug is to change status info overlay to display at top of screen on top of content, closer to the location bar.
This change essentially makes it impossible for anyone trying to do any kind of full-screen web app, such as they might be doing with our new fast fancy hardware accelerated graphics support. The notification bar shows up *all the time* when you do any kind of XHR request, and is incredibly distracting because it keeps blinking in and out. We made the decision very early on to remove the status bar; if we now want to bring back the status bar, let's do that, but let's not do this half-baked distracting thing. I very much agree with Gavin's sentiment in comment #39.
Blocks: 629783
Filed bug 629984 for the XHR portion of comment 70, and previously filed bug 629783 for not showing the floating status on about:addons.
No longer blocks: 629783
Depends on: 629783, 629915
We can disable this by default and make option in about:config This will be a good idea, less distracting for ppl who don't need this information
(In reply to comment #72) > We can disable this by default and make option in about:config > This will be a good idea, less distracting for ppl who don't need this > information That, please! But shouldn't you file another bug and link to it?
(In reply to comment #73) > (In reply to comment #72) > > We can disable this by default and make option in about:config > > This will be a good idea, less distracting for ppl who don't need this > > information > > That, please! But shouldn't you file another bug and link to it? Done Bug #629985
https://groups.google.com/d/topic/mozilla.dev.apps.firefox/1Rz8LO3qmpA/discussion My post is already behind the (excellent) action in the followup bugs, but I wanted to draw attention to it here to keep this resolved bug from accumulating advocacy comments. Beyond advocating for or against any decision, this post is about what might be called "process problems" that we must fix immediately. /be
Depends on: 630009
Depends on: 630079
Depends on: 630016
No longer depends on: 630016
Depends on: 630015
No longer depends on: 630015
Depends on: 630196
No longer depends on: 630196
Depends on: 630902
Depends on: 631192
Now that Bug 541656 and Bug 629898 have landed, the "small" overylay is no longer the width of the URL being loaded. http://imgur.com/7pZ4B.jpg I have filed Bug 631194 for this.
Depends on: 631298
Bug 631428 When the add-on bar is open, it doesn't look right to be taking up content space when there so much empty chrome right below it. Forgetting for the moment the history of these wanderings, if you compare 3.6 to 4.0, it just looks like link preview and progress messages have been arbitrarily moved out of the status bar (now add-on bar) and into content, for no discernible reason. The overlay makes sense when the status bar (add-on bar) is hidden, but not when it's visible.
I have verified that this bug is fixed on Firefox 4 Beta 11 on Linux x86_64.
Also verified by [:chaos] with a nightly.
Status: RESOLVED → VERIFIED
Whiteboard: [hardblocker] → [hardblocker][fx4-fixed-bugday]
Blocks: 599212
The "Done" status message has been removed, presumable because the overlay disappears when done, however if the overlay is not used (status-4-evar or if Bug 629304 is addressed), "Done" is a pretty significant status, and should be displayed, same as in 3.6
No longer depends on: 630902
(In reply to comment #77) > Bug 631428 > > When the add-on bar is open, it doesn't look right to be taking up content > space when there so much empty chrome right below it. > > Forgetting for the moment the history of these wanderings, if you compare 3.6 > to 4.0, it just looks like link preview and progress messages have been > arbitrarily moved out of the status bar (now add-on bar) and into content, for > no discernible reason. > > The overlay makes sense when the status bar (add-on bar) is hidden, but not > when it's visible. I agree. Also please don't move the link text to this overlay. It's awesome in the location bar.
> Also please don't move the link text to this overlay. It's awesome in > the location bar. Completely disagree, it's much more intuitive at the bottom. The current implementation in the status bar is pretty poor. I often find myself wondering why the chrome is flickering while I am hovering over links.
Depends on: 632626
Viewing websites that have images which changes by clicking the image gets incredibly irritating. Especially when the loader always appear on a dark background. Perhaps the address bar should just become the loader instead by using it like a loading bar. Please keep in mind to use a light colour so attention isn't always diverted each time it loads.
The recently added status bar seems very irritating. all of the time it is residing in the window, mostly blank! When hovering over a link, the destination appears in it. Initially, the text that appears have all the characters with bottom length (g, j, p, q, y, /, etc.) appear cropped. if the courser stay on the link, the text then render properly; this flickering behavior seems very awkward. There is no direct option (indirect, noo idea) to disable/hide this status bar. Applying persona, make it worse; the add-on bar (& other bars) get the look of persona but not this one. In some cases it become too dark (while the persona itself is light colored) The starting approach for this status bar was to implement a chrome style hovering, mini bar. Even the height of this bar is extra if displaying the status msg is compulsory for the speed issue, it can be done in the add-on bar [some add-on were implementing this feature after the old status-bar disappeared] as mentioned above, Firefox 5 is planned after 3 months; it would be much better if this status bar is delayed till it with full implementation [hover, mini..] this is my first ever post here, i m sorry if i hav entered some un-relevant comments here
Mike Wazowski: are you still seeing the status panel when clicking images in 4.0b11? I tried a few simple testcases and can't reproduce that, but if you do still see it, please file a bug on it with a test case or URLs to examples.
For me this "Connection Status" is a total showstopper in Chrome, it's so annoying and distracting changing size and jumping around as the pages load I can't use it. I love FF, FF4 is awesome but I'm really disliking this "enhancement". The connection status was fine where it was in the status/addon bar... why the need to fix something that isn't broken?
No longer depends on: 630009
why can't I have the status messages be displayed inside of add-on bar (if it is shown)? why did you make this element be separate? to waste more screen space?
The connection status overlay in FF 4.0b11 is really disturbing, if I have no chance to deactivate it. I think that the most users won't care about each particular element that is being loaded on a page. So I vote to remove the overlay by default and to re-introduce the green loading bar which has been beyond the adressbar in the nightly builds of FF 4 some time ago. Most users want to know whether and when a page loading is complete or not. My opinion is, that the overlay, which has been chosen as favorite solution, is confusing all lay people. That can not be a step towards usabilty.
I understand the desire to quickly resolve this issue and push out Fx4 "as-is" as quickly as possible. Before doing so, I believe that the status pop-up be integrated into the add-on bar when it is visible, and to retain the current behavior when it is not. That said, I am a very big proponent of the link text appearing in the address bar. There is absolutely no logic in displaying this text in the bottom of the screen, whereas once clicked, the new address will appear at the top of the screen. I firmly believe that this functionality should be restored as quickly as possible, albeit after Fx4's release as I have understood that this altered functionality has been causing undesired side-effects on some platforms. If these issues can be resolved, Firefox would ideally display the link text in this fashion, as well as the loading progress that René speaks of. I do not find the actual status messages to be relevant to the average user. Moreover, the popping up of the overlay is detrimental to the user experience.
(In reply to comment #88) > The connection status overlay in FF 4.0b11 is really disturbing, if I have no > chance to deactivate it. > > I think that the most users won't care about each particular element that is > being loaded on a page. So I vote to remove the overlay by default and to > re-introduce the green loading bar which has been beyond the adressbar in the > nightly builds of FF 4 some time ago. > > Most users want to know whether and when a page loading is complete or not. My > opinion is, that the overlay, which has been chosen as favorite solution, is > confusing all lay people. That can not be a step towards usabilty. The green loading bar was removed due to performance reasons. I think they have plans to reintroduce it post-Fx4, but IMHO we should not get rid of overlay until that is implemented. (In reply to comment #89) > That said, I am a very big proponent of the link text appearing in the address > bar. There is absolutely no logic in displaying this text in the bottom of the > screen, whereas once clicked, the new address will appear at the top of the > screen. There is lots of logic to this decision. 1.) Link target still works in fullscreen mode 2.) Beginning of link target is always at the same position, unlike the right justified link target in URL bar. 3.) Having link target in a separate position allows you to compare it with the current page URL. If link target was in URL bar and it is too long it cuts off the current URL and you can't compare.
As has been stated previously, this bug is NOT the pace for you to be advocating for your favorite solution to this issue. This bug has been marked fixed as it fixes the issue as defined int he bug. Please take any discussion about an alternate solution elsewhere.
Can some features be added ( I believe this still fits into this but) : 1 - redirect messages to status bar 2 - select the screen position for status messages (top right would be nice) 3 - a way of displaying the last status message (maybe a tiny panel button in place) once it has hidden 4 - configure the time it is shown (1 sec to infinity) 5 - a collapsible list with history (stack of last 50 messages)
Can some features be added ( I believe this still fits into this bug) : 1 - redirect messages to status bar 2 - select the screen position for status messages (top right would be nice) 3 - a way of displaying the last status message (maybe a tiny panel button in place) once it has hidden 4 - configure the time it is shown (1 sec to infinity) 5 - a collapsible list with history (stack of last 50 messages)
Depends on: 637649
No longer depends on: 637649
How is this fixed if it depends on 6 unfixed bugs?
(In reply to comment #95) > How is this fixed if it depends on 6 unfixed bugs? Convention is to mark regressions caused by a fix as blockers of the bug that caused them. Discussions about stuff like that would be better off in forums though - http://www.mozilla.org/about/forums/ , and work on further changes should be in new bugs.
I file another bug655575 about showing connection status: in firefox 4, this overlay message bar stop working after the page is loaded, neither Flash connection nor reload picture won't trigger it popup. In Firefox 3.6, whenever there is connecting movement, it display on statusbar. (In reply to comment #92) > As has been stated previously, this bug is NOT the pace for you to be > advocating for your favorite solution to this issue. This bug has been > marked fixed as it fixes the issue as defined int he bug. Please take any > discussion about an alternate solution elsewhere. sorry if this touble anyone. Did try file a new bug, but no reply after a week or so..
Blocks: 573385
Depends on: 809898
No longer depends on: 630079
Blocks: status-panel
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: