925681 - Australis: in customization mode, the awesome bar should have a Firefox identity button and the reload button should show

Status: VERIFIED FIXED

(Firefox :: Theme, defect)

Description

[u428464]

In customization mode the awesome bar doesn't show the reload button in it. It should be visible. It would also be nice to have the "firefox page" indicator visible to show that the page is secure.

Comment 1

[:Gijs (he/him)]

(In reply to Guillaume C. [:ge3k0s] from comment #1)
> In customization mode the awesome bar doesn't show the reload button in it.
> It should be visible.

Out of curiosity, why? You won't be able to interact with it...

Comment 2

[u428464]

I'm no visual designer, but I think it would be clearly better to show things as they are even out of Customization mode. if you're not convinced maybe we should ask UX if it's better or not.

Comment 3

[u428464]

*in customization mode

Comment 4

[:Gijs (he/him)]

Per comment #2. Reload button, yes or no?

Comment 5

[Zhenshuo Fang (:fang) - Firefox UX Team]

Not a very strong preference but I do think we should show it for users who wonder "where is my reload button".

And for the "Firefox identity in the awesome bar", when we have a favicon for customization mode we probably don't need more identity in the awesome bar.

Comment 6

[sworddragon2]

I'm noticing that in customization mode the reload/stop button is in the address bar and can't be moved anymore at a custom position (this was possible in Firefox 25 and before). I'm not sure but is this report among other things talking about this?

Comment 7

[:Gijs (he/him)]

(In reply to sworddragon2 from comment #6)
> I'm noticing that in customization mode the reload/stop button is in the
> address bar and can't be moved anymore at a custom position (this was
> possible in Firefox 25 and before). I'm not sure but is this report among
> other things talking about this?

No.

Comment 8

[Rob Crowther]

In that case, filed bug 940342 for not being able to move reload/stop button.

Comment 9

[Blake Winton (:bwinton) (:☕️)]

Attachment: A first cut at the patch to show stuff in customize mode.

Would something like this work?

(Screenshot at https://www.dropbox.com/s/obakua77xbz661y/Screenshot%202014-01-20%2017.11.57.png )

Comment 10

[:Gijs (he/him)]

Comment on attachment 8362700 [details] [diff] [review]
A first cut at the patch to show stuff in customize mode.

I'll buy that for a dollar. :-)

(assuming you get ui-r+)

Comment 11

[:Gijs (he/him)]

Egh. Is this a half-dupe of bug 869500? Blake?

Comment 12

[Blake Winton (:bwinton) (:☕️)]

I don't think it is, since the favicon appears in the tab, and these appear in the urlbar.
(You can see that my screenshot doesn't have a favicon, and so doesn't fix this bug.  ;)

Comment 13

[u428464]

(In reply to Blake Winton (:bwinton) from comment #9)
> Created attachment 8362700 [details] [diff] [review]
> A first cut at the patch to show stuff in customize mode.
> 
> Would something like this work?
> 
> (Screenshot at
> https://www.dropbox.com/s/obakua77xbz661y/Screenshot%202014-01-20%2017.11.57.
> png )

Looks very nice. It would be even nicer to have "about:customize" greyed out in the location bar next to the identity block.

Comment 14

[Blake Winton (:bwinton) (:☕️)]

It would, but that seems kind of annoyingly hard.  :(
I got halfway there, by adding the following lines to browser/themes/shared/customizableui/customizeMode.inc.css

toolbarpaletteitem > toolbaritem > #urlbar > hbox > hbox > html|*.textbox-input,
toolbarpaletteitem > toolbaritem > * > #urlbar > hbox > hbox > html|*.textbox-input {
  visibility: visible;
}

If you wanted to take that, and run with it, Guillaume, that would be _awesome_!  ;)

Comment 15

[Stephen Horlander [:shorlander]]

Comment on attachment 8362700 [details] [diff] [review]
A first cut at the patch to show stuff in customize mode.

Review of attachment 8362700 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, thanks!

Comment 16

[u428464]

(In reply to Blake Winton (:bwinton) from comment #14)
> It would, but that seems kind of annoyingly hard.  :(
> I got halfway there, by adding the following lines to
> browser/themes/shared/customizableui/customizeMode.inc.css
> 
> toolbarpaletteitem > toolbaritem > #urlbar > hbox > hbox >
> html|*.textbox-input,
> toolbarpaletteitem > toolbaritem > * > #urlbar > hbox > hbox >
> html|*.textbox-input {
>   visibility: visible;
> }
> 
> If you wanted to take that, and run with it, Guillaume, that would be
> _awesome_!  ;)

Sadly my coding skills are close to nothing so I can't really help here. It's fine without it too. ;)

Comment 17

[Matthew N. [:MattN]]

https://hg.mozilla.org/integration/fx-team/rev/42f136d90d85

Comment 18

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/42f136d90d85

Comment 19

[Tim Nguyen :ntim]

This still isn't fixed for me, I'm using Nightly 06/02/14

Comment 20

[:Gijs (he/him)]

(In reply to Tim Nguyen [:ntim] from comment #19)
> This still isn't fixed for me, I'm using Nightly 06/02/14

I suspect this is bug 964206 which was duped to bug 908534. Can you confirm that, and/or file a new bug if switching tabs doesn't make the indicator appear? Thank you!

Comment 21

[Cornel Ionce [:noni] [Hubs QA]]

Verified fixed on Windows 7 64bit, Mac OS X 10.9 and Ubuntu 13.10 using latest Aurora (build ID: 20140306004001).