similar to bug 1379480, but this bug is not about distracting. The stop button should be available as soon as the load happens. however, with the animation, the stop button doesn't look like ready until the animation ends, especially, the "x" icon (that means "stop") is not displayed until the animation ends. for example, if you click "reload", clicking the button again behaves as "stop", but the appearance doesn't match until the animation ends. the same thing happens for "stop" => "reload" case. It means that the appearance doesn't explain the feature, and I think it's too bad. IMO, there shouldn't be any kind of transition animation between them.

(In reply to Tooru Fujisawa [:arai] from comment #0) > the same thing happens for "stop" => "reload" case. This is actually not true, because we disable the button for 650ms when we switch from stop->reload to prevent people from accidentally clicking 'reload' when they intended to click 'stop'. We shortened the animation in bug 1381957 so it's now 400ms for both animations. It used to be 684ms for stop->reload and 600ms for reload->stop. This is a 41% reduction for stop->reload and a 33% reduction for reload->stop. I don't think there is much that can be done here so I'm going to close this bug as wontfix since the request goes against the intended design of the feature.

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #1) > (In reply to Tooru Fujisawa [:arai] from comment #0) > > the same thing happens for "stop" => "reload" case. > > This is actually not true, because we disable the button for 650ms when we > switch from stop->reload to prevent people from accidentally clicking > 'reload' when they intended to click 'stop'. I'm not seeing this behavior. the button is not disabled, both visually and functionally. > We shortened the animation in bug 1381957 so it's now 400ms for both > animations. It used to be 684ms for stop->reload and 600ms for reload->stop. > This is a 41% reduction for stop->reload and a 33% reduction for > reload->stop. that's totally unrelated to this bug. > I don't think there is much that can be done here so I'm going to close this > bug as wontfix since the request goes against the intended design of the > feature. why a design have priority over semantics...?

I'm feeling that, at least these days, UI/UX bugs are closed with a reason like "it's designed like that", instead of explaining the reasoning "why the current behavior is valid" or "why the current behavior is better even while there's a problem mentioned in a bug". it's really depressing and I don't see any point of reporting bugs if they're closed like that...

> I'm not seeing this behavior. > the button is not disabled, both visually and functionally. Yes, it is. You can tell by hovering the button: when it is disabled there is no hover background. As a matter of fact, Chrome has the same behavior.

(In reply to Tooru Fujisawa [:arai] from comment #2) > (In reply to Jared Wein [:jaws] (please needinfo? me) from comment #1) > > (In reply to Tooru Fujisawa [:arai] from comment #0) > > > the same thing happens for "stop" => "reload" case. > > > > This is actually not true, because we disable the button for 650ms when we > > switch from stop->reload to prevent people from accidentally clicking > > 'reload' when they intended to click 'stop'. > > I'm not seeing this behavior. > the button is not disabled, both visually and functionally. What build are you using? What theme do you have applied? Bug 1376893 made it so that we don't grey out the reload button while it's disabled due to flickering, but it does functionally disable for the first 650ms when it gets switched to. As comment 4 says, you can see this by leaving your mouse cursor over the button while a page loads and then finishes loading. > > We shortened the animation in bug 1381957 so it's now 400ms for both > > animations. It used to be 684ms for stop->reload and 600ms for reload->stop. > > This is a 41% reduction for stop->reload and a 33% reduction for > > reload->stop. > > that's totally unrelated to this bug. I brought this up because as these numbers decrease, the amount of time where the button doesn't look "ready" decreases. I thought that was in the same direction as this bug had proposed. > > I don't think there is much that can be done here so I'm going to close this > > bug as wontfix since the request goes against the intended design of the > > feature. > > why a design have priority over semantics...? (In reply to Tooru Fujisawa [:arai] from comment #3) > I'm feeling that, at least these days, UI/UX bugs are closed with a reason > like "it's designed like that", instead of explaining the reasoning "why the > current behavior is valid" or "why the current behavior is better even while > there's a problem mentioned in a bug". > it's really depressing and I don't see any point of reporting bugs if > they're closed like that... I tried to explain this in a recent post on reddit, https://www.reddit.com/r/firefox/comments/6m8gco/firefoxs_new_reloadstop_animation_for_photon_just/dkecyx1/ To quote myself, """ Animations and movements in software should model animations and movement seen in the "real world". This means that we don't see moving items immediately stop without some easing, as well we don't see items change forms without some level of morphing. The animation implemented shows the changing from stop <-> reload which is more natural than the immediate switch. We are and have been introducing animations mainly to inform users how Firefox works (see the animation for how the bookmark star bounces in to the bookmarks menu). In other situations, such as the tab animations, we are focused on improving perceived performance while also modeling movements seen in nature. """ I hope that you don't think we are brushing this off. I believe that with bug 1381957 we've made the problem you have reported less severe and that now we are in a state where we have balanced the various trade offs quite evenly.