New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 652864 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug-Regression



Sign in to add a comment

gif is not auto playing

Reported by luzhang....@gmail.com, Oct 4 2016

Issue description

<b>Chrome Version       : <Copy from: 'about:version'></b>
URLs (if applicable) : https://www.messenger.com/t/lupushnotif.lupushnotif
Other browsers tested: yes
  Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
     Safari: OK
    Firefox: OK
         IE:

What steps will reproduce the problem?
(1) choose any gif from your folder or from gif icon on messenger.com in any thread
(2) send the gif, can see the gif renders
(3) gif may play or not when resizing the browser window.

What is the expected result?
it should always auto play.


What happens instead?
gif only auto plays when in certain browser width.

Please provide any additional information below. Attach a screenshot if
possible.

 
gifnotautoplaying.mov
7.7 MB Download
Components: Blink>Image
Labels: Needs-Feedback
Reporter@ - Could you please provide the chrome version and OS in which the issue was reported.

Thanks,
Cc: krajshree@chromium.org
This repros for me on Chrome Version 53.0.2785.116 (64-bit) on OSX 10.11.6
Here is a simpler repro case:
https://jsfiddle.net/hu0q7p3f/

It's definitely the border radius causing issues.

Comment 5 by f...@opera.com, Oct 5 2016

Cc: fmalita@chromium.org
Thanks for the additional info. That makes it sounds like it could be the same issue 644112 (although I not allowed to look at that bug), which should be fixed in 55. Maybe it should be merged to 54? Florin?
Cc: rbasuvula@chromium.org
Labels: -Type-Bug -Needs-Feedback M-55 hasbisect OS-Linux OS-Mac OS-Windows Type-Bug-Regression
Status: Untriaged (was: Unconfirmed)
Tested in chrome stable #53.0.2785.143 on Mac 10.12 able to reproduce the issue.
Below are the Bisect Details:

Bisect Info:
=============
Good Build: 53.0.2746.0(395489)
Bad Build: 53.0.2748.0(395748)

Bisect URL:
===========
You are probably looking for a change made after 395490 (known good), but no later than 395501 (first known bad).
CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/6de57089abaea05decce400f1bae7889b34e839b..e79f1dd40fc3a6591b1a30aa911eaf1fbb339e49

Unable to find a possible suspect from the CL generated. Untriaging it so that it gets addressed.
Note : Able to reproduce the issue in Win 10.0(#53.0.2785.143) & Linux Ubuntu(#53.0.2785.143)

Comment 7 by f...@opera.com, Oct 6 2016

4c1400381d16b6dcd8921a8f19a2ae9af4aac4cf in that range is likely the culprit (as indicated above.)

Comment 8 by f...@opera.com, Oct 6 2016

Cc: -fmalita@chromium.org
Owner: fmalita@chromium.org
Status: Assigned (was: Untriaged)
Thanks, this is indeed a dupe of issue 644112, and should be fixed in 604a9c1f58454572d2e4c3680e913de37723410b.

Since that bug's marked as internal, I don't think I can dupe on it.  Let's see if we can still merge to 54.
Status: Fixed (was: Assigned)
The fix has been merged, and should be available in the next M54 refresh.

Sign in to add a comment