Closed Bug 632626 Opened 13 years ago Closed 11 years ago

Show status message popup on top of the add-on bar if enabled

Categories

(Firefox :: General, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: davemgarrett, Unassigned)

References

Details

(Keywords: regression, ux-minimalism)

Filed at Dão's request due to bug 629304 being rejected.

Bug 629304 added the status message popup to show on top of content in the lower left. If you have the add-on bar enabled this adds to the vertical space instead of removing it as was the original intention of the status bar removal. It can get worse up to 3 lines with the find bar active.

As an alternative to putting these messages inside the add-on bar (bug 629304) the popup could just be shown on top of the add-on bar if open. The popup already automatically moves to the opposite side of the screen if you mouse over it, so it won't obstruct usage of the add-on bar, just some visibility for a short period.

There is an argument against this, though. While the page is loading you don't care too much about the space here yet and ideally it will only appear for a short while. It also moves out of the way if you mouse over it, so whilst this extra usage of vertical space might be annoying to some it may not be big enough of a deal to bother with.
blocking2.0: - → ---
Summary: Show connecting / waiting / loading status messages on top of the add-on bar if enabled → Show status message popup on top of the add-on bar if enabled
Typo: that second bug number for the initial bug implementing the popup should've been bug 628654
(In reply to comment #0)
> Filed at Dão's request due to bug 629304 being rejected.

More precisely, due to your comments distracting the bug.
(In reply to comment #2)
> (In reply to comment #0)
> > Filed at Dão's request due to bug 629304 being rejected.
> 
> More precisely, due to your comments distracting the bug.

Bug 629304 comment 0 originally requested this to be on not in the add-on bar. The discussion morphed to restructuring the add-on bar to put it inside. That's what was WONTFIXed. My comments were on-topic to the bug as filed.
You're focus on and interpretation of the preposition chosen in bug 629304 comment 0 seems a bit over the top. The point of the bug was to show the text on the add-on bar, not to move the bubble. It was filed in response to bug 628654 comment 36. It didn't morph.
Bug 629304 does not mention a specific comment it's in reply to. Your comments in that bug started with the suggestion to "make the status field movable / removable" and eventually Mike Beltzner WONTFIXed saying "I don't think that we're going to restructure the Add-On Bar for this." Then when I mentioned that that wasn't the only option, and you said to file another bug. You restricted it to that one solution which was WONTFIXed, so now we have another bug for just moving the popup down a bit rather than restructuring the add-on bar, as requested.
(In reply to comment #5)
> Bug 629304 does not mention a specific comment it's in reply to.

So what? It didn't mention moving the popup over the add-on bar either. And I just provided you with the context which it was filed in.

> Your comments
> in that bug started with the suggestion to "make the status field movable /
> removable"

Yep, the status field that would have to be added to fix the bug as intended, and which could also have been unmovable instead, hence my comment. Please don't make it sound like I hijacked the bug.

> Then when I mentioned that that wasn't the only option

You actually did that in bug 629304 comment 7, which ideally would already have been a cross-reference to a separate bug instead. Your second comment didn't add anything.
Dão, I don't understand why this has become a procedural argument. There must've been some misunderstanding somewhere. I did not imply you "hijacked" the bug and me posting a second one line comment was not a "distraction". We each posted our own suggested solutions to a bug without a well defined suggested solution. I only commented again because the entire bug was WONTFIXed based on /one/ possible solution, rather than /any/ possible solution to the bug. We now have another bug for another possible solution that may or may not be worth doing.
The misunderstanding is in your interpretation of bug 629304 comment 0. (You claimed that it "originally requested this to be on not in the add-on bar", but now you say it didn't suggest a solution, so that's some progress at least.)
I said "well defined" suggested solution. It said "on" not "in", but that's vague. The word "on" implies my idea and the word "in" would imply yours, but either could be interpreted in either way. I retitled the bug to "in/on" initially and then to "inside" at the end to clarify what precisely was WONTFIXed. The entire reason for the miscommunication here is probably just bug 629304 comment 12 where Mike closed it based on your idea to fix the bug which would require "restructuring" the add-on bar (though only slightly) and thus necessitated another bug for the other route. In any case, comments 2-9 here are a distraction to this bug. We don't need to debate this at length.
Why make it above the add-on bar? why not inside of it? That would be better for the ergonomics.
On, in or inside, I agree with the sentiment here: 
https://bugzilla.mozilla.org/show_bug.cgi?id=629304#c11

Several changes were done to maximize vertical screen real estate, but the current situation is effectively a *regression* from ff3, i.e. exactly the opposite of what the goal was.
The screen space covered by the new hover link may be in use without the mouse over it.

In an XUL page, the user can be navigating down a tree on the left hand side with the keyboard and be unable to see the selection due to it being under the hover link.
wontfix per bug 749804.
Status: NEW → RESOLVED
Closed: 11 years ago
Depends on: 749804
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.