Closed Bug 413062 Opened 17 years ago Closed 7 years ago

Bookmark Contextual Dialog: Fade out

Categories

(Firefox :: Bookmarks & History, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: faaborg, Unassigned)

References

()

Details

(Keywords: polish, Whiteboard: [polish-hard][polish-interactive][polish-p1])

If possible, the contextual dialog should fade in when displayed and fade out when dismissed. Mockup available at: http://people.mozilla.com/~faaborg/files/granParadisoUI/places_NewBookmarkDialog_i9.png
I completely disagree with this bug. UNless the speed is set to very few milliseconds, fading UI is just a waste of time for power users. Power users will be compromised by this bug, again another case for a disable pref.
>UNless the speed is set to very few milliseconds We need to make sure that the effect is not actually slowing users down with completing actions, and it doesn't feel sluggish.
Refining my thoughts on this, I think that fade out is fine, so long as the rest of the UI is accessible whilst the fade is happening. For example the 'dialog' is going to disappear when a user clicks outside of it yeah? At that point a fade out would be acceptable because it's not preventing the user from moving on. However fade in is to me, still not a good idea.
Agree, the dialog should pop in immediately on user action, and then fade away when it's dismissed. Our animation code is a bit spotty at times, though, so we'd have to make sure that we can do this. Not blocking, but wanted, nifty polish.
Flags: wanted-firefox3+
Summary: Bookmark Contextual Dialog: Fade in and fade out → Bookmark Contextual Dialog: Fade out
I think we should resolve this as INVALID. Contrary to what I told Mano, it might actually not be implementable cleanly. At the end, the operating system really hides the panel. Consequently, the OS would have to implement the fading. Ubuntu is doing this if you enable Desktop Effects.
Assignee: mano → nobody
not going to happen, as far as I can tell.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Each OS has as different way of setting the window opacity, we could theoretically in the future expose these calls to XUL in a way that works on every platform.
The point is that the OS is already doing the fading in some cases ... we would have to disable that explicitly in order to do our own fading. I don't know if that's even possible. Even if it is, that seems backwards, because the OS can do it much better than we can: fancier, hardware accelerated, consistent for all applications' popups and under the control of the user.
Right, I'm not suggestion that we implement it ourselves, but that we eventually attempt to leverage the OS's ability to fade windows.
Then I misunderstood this bug. I'm not sure if there's actually something that needs to be enabled from our side -- as I wrote, this already works on Linux, and I think on OS X, too.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(In reply to comment #10) > Then I misunderstood this bug. > > I'm not sure if there's actually something that needs to be enabled from our > side -- as I wrote, this already works on Linux, and I think on OS X, too. In OSX only the main menus fade correctly like the rest of the OS. All the other xul popup menus do not. I filed bug 406997 on this a while ago.
Depends on: 406997
Blocks: 403157
(In reply to comment #9) > Right, I'm not suggestion that we implement it ourselves, but that we > eventually attempt to leverage the OS's ability to fade windows. So why does this block bug 403157? Menus don't fade in XP.
Actually, XP can fade menus in but out, and I think it doesn't fade panels.
(In reply to comment #13) > Actually, XP can fade menus in but out in but *not* out
There's but 333564 for the menu fading on Windows, but I don't think that would help here.
(In reply to comment #14) >in but *not* out It fades the whole menu in, and the selected item out. Same with Vista.
this bug is eligible for bug 462080
Keywords: polish
Whiteboard: [polish-hard][polish-interactive]
Whiteboard: [polish-hard][polish-interactive] → [polish-hard][polish-interactive][polish-high-visibility]
This bug's priority relative to the set of other polish bugs is: P1 - Polish issue that appears in the main window, or is something that the user may encounter several times a day. This will be encountered often both because it is in the primary UI, and since there are a number of different interfaces that would all use the effect (bookmarks contextual dialog, site identity contextual dialog, new notification UI, etc.)
Whiteboard: [polish-hard][polish-interactive][polish-high-visibility] → [polish-hard][polish-interactive][polish-p1]
Status: REOPENED → NEW
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
The Star UI now seems to follow the other popups - if the star is clicked a second time it fades out. If an action causes it to close, it closes straight away.
Status: NEW → RESOLVED
Closed: 17 years ago7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.