fix(styles): make setting header UI better #3089
Conversation
|
Fixes #3055 |
| @@ -35,6 +35,7 @@ $input-background-disabled-color: #f2f2f2; | |||
| $input-border-disabled-color: #dddddd; | |||
| $input-disabled-color: #64778c; | |||
| $secondary-button-border-color: #c1c1c1; | |||
| $black: #fff; | |||
pdehaan
Sep 21, 2015
Contributor
nit: this is a bit confusing. Since $black is technically white.
nit: this is a bit confusing. Since $black is technically white.
vladikoff
Sep 22, 2015
Contributor
should this be $modal-border-color?
should this be $modal-border-color?
| var displayName = account.get('displayName'); | ||
| var email = account.get('email'); | ||
|
|
||
| var $cardHeader = $('.card-header'); |
vladikoff
Sep 22, 2015
Contributor
could we use this.$... for all these selectors here? see other usage in this same file
could we use this.$... for all these selectors here? see other usage in this same file
| @@ -117,7 +117,10 @@ function ($, modal, Cocktail, Session, BaseView, AvatarMixin, | |||
| $.modal.close(); | |||
| } | |||
| this.showEphemeralMessages(); | |||
|
|
|||
vladikoff
Sep 22, 2015
Contributor
nit: extra spaces / line breaks, not needed
nit: extra spaces / line breaks, not needed
| {{#showSignOut}} | ||
| <button id="signout" class="settings-button secondary">{{#t}}Sign out{{/t}}</button> | ||
| {{/showSignOut}} | ||
| </header> | ||
|
|
||
| <div class="settings-success-wrapper"> | ||
| <div class="success settings-success">Hello</div> |
vladikoff
Sep 22, 2015
Contributor
Do we still need this Hello here?
- it seems like it is not visible
- the contents of that get replaced with some "updated" message.
So should this just be <div class="success settings-success"></div> ?
Do we still need this Hello here?
- it seems like it is not visible
- the contents of that get replaced with some "updated" message.
So should this just be <div class="success settings-success"></div> ?
| @@ -156,6 +159,25 @@ function ($, modal, Cocktail, Session, BaseView, AvatarMixin, | |||
| }); | |||
| }, | |||
|
|
|||
| _swapDisplayName: function () { | |||
|
@vladikoff so i fixed everything but am unable to repro the text clipping issue in FF or Chrome. Where were did you see this? |
8b4ab83
to
c44bd9a
|
@johngruen Seems like text clipping was fixed but now the headers are just too close to each other: |
|
@johngruen the above is in latest stable chrome ^ |
|
Also needs rebase |
c618c47
to
0d4e898
| $('body.settings').fadeOut(this.FADE_OUT_SETTINGS_MS, function (){ | ||
| $('body').removeClass('settings').show(); | ||
| }); | ||
| }, |
zaach
Sep 25, 2015
Contributor
Am I going crazy I thought we already had code that did this.
Am I going crazy I thought we already had code that did this.
zaach
Sep 25, 2015
Contributor
Ugh, I didn't notice in 207dfd6 that we removed the smooth transition.
/cc @shane-tomlinson
Ugh, I didn't notice in 207dfd6 that we removed the smooth transition.
/cc @shane-tomlinson
zaach
Sep 25, 2015
Contributor
This effect is now implemented in base.js, which we could modify to also use a transition if the view specifies a duration.
This effect is now implemented in base.js, which we could modify to also use a transition if the view specifies a duration.
shane-tomlinson
Sep 28, 2015
Member
Ugh, I didn't notice in 207dfd6 that we removed the smooth transition.
/cc @shane-tomlinson
Yeah, that transition messed with the removal of the layoutClassName, so I took it out.
Ugh, I didn't notice in 207dfd6 that we removed the smooth transition.
/cc @shane-tomlinson
Yeah, that transition messed with the removal of the layoutClassName, so I took it out.
shane-tomlinson
Sep 28, 2015
Member
Yeah, that transition messed with the removal of the layoutClassName, so I took it out.
I now see not having it messes with other things. In base.js, can you document why the transition is needed or else another drive by removal could occur.
Yeah, that transition messed with the removal of the layoutClassName, so I took it out.
I now see not having it messes with other things. In base.js, can you document why the transition is needed or else another drive by removal could occur.
shane-tomlinson
Oct 1, 2015
Member
This flash still exists - can we just remove the fade out for now and file a follow on bug to re-add the behavior more generically?
This flash still exists - can we just remove the fade out for now and file a follow on bug to re-add the behavior more generically?
| cardHeader.text(displayName); | ||
| cardSubheader.text(email); | ||
| } | ||
| }, |
vladikoff
Sep 25, 2015
Contributor
above is not covered by unit tests, see

https://coveralls.io/builds/3670185/source?filename=app%2Fscripts%2Fviews%2Fsettings.js
Let us know if you need help adding tests for these
above is not covered by unit tests, see
https://coveralls.io/builds/3670185/source?filename=app%2Fscripts%2Fviews%2Fsettings.js
Let us know if you need help adding tests for these
| cardHeader.text(email); | ||
| cardSubheader.text(''); | ||
| } else { | ||
| cardHeader.text(displayName); |
| }); | ||
| }); | ||
|
|
||
| describe('with display name added', function () { |
| assert.equal(view.$('.card-subheader').text(), 'a@a.com'); | ||
| }); | ||
| }); | ||
| }); |
shane-tomlinson
Oct 1, 2015
Member
As noted above, one more test is needed that starts with the email address in the header, then adds a display name after the initial render. That should hit the uncovered code.
As noted above, one more test is needed that starts with the email address in the header, then adds a display name after the initial render. That should hit the uncovered code.
|
@shane-tomlinson added another test that should fit the bill, also removed that fading stuff. |
| @@ -148,6 +149,32 @@ function ($, modal, Cocktail, Session, BaseView, AvatarMixin, | |||
| return self._showAvatar(); | |||
| }, | |||
|
|
|||
| beforeDestroy: function () { | |||
| @@ -1,24 +1,30 @@ | |||
| <div id="fxa-settings-header-wrapper"> | |||
| <header id="fxa-settings-header"> | |||
| <h1 id="fxa-manage-account">{{#t}}Manage account{{/t}}</h1> | |||
| <h1 id="fxa-manage-account">{{#t}}Firefox Account{{/t}}</h1> | |||
shane-tomlinson
Oct 1, 2015
Member
Do you want Account or Accounts here. I understand the rationale for Account, but that doesn't seem right.
Do you want Account or Accounts here. I understand the rationale for Account, but that doesn't seem right.
ryanfeeley
Oct 1, 2015
Contributor
I prefer "Accounts". It fits in more with the domain and the emails we are sending. You are at a site that has accounts, and maybe one day you'll be able to be signed into multple accounts, like Google.
I prefer "Accounts". It fits in more with the domain and the emails we are sending. You are at a site that has accounts, and maybe one day you'll be able to be signed into multple accounts, like Google.
|
As soon as the tests pass, I'm hitting the button. This is a great update @johngruen! |
|
cool! |
oh dear lord. Great catch. |
* Change `Firefox Account`=>`Firefox Accounts` * Ensure the displayName is not an XSS vector. * Remove the display name from the settings-unit-summary
fix(styles): make setting header UI better r=vladikoff







@pdehaan @zaach maybe give this a review? I added some stuff into the settings view to twiddle the DOM when a user adds or removes a display name.
Fixes #3055