User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre Stop and reload was always on the left side next to the back and forward buttons. I do think that it would be more sensible to move the SRG button to the left and Larry next to it. Also the button should be a bit bigger (wider). The point of putting it to the left is that from my experience users tend to use Enter for what the Go button does but very often use the Reload button rather than F5. Putting the SRG button close to the back forward buttons makes the GUI more intuitive regarding the way the typical user uses the GUI. Reproducible: Always Steps to Reproduce: 1.use a nightly trunk build 2.realise stop-reload-go is on right side Actual Results: it's on right side Expected Results: left side is more logical and user friendly.

A Mockup how it could look like.

The button was decided to be on the right, and that's where it's going to be baring any sort of massive sea change that I don't see happening after the feature freeze. As an enhancement request, however, this has some merit. Last I checked, you can move the reload and stop buttons to the left and they will live there as the old-style combined stop/reload button (no go) but not attached to the bar.

As Dave said, you can already move the reload and stop buttons to the left of the location bar. Placing them on the right when combined was for the natural mapping of the movement of the progress bar from left to right until it reached the reload button.

So not any changes to making this user friendly with movable button (RESOLVED WONTFIX) ?

Yeah, no idea why they're reluctant to add this. You can fix it yourself though by adding the following to your userChrome.css file (from the developer of the "Status-4-Evar" add-on, taken from userstyles.org): ----- /* Combined go/reload/stop on left side */ #urlbar > .urlbar-frontcap-and-textbox { -moz-box-ordinal-group: 2; } #urlbar > toolbarbutton { margin: 0px !important; border: none !important; padding-left: 5px !important; border-right: 1px solid rgba(0,0,0,.35) !important; border-top-left-radius: 3px !important; border-bottom-left-radius: 3px !important; border-top-right-radius: 0px !important; border-bottom-right-radius: 0px !important; margin-right: 1px !important; box-shadow: 1px 1px 0 rgba(0,0,0,.1) inset, -1px -1px 0 rgba(255,255,255,.2) inset !important; } #urlbar > toolbarbutton:active:hover { border-top-left-radius: 3px !important; border-bottom-left-radius: 3px !important; border-top-right-radius: 0px !important; border-bottom-right-radius: 0px !important; padding-left: 5px !important; padding-right: 3px !important; box-shadow: 1px 1px 0 rgba(0,0,0,.1) inset, -1px -1px 0 rgba(255,255,255,.2) inset, 0 0 6.5px rgba(0,0,0,.4) inset, 0 0 2px rgba(0,0,0,.4) inset !important; } /* Status-4-Evar compatibility */ #urlbar-progress-alt { margin-right: 0px !important; } #urlbar:not([pmpack="center"]) #urlbar-progress-alt { margin-right: -1px !important; border-right: 1px solid rgba(0,0,0,.1) !important; } #urlbar:not([pmpack="begin"]) #urlbar-progress-alt, #urlbar:not([pmpack="begin"]) #urlbar-progress-alt > * { border-bottom-right-radius: 3px !important; } #urlbar:not([pmpack="end"]) #urlbar-progress-alt, #urlbar:not([pmpack="end"]) #urlbar-progress-alt > * { border-top-right-radius: 3px !important; } ----- Works absolutely perfectly.

(In reply to comment #5) > Yeah, no idea why they're reluctant to add this. I have no idea why some people can't grasp that added built-in complexity that won't be used by many people is a bad thing. Virtually nobody is going to want to (or know to want to) move the combined three state button to the left in comparison to the hundreds of millions of Firefox users. There is already the ability to split it off and have the old two state button on the left, as already stated, and that works fine. We have this nice system of extensions and the few who want it on the left like this can make one for that. That's why we have extensions: so we don't build every single idea into one bloated feature pile, and that includes everything from minor interface tweaks up to IRC clients. Just because something is declared addon territory doesn't mean it's a bad idea. I'm sure plenty of people will love the button on the left. It's just that the route to doing that is going to go through the Addon Manager instead of the default toolbar customization system. > ----- > { ... big complex blob of CSS ... } > ----- > > Works absolutely perfectly. Programs like Firefox are big and complicated. Adding yet another pile of CSS changes for an infrequently used feature is more that will have to be maintained, eventually, by someone down the road. I know users want everything built in, sometimes I too want something built in that get's kicked off to an addon (ex: copy link text; bug 242852), but not everything can be in at once and addons do work quite well. ;)

Nobody is going to want it on the left... except the millions of current users that are used to it there in Firefox 1-3.x. I've already seen a couple posts on the "Input" feed page from users (assumingly migrating from 3.x to 4.0b7 as their first Firefox 4 release) asking "Where is the reload button?" or "They took away the reload button?" But that's another argument. My point is that the CSS already exists, and is working perfectly for many users on the nightlies. Having the appearance of the combined reload/stop button completely change when moved to the left really just seems needlessly visually inconsistent given that the fix for this exists, and amounts to 3 CSS rules (the Status-4-Evar part is not essential, and will be moving into the extension itself later on from what I gather). Thus, I provided the "big complex blob of CSS" for those who find this bug from now on. If this CSS were submitted as a patch at this point, I'm assuming there's no chance of it being accepted anyway given the WONTFIX status?

(In reply to comment #7) > If this CSS were submitted as a patch at this point, I'm assuming there's no > chance of it being accepted anyway given the WONTFIX status? Correct. Feel free to make an add-on.

Too bad, because it's very important change for all Firefox users. Now they need to change their old habits with reload button, because it was always on the left side and mouse road will be longer too, because right side is not used that much like left... Of course I can use addons, but when they are not maintained and updated properly it will cause more bloat than simply adding a small code of moving combined button... So please reconsider this as NEW bug, because this is not in anyway user friendly change, forcing is not a good option...

Change happens. That's the one consistent thing in the world. The button on the right is 3-state because it can mix with the go button which is on the right. The go button doesn't really belong on the left and there's other new stuff in the way over there (doorhanger widgets and the like), so putting the 3-state button on the left and connected to the bar is not the best idea for most users, in my opinion. Again, the old 2-state regular button mode is still available via toolbar customization, so if people are going to desperately cling to old habits THEY STILL CAN by just dragging the old reload and stop buttons back over via toolbar customization. It just won't look like the new version... because it'll be the old version.

Yep, I know I can get old combined reload/stop button, but it will be nice to have it movable left/right for user preferences in the new look. It's not that hard and will not be pain in the ass to change it for novice users using chrome or wasting time for searching working addon. Devs now adding Panorama, Sync etc and you talk about this customization as bloat... funny At least mark this as NEW enhancement

(In reply to comment #11) > Devs now adding Panorama, Sync etc and you talk about this customization as > bloat... funny I don't entirely disagree with this point, though I do like these features. ;) > At least mark this as NEW enhancement Frank Yan WONTFIXed this and he's the one that gets to make the decision, not me, though I do agree with him. (my reasoning in comment 10)

Why is this a battle? The open source community is about... openness and community, no? I completely understand that this new right-sided, 3-state button represents a new way of looking at this functionality. Since the button's now attached to the address bar, and it's more intuitive to control an object from it's right side (according to usability studies I remember reading), and since it's now combined with the go button - it makes sense. Especially with the new progress bar effect (mentioned above). I've really grown to prefer it over the old way after disliking it at first. When I go back to Chrome for something it feels weird to click the reload button to the left of the address bar. However... This 'my way or the highway' attitude, is really not constructive and smacks of Steve Jobs-style arrogance. Let's tell people why we're doing things instead of this whole, "I'M changing things and since I'M working on it and YOU'RE not (and aren't paying for it)... go screw yourself". Let's act like a community and speak constructively when we go and change such a basic and familiar part of peoples' web browsing experience. We should all be fighting for Firefox to maintain it's market-share, and to do that you have to hold peoples' hands a bit sometimes. I find that, as developers, we tend not to think like people sometimes. A perfect example of this is Google's horrible 'customer service' system. They're thinking like engineers. Let's be above that. Community - not corporate product... remember?

(In reply to comment #10) > Again, the old 2-state regular button mode > is still available via toolbar customization, so if people are going to > desperately cling to old habits THEY STILL CAN by just dragging the old reload > and stop buttons back over via toolbar customization. You make it sound like clinging to old habits is a bad thing and that the old design was flawed. I think that the old design was proven and is more sensible than the new design from the page control perspective. This change is like removing the play / pause button on any media player from the regular rewind - play / pause - forward setup and moving the play / pause button completely somewhere else. It does not make sense. The long extra mouse travel on wide screen monitors is really unfortunate with the new default design.