Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MM-15232] [MM-18158] Add a container to small images, Fix UX issues when markdown images are used in channel header #3877

Conversation

@abdusabri
Copy link
Contributor

abdusabri commented Oct 6, 2019

Summary

Attached images and in-line markdown images with a width or height below 48px will be placed inside a container div to allow for better click/tap targeting.

Expected behavior:

  • The container will have a 1px border with rounded corners (4px)
  • The container will have a hover effect and a pointer cursor
  • The container will have the same background color as the center channel theme color
  • The enclosed image will have its own hover effect and rounded corners removed
  • Clicking on the container div will open the preview modal
  • If both width and height of the image are bigger than 48px, no container will be added
    - If an in-line markdown image is a link itself, no container will be added (even if the width and/or height are below 48px, as it doesn't have a hover effect and doesn't open the preview modal, @esethna, please let me know if this should change)

Also fixes an issue where images with a big height didn't respect max height constraints, and adds hover effect for in-line markdown images if they are also a link

When markdown images are used in a channel header, they are:

  • Scaled down to fit the available height in the header description area
  • Scaled down in the system messages that states the header has been changed
  • Scaled down in the expanded header state (when the header is clicked)

Screenshots

image

image

image

Ticket Link

Fixes mattermost/mattermost-server#12187 and https://mattermost.atlassian.net/browse/MM-18158

Copy link

andrewbrown00 left a comment

Thanks @abdusabri, this is looking great 🎉

Few items to resolve

  • Inline images are being stretched when posted, this is a regression. Clicking on the image shows the image properly (not stretched).
    image
    Expected/current behavior
    image

  • Inline images always show the hover effect, even if they are not a link.

@esethna what are your thoughts here, I'm 4/5 we should show the hover effect if the inline image is a also a link.

If an in-line markdown image is a link itself, no container will be added (even if the width and/or height are below 48px, as it doesn't have a hover effect and doesn't open the preview modal, @esethna, please let me know if this should change)

@abdusabri

This comment has been minimized.

Copy link
Contributor Author

abdusabri commented Oct 8, 2019

@andrewbrown00, Thanks for the feedback and for reporting the stretching issue of in-line markdown images! I've fixed it.

FYI, it is also happening on the daily version of the web app, but not on the community, I think this might be from my previous PR on MM-12898.

The cases for in-line markdown images are:

  1. If the image source is unsafe, a link is rendered -> Not relevant for this PR
  2. If the image source is safe, the image will have a pointer cursor & a hover effect, and clicking on it will open the preview window -> Covered
  3. If the image is a link itself, the image will be rendered and clicking on it will open the link in a new browser window (no preview or hover effect) -> Will add hover effect and a container if width or height less than 48px as you suggested and Eric gave 👍 (but will still open the link, not the preview modal)

Inline images always show the hover effect, even if they are not a link.

As far as I understand, this is case 2. form above, and that is the expected behavior. Did I miss something?

Thanks! 🙂

@esethna

This comment has been minimized.

Copy link
Member

esethna commented Oct 8, 2019

@abdusabri apologies, I think I may have misspoke, I don't think inline markdown images should get a container at all. Given they are typically used in-line, it could be distracting to show a container around them if they are small. For example, here is how an in-line markdown image is used in the developers channel header, which wouldn't be possible if we added a container around the image

image

@abdusabri

This comment has been minimized.

Copy link
Contributor Author

abdusabri commented Oct 8, 2019

@esethna, no worries! Maybe i read between the lines a bit too much, sorry 😊. And i'm also not really convinced it should have a container 🙈 it didn't look nice at all when I tried it. Glad you confirmed.

So, i will only add hover effect for inline images that are a link themselves.

@andrewbrown00, i would be waiting for your confirmation if i missed something regarding your 2nd comment. Update: i will remove the container as well as Eric just explained to me

@andrewbrown00

This comment has been minimized.

Copy link

andrewbrown00 commented Oct 8, 2019

@abdusabri thanks and Eric was correct and I missed that use case. Again, really nice job with this and I look forward to your future contributions 😄

@abdusabri

This comment has been minimized.

Copy link
Contributor Author

abdusabri commented Oct 8, 2019

@esethna, @andrewbrown00

Thanks for the image link example of the channel header use case, that gave me a new problem to solve 😄

Some special handling was needed to get the hover effect to work properly for the channel header.

Besides a couple of technical issues that I've resolved, the main consideration is the limited space (height) available in the header (22px max).

I set smaller max-height constraints for the image and created some space to allow for the hover effect. Here is an example of how it looks like.

image

I've separated this into its own commit in case input from Design/UX is needed so it won't block this PR in that case.

Copy link
Member

esethna left a comment

@abdusabri this is great! A few comments on the change to in-line images in the channel header (feel free to break this out into another PR if you feel necessary (your call), so we aren't creating scope creep since you are actually solving this ticket in here as well: https://mattermost.atlassian.net/browse/MM-18158):

  1. We should respect the reduced size in the system message states that states the header has been changed
    image

  2. Inline images should always have rounded corners by default (otherwise there is a strange state where the rounded corners only appear on hover)
    hover

  3. We should also respect the reduced size in the expanded header state (ie click in the header to see the expanded view):

image

@abdusabri

This comment has been minimized.

Copy link
Contributor Author

abdusabri commented Oct 9, 2019

Thanks for the feedback @esethna.

I'm totally fine fixing this in this PR. Turned out it is not a quick fix though 🙃, but I've a draft implementation already in place 🙂.

Here is a screenshot

image

I will need some more time to polish the implementation and add a bunch of tests 😄. When done, I will also update the PR description to state that it is fixing MM-18158 as well.

@abdusabri abdusabri changed the title [MM-15232] Add a container to images below a min-width and min-height to maintain clickable areas [MM-15232] [MM-18158] Add a container to small images, Fix UX issues when markdown images are used in channel header Oct 10, 2019
@lieut-data

This comment has been minimized.

Copy link
Member

lieut-data commented Oct 11, 2019

/check-cla

@abdusabri abdusabri requested review from esethna and andrewbrown00 Oct 11, 2019
Copy link

andrewbrown00 left a comment

@abdusabri thanks for the updates, a few small changes listed below:

  1. Inline image in the header doesn't look like it has rounded corners by default.
    image
    Note See ES comment

Inline images should always have rounded corners by default (otherwise there is a strange state where the rounded corners only appear on hover)

  1. @esethna I'm 5/5 we should reduce the corner radius to 2px for small images, ie the inline header image. Here's what it looks like with:
    2.1. 4px corners (current)
    image
    2.2. 2px proposed
    image
@abdusabri

This comment has been minimized.

Copy link
Contributor Author

abdusabri commented Oct 14, 2019

@andrewbrown00, on my local environment rounded corners are working as expected - by default -, and the test server was not updated to the latest commit, so can't test there.

Here is what it looks like for me

image

Where are you getting this behavior? How can i reproduce?

@andrewbrown00

This comment has been minimized.

Copy link

andrewbrown00 commented Oct 14, 2019

My apologies @abdusabri I saw this
image
and thought new changes we available. So I emptied my cache and did a hard reload on the existing test server.

I'll wait for an updated test server link 😉

Note I still like we should reduce the corner radius to 2px for smaller images, but I'll let Eric chime in.

@abdusabri

This comment has been minimized.

Copy link
Contributor Author

abdusabri commented Oct 14, 2019

No worries @andrewbrown00!

Once Eric confirms, i will reduce corners to 2px. In that case, it should also be applied to the scaled down images in the system messages. correct?

@sudheerDev

This comment has been minimized.

Copy link
Member

sudheerDev commented Nov 20, 2019

@sudheerDev

For scroll pop issue of MD images, please check the below screenshots based on community daily.

@abdusabri Can You check this once again on daily? Or send me a sample of the post for me to cross check. I cannot replicate this anymore.

We had few issues and we fixed them with #4164 and #4206.

As far as width: 100% this will cause issues with inline images with text as they now take up 100% of the space causing then to start with multiline and then wrap to a single line.

@abdusabri

This comment has been minimized.

Copy link
Contributor Author

abdusabri commented Nov 21, 2019

@sudheerDev
For scroll pop issue of MD images, please check the below screenshots based on community daily.

@abdusabri Can You check this once again on daily? Or send me a sample of the post for me to cross check. I cannot replicate this anymore.

We had few issues and we fixed them with #4164 and #4206.

As far as width: 100% this will cause issues with inline images with text as they now take up 100% of the space causing then to start with multiline and then wrap to a single line.

@sudheerDev

Thanks for the feedback.

I can confirm that I can no longer repro the issue on master. I was able to repro 8 days ago because #4206 was not merged at that time.

I will sync with master and test again on my branch with width: auto - not 100% - to confirm everything is working as expected. But I'm not sure I will have time to do so in the next couple of days.

Copy link
Member

sudheerDev left a comment

LGTM!. Thanks @abdusabri

@sudheerDev

This comment has been minimized.

Copy link
Member

sudheerDev commented Nov 21, 2019

@abdusabri The change of width you have here is same as master. Once you merge i believe you wouldn't need it here any longer. Rest all looks good to me so, went ahead and approved it.

Copy link
Contributor

devinbinnie left a comment

Looks good overall, just some small changes around CSS requested. Thanks @abdusabri!

alt={alt}
src={brokenImageIcon}
/>
<div style={{display: 'inline-block'}}>

This comment has been minimized.

Copy link
@devinbinnie

devinbinnie Nov 21, 2019

Contributor

Can we convert this to a class instead of using an inline style?

This comment has been minimized.

Copy link
@abdusabri

abdusabri Nov 23, 2019

Author Contributor

I thought a class is not necessary for a one-off use case, but sure, can use a class instead

This comment has been minimized.

Copy link
@devinbinnie

devinbinnie Nov 26, 2019

Contributor

Yes, please use a class.

This comment has been minimized.

Copy link
@sudheerDev

sudheerDev Dec 2, 2019

Member

Can we convert this to a class instead of using an inline style

Sorry, i am a little late to the comment here. It is fine to have simple styles in JS like this considering we have css which is not well maintained. If we make this a class we most likely will never get to cleaning this part if the html changes

This comment has been minimized.

Copy link
@abdusabri

abdusabri Dec 3, 2019

Author Contributor

@devinbinnie, please confirm 🙂

This comment has been minimized.

Copy link
@devinbinnie

devinbinnie Dec 3, 2019

Contributor

@abdusabri Sure that's fine

src={src}
onError={this.handleError}
onLoad={this.handleLoad}
style={this.props.handleSmallImageContainer && this.state.isSmallImage ? {

This comment has been minimized.

Copy link
@devinbinnie

devinbinnie Nov 21, 2019

Contributor

Can this be done with class names instead of inline styles?

This comment has been minimized.

Copy link
@abdusabri

abdusabri Nov 23, 2019

Author Contributor

I would have loved to do it using a class, and actually tried multiple approaches before falling back to using in-line styles. There are multiple levels of inheritance and a specificity war is going on 🙈 🙃, and in such cases, I believe using in-line style is better than using !important.

It would be awesome and much appreciated If you could help with resolving the specificity issue without using !important.

Update: I've figured it out, resolved the specificity issue and moved it into a class instead of in-line style.

This comment has been minimized.

Copy link
@devinbinnie

devinbinnie Nov 26, 2019

Contributor

@abdusabri Thanks, but I'm not seeing the changes here

This comment has been minimized.

Copy link
@abdusabri

abdusabri Nov 26, 2019

Author Contributor

The change is done locally but not pushed yet. Sorry if my comment was confusing.

This comment has been minimized.

Copy link
@devinbinnie

devinbinnie Nov 26, 2019

Contributor

Okay no problem! :)

<div
onClick={this.props.onClick}
className={className}
style={this.state.imageWidth > MIN_IMAGE_SIZE ? {

This comment has been minimized.

Copy link
@devinbinnie

devinbinnie Nov 21, 2019

Contributor

Same here with respect to inline styles

This comment has been minimized.

Copy link
@abdusabri

abdusabri Nov 23, 2019

Author Contributor

This is using the actual image size after it has loaded, not a predictable/fixed value that can be set in a CSS class, and I don't know if there could be a practical way to use something like calc to set it in CSS either.

This comment has been minimized.

Copy link
@abdusabri

abdusabri Nov 24, 2019

Author Contributor

width: fit-content; works, but according to MDN docs, it is experimental and shouldn't be used in production code. And here are more details from can I use

This comment has been minimized.

Copy link
@devinbinnie

devinbinnie Nov 26, 2019

Contributor

Okay, we can leave this one.


//The css hack here for loading images in the background can be removed after IE11 is dropped in 5.16v
//We can go back to https://github.com/mattermost/mattermost-webapp/pull/2924/files
if (!this.state.loaded && dimensions && dimensions.width) {
if (!this.state.loaded && this.dimensionsAvailable(dimensions)) {
imageStyleChangesOnLoad = {position: 'absolute', top: 0, height: 1, width: 1, visibility: 'hidden', overflow: 'hidden'};

This comment has been minimized.

Copy link
@devinbinnie

devinbinnie Nov 21, 2019

Contributor

Can we move this to a class somewhere?

This comment has been minimized.

Copy link
@abdusabri

abdusabri Nov 23, 2019

Author Contributor

Not sure how best to handle this for a workaround - based on the code comment above this line -, I would love for @sudheerDev to chime in as he has more context about this

This comment has been minimized.

Copy link
@abdusabri

abdusabri Dec 2, 2019

Author Contributor

@devinbinnie, @sudheerDev I'm waiting for your feedback on this to complete the requested changes and push my local updates

This comment has been minimized.

Copy link
@devinbinnie

devinbinnie Dec 2, 2019

Contributor

Well I know IE11 is no longer supported by Mattermost, so it should be safe to remove altogether, @sudheerDev does that make sense?

This comment has been minimized.

Copy link
@abdusabri

abdusabri Dec 2, 2019

Author Contributor

In case it is gonna be removed altogether, is it better to do so in a separate PR? (so it is easier to isolate the change in case there are any regression issues because of it)

This comment has been minimized.

Copy link
@devinbinnie

devinbinnie Dec 2, 2019

Contributor

Either that or at least a separate commit.

This comment has been minimized.

Copy link
@abdusabri

abdusabri Dec 2, 2019

Author Contributor

A separate commit sounds good. I can do so once Sudheer confirms or provides his feedback.

This comment has been minimized.

Copy link
@sudheerDev

sudheerDev Dec 2, 2019

Member

@abdusabri @devinbinnie Yes, we can remove that as we don't need to support for IE11. IMO it should be a separate PR.

This comment has been minimized.

Copy link
@sudheerDev

sudheerDev Dec 2, 2019

Member

it is easier to isolate the change in case there are any regression issues because of it

I agree with this. i think we should isolate that change. We already have a lot in this PR already. Better not to make more changes on top of this. It is easier for git blame to track and understand why a change was made as well if it is in separate PR.

This comment has been minimized.

Copy link
@abdusabri

abdusabri Dec 3, 2019

Author Contributor

Ok, then let's do this in a separate PR.

Please feel free to create a ticket and assign it to me (@devinbinnie or @sudheerDev)

@abdusabri

This comment has been minimized.

Copy link
Contributor Author

abdusabri commented Nov 23, 2019

Thanks @devinbinnie for the feedback! 🙂

Please check my comments and let me know your thoughts, thanks!

Copy link

andrewbrown00 left a comment

@abdusabri good to go 😄

@esethna esethna added this to the v5.20.0 milestone Dec 3, 2019
@devinbinnie devinbinnie self-requested a review Dec 3, 2019
Copy link
Contributor

devinbinnie left a comment

Thanks @abdusabri! Can you sync the PR with master? Then we can merge it.

abdusabri added 3 commits Dec 3, 2019
* Move small image styles when inside a container to a CSS class
* Improve naming convention of MD inline img container CSS class
* Update unit tests
* Update and improve E2E tests
@mattermod

This comment has been minimized.

Copy link
Contributor

mattermod commented Dec 3, 2019

New commit detected. SpinWick will upgrade if the updated docker image is available.

@abdusabri

This comment has been minimized.

Copy link
Contributor Author

abdusabri commented Dec 3, 2019

Thanks @abdusabri! Can you sync the PR with master? Then we can merge it.

Thanks @devinbinnie! Just pushed my local commits.

Since there were some updates, improvements, and a little merge conflict in E2E tests, it would be a nice bonus if @saturninoabril can have a quick look.

Copy link
Member

saturninoabril left a comment

@abdusabri Great to have those tests, well done!

cy.get('div.modal-image__content').should('be.visible');
});
});
});

This comment has been minimized.

Copy link
@saturninoabril
should('have.class', 'markdown-inline-img--hover').
and('have.class', 'markdown-inline-img').
and('have.class', 'markdown-inline-img--scaled-down').
and('have.css', 'height', '18px');

This comment has been minimized.

Copy link
@saturninoabril
@mattermod

This comment has been minimized.

Copy link
Contributor

mattermod commented Dec 3, 2019

Test server destroyed

@saturninoabril

This comment has been minimized.

Copy link
Member

saturninoabril commented Dec 4, 2019

/update-branch

@saturninoabril saturninoabril merged commit 01dbe7b into mattermost:master Dec 4, 2019
16 checks passed
16 checks passed
ci/circleci: build Your tests passed on CircleCI!
Details
ci/circleci: build-docker Your tests passed on CircleCI!
Details
ci/circleci: build-storybook Your tests passed on CircleCI!
Details
ci/circleci: i18n-check Your tests passed on CircleCI!
Details
ci/circleci: install Your tests passed on CircleCI!
Details
ci/circleci: lint Your tests passed on CircleCI!
Details
ci/circleci: prepare-docker-build Your tests passed on CircleCI!
Details
ci/circleci: test Your tests passed on CircleCI!
Details
ci/circleci: type-check Your tests passed on CircleCI!
Details
ci/circleci: upload-s3 Your tests passed on CircleCI!
Details
ci/circleci: upload-storybook Your tests passed on CircleCI!
Details
cla/mattermost abdusabri authorized
Details
mattermost/serverless-ops/github PR is up-to-date.
merge/blocked Merged allowed
Details
untagged-build Workflow: untagged-build
Details
untagged-build Workflow: untagged-build
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.