New issue
Advanced search Search tips
Starred by 2 users

Issue metadata

Status: Fixed
Closed: Dec 18
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug

Sign in to add a comment

Issue 870599: img not showing

Reported by, Aug 3

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.84 Safari/537.36

Steps to reproduce the problem:
2. src img ../../../../assets/thumbon.png not working
3. only on chrome

What is the expected behavior?
show image

What went wrong?
src img ../../../../assets/thumbon.png  not working
 only on chrome

Did this work before? N/A 

Chrome version: 68.0.3440.84  Channel: stable
OS Version: 10.0
Flash Version:
33.9 KB View Download

Comment 1 by, Aug 6

Labels: Needs-Triage-M68

Comment 2 by, Aug 6

 Issue 870600  has been merged into this issue.

Comment 3 by, Aug 7

Components: Blink>Image
Labels: Triaged-ET Target-70 M-70 FoundIn-70 OS-Linux OS-Mac
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on Mac 10.13.3, Win-10 and Ubuntu 17.104 using chrome reported version #68.0.3440.84 and latest canary #70.0.3515.0.
This is a non-regression issue as it is observed from M60 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.


Comment 4 by, Aug 7

Components: -UI -Blink>Image Blink>CSS Blink>Layout
This appears to be a layout issue, or maybe style resolution. The computed height of the image is 0px. It's specified as 100% but no parent element has 0 height. Forcing re-layout seems to fix it in that docking Devtools causes the height to compute and the image to appear, as does disabling the height: 100%; CSS rule on the image.

Comment 5 by, Aug 8

Components: -Blink>Layout
Labels: -Pri-2 Pri-3
Status: Available (was: Untriaged)
Looks like an invalidation problem, the image takes awhile to load and once it is loaded it never updates the height of the element. Interesting.

Comment 6 by, Dec 11

Components: -Blink>CSS Blink>Layout
Looks like the culprit is |image_size_is_constrained| in LayoutImage::InvalidatePaintAndMarkForLayoutIfNeeded - it's not strict enough in this case and thus not triggering a layout when the image dimensions arrive.

Comment 7 by, Dec 13

Status: Assigned (was: Available)

Comment 8 by, Dec 14

Project Member
The following revision refers to this bug:

commit fbc553f0671c6123db3b7a840cafbbc44f875981
Author: Fredrik Söderquist <>
Date: Fri Dec 14 09:55:18 2018

Refactor "needs layout" check in LayoutImage

Move the conditions used to check if layout is needed when the intrinsic
size changes out into a new function, and call that from
Replace open-coded HasRelativeLogicalWidth() with a call to that method.

Bug:  870599 
Change-Id: Iae480326083eb493d58233378d95af8c1dd62f0a
Commit-Queue: Fredrik Söderquist <>
Reviewed-by: Morten Stenshorne <>
Cr-Commit-Position: refs/heads/master@{#616624}

Comment 9 by, Dec 18

Project Member
The following revision refers to this bug:

commit 934d262005cdf2110da6fe3d1660e6e45cde6925
Author: Fredrik Söderquist <>
Date: Tue Dec 18 11:33:12 2018

Narrow "is constrained" check for LayoutImage layout invalidation

If our containing block has auto height, we need to relayout.
Add !HasAutoHeightOrContainingBlockWithAutoHeight() to the
condition for |image_size_is_constrained|.

Bug:  870599 
Change-Id: I22858843d7ad87c63eb7b8d6e771e0f8d6cfa09d
Commit-Queue: Fredrik Söderquist <>
Reviewed-by: Morten Stenshorne <>
Cr-Commit-Position: refs/heads/master@{#617446}

Comment 10 by, Dec 18

Status: Fixed (was: Assigned)

Sign in to add a comment